What is DAST? Dynamic application security testing, explained
DAST tests a running application from the outside: crawling its pages and APIs, sending crafted inputs, and observing responses to find exploitable behavior like injection, broken authentication, and misconfigurations. It sees what is actually exposed in the deployed application, including issues no code review can catch.
DAST, dynamic application security testing, tests an application the way an attacker encounters it: from the outside, while it runs, with no knowledge of the source code. The scanner crawls the application’s pages and endpoints, sends deliberately malformed and malicious inputs, and watches how the application responds.
What DAST actually finds
Because DAST observes real behavior, it excels at flaws that only exist in the deployed, integrated system:
- Injection vulnerabilities proven by response: the scanner does not guess that a parameter might be injectable; it demonstrates it.
- Authentication and session weaknesses: broken login flows, session fixation, missing access controls between user roles.
- Server and framework misconfigurations: verbose error pages, dangerous HTTP methods, missing security headers, exposed debug endpoints.
- Cross-site scripting confirmed in the rendered page, not inferred from code.
The defining strength is evidence: a real request that produced a real, observable failure. A DAST finding that ships the exact request and response is close to self-triaging.
How it differs from SAST
The two are mirror images. SAST reads the code without running it: earliest possible feedback, exact file and line, but blind to deployment reality. DAST runs the application without reading it: complete deployment reality, but findings point at URLs and parameters rather than lines of code. SAST can cover code paths a crawler never reaches; DAST catches integration and configuration issues no static analysis can see. This is why the serious answer to “SAST or DAST” is “both, correlated in one place.”
Running DAST well
Three practices separate useful DAST from shelfware:
- Test where your apps actually live. For internal and pre-production systems, that means a scanner deployed inside your network, not a cloud service that cannot reach them. This matters doubly in restricted and airgapped environments.
- Feed it your API specifications. An OpenAPI file turns blind crawling into systematic coverage of every endpoint and parameter.
- Scope and schedule deliberately. Safe-mode defaults, excluded paths for fragile functionality, and repeatable scan profiles that fit a pipeline stage or a nightly window.
The boundary
DAST cannot see what it cannot reach: logic behind feature flags, code paths requiring exotic state, or vulnerabilities in components that never surface over HTTP. It complements rather than replaces the static view, which is why SecuDAST runs alongside eight sibling engines feeding one queue, entirely inside your perimeter.
Frequently asked questions
Is DAST safe to run against production?
It is designed for staging and pre-production environments. Reputable scanners default to safe modes that avoid destructive payloads and let you scope out sensitive endpoints, but the standard practice is testing an environment that mirrors production rather than production itself.
Do I need DAST if I already run SAST?
They answer different questions. SAST finds flaws in the code before deployment; DAST finds what is actually exploitable in the running system, including configuration, deployment, and integration issues that exist in no single source file. Mature programs run both.
Can DAST test APIs and single-page applications?
Modern engines can, by consuming API specifications to map endpoints and by exercising JavaScript-driven frontends. Classic crawlers built for form-based websites miss most of a modern application, so API and SPA support is a key evaluation criterion.