What is DAST (Dynamic Application Security Testing)?
Updated
Dynamic Application Security Testing (DAST) tests a running application from the outside, sending crafted requests the way an attacker would and observing how the application responds. Because it exercises the deployed, running system, it finds vulnerabilities that only manifest at runtime — configuration errors, authentication weaknesses, and injection flaws in live behavior.
DAST is a 'black-box' technique: it does not see the source code, only the application's external behavior. That makes it technology-agnostic and good at catching what actually happens in production, but it can only test the paths it manages to reach, and it finds a flaw without pointing to the line of code that caused it — the opposite trade-off from SAST.
How DAST works and what it catches
A DAST scanner first crawls the running application to discover its endpoints and inputs, then submits malicious or malformed payloads and analyzes the responses for signs of a vulnerability — an error leaking internal detail, a reflected script, an authentication bypass. Because it interacts with the real deployment, it catches issues that live in configuration and runtime state rather than in source: missing security headers, exposed admin paths, session-handling flaws.
Its coverage is bounded by what it can reach. Complex authenticated flows, single-page applications, and API-only surfaces need configuration to test well, and anything the crawler never navigates to is never tested. DAST is therefore strongest when it is fed good coverage — seeded credentials, an API specification — rather than pointed at a URL and left to explore on its own.
Where DAST fits alongside SAST and SCA
DAST answers a question static analysis cannot: what is actually exploitable in the deployed system right now? SAST finds coding flaws early but cannot see runtime configuration; software composition analysis inventories dependency risk but does not exercise behavior. DAST closes the runtime gap, which is why the three are used together across the lifecycle rather than chosen between.
In a pipeline, SAST typically runs on every commit for fast first-party feedback, SCA runs continuously as new vulnerabilities are disclosed against dependencies, and DAST runs against staging or production builds where a real running target exists. Findings from all three should be deduplicated and normalized so the same underlying issue is not counted three times.
Frequently asked questions
What is the difference between DAST and SAST?
DAST tests a running application from the outside and finds runtime and configuration flaws, but cannot point to the source line. SAST analyzes source code without running it and finds first-party coding flaws early, pinpointing the exact location. They are complementary black-box and white-box techniques, best run together.
What kinds of vulnerabilities does DAST find?
DAST is strong at runtime and configuration issues: missing security headers, exposed administrative paths, authentication and session-handling weaknesses, and injection flaws that appear in live responses. Because it exercises the deployed system, it catches problems that only exist once the application is actually running and configured.
Why does DAST need configuration to be effective?
DAST can only test the paths it reaches. Authenticated flows, single-page applications, and API-only surfaces are easy for a crawler to miss, so providing credentials and an API specification greatly improves coverage. Without that, a scan may exercise only a fraction of the application and report a falsely clean result.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.