What is Dynamic Application Security Testing (DAST)?
Dynamic Application Security Testing (DAST) is a method of finding security vulnerabilities in a running web application or API by sending attack traffic and observing how the application responds. It requires no access to source code and tests the application from the outside, the way an attacker would.
What it does
DAST tools probe a live, running application by sending crafted HTTP requests and analyzing the responses. They simulate real attack techniques such as SQL injection, cross-site scripting (XSS), authentication bypass, and insecure direct object references. Because the tool interacts with the application at runtime, it can find vulnerabilities that only appear when code is actually executing, such as logic flaws in session handling or misconfigured server headers.
A DAST scan typically:
- Crawls the application to map all reachable endpoints and parameters
- Sends malicious or unexpected input to each parameter
- Checks responses for signs of vulnerability, such as error messages, reflected content, or unexpected data
- Reports findings with the URL, parameter, and evidence of the issue
Modern DAST tools also scan APIs directly using OpenAPI or Postman collections, not just browser-rendered pages.
Why teams buy it
DAST finds vulnerabilities that Static Application Security Testing (SAST) cannot, because SAST reads code without running it. A misconfigured web server, a vulnerable third-party component exposed at runtime, or a flaw in how the application assembles responses will not appear in a static scan. DAST also produces findings that are easier to verify because the tool has already confirmed the application responded in a vulnerable way.
Teams integrate DAST into CI/CD pipelines to catch regressions before deployment, and run authenticated scans against staging environments to cover logged-in functionality.
What to look for
- Authentication support: The scanner must be able to log in and maintain a session to test protected pages.
- API coverage: Look for native support for REST and GraphQL APIs, not just HTML forms.