Dynamic application security testing (DAST) is a way of finding security weaknesses in a web application or API while it is running, by testing it from the outside the way an attacker would. A DAST tool explores the application, then sends crafted requests designed to trigger problems such as injection flaws, broken authentication or security misconfigurations, and reports what it finds. It needs no access to source code, which makes it a form of black-box testing.
At a glance
- DAST tests the running application through its web pages and API endpoints, not its code.
- It finds issues that only appear at runtime, such as server misconfigurations, weak session handling and some injection flaws.
- It doesn’t need source code, so it works regardless of programming language.
- It can’t point to the exact line of code responsible, and coverage depends on how much of the application the tool can reach.
- It is commonly automated in a test environment as part of the release pipeline, alongside static testing.
What problem it solves
Code can look safe and still be vulnerable once it runs, because problems often come from how components are configured and interact: a web server that reveals too much information, a session cookie missing security settings, or an input that is handled safely in one place but not another. Reviewing the code alone doesn’t always reveal these issues.
DAST checks the application as it is actually deployed. It shows what an outside attacker could reach and exploit, which helps teams prioritize issues that are genuinely exposed. Because it is automated, it can run on every release or on a schedule, giving software companies repeatable evidence for customers and auditors that their applications are tested.
How it works
Configuration. The team points the tool at an application or API, usually in a test environment, and provides login details and, for APIs, a definition of the available endpoints.
Crawling. The tool explores the application, following links, submitting forms and recording every page, parameter and endpoint it can find. Modern applications built with heavy JavaScript can make crawling harder, so coverage needs checking.
Attack simulation. For each input it found, the tool sends variations designed to trigger known classes of weakness, for example inputs that try to break out of a database query or inject script into a page.
Analysis. It examines the responses for signs of a weakness, such as error messages, unexpected data or behaviour changes, and rates findings by severity.
Reporting and workflow. Findings, with the requests that triggered them, go to developers to reproduce and fix. In a DevSecOps pipeline, scans run automatically against each new build in a test environment.
When it matters for buyers
- When you run customer-facing web applications or APIs. These are directly reachable by attackers.
- When customers or auditors ask how your software is tested. DAST reports are common evidence alongside penetration testing.
- When you lack source code. DAST can test applications you are permitted to scan even without code access.
- When building an application security testing program. DAST complements static testing, which sees the code but not the runtime. Our application security testing overview covers how these tools are bundled and priced.
- When releases are frequent. Automated scans can keep pace where manual testing can’t.
Questions to ask vendors
- How well do you crawl modern single-page applications, and how do you handle logins and multi-step workflows?
- Can you test our APIs, and which API definition formats do you import?
- How do you keep scans from damaging test data or disrupting systems?
- How do you confirm findings to reduce false positives?
- How long does a typical scan take, and can it run in our release pipeline?
- How is pricing calculated: per application, per target, per scan or per user?
How it differs from SAST
Static application security testing (SAST) reads the source code without running it and can point to the exact line with a problem, early in development. DAST tests the running application from outside, later in the cycle, and finds runtime and configuration issues SAST can’t see, but it can’t show where in the code the problem lies. Each misses things the other finds, which is why many teams use both. Once the application is live, web application and API protection (WAAP) adds a protective layer in front of it rather than testing it.