DAST (dynamic application security testing): what it finds, what it misses

DAST stands for dynamic application security testing. Search results for the bare acronym also show a medical screening test with the same letters, so this page uses the full term. DAST tests a running web application or API from the outside, the way an attacker's browser or script would. This guide covers how a scan works, where it fails, how to run one safely, and how it differs from SAST and a penetration test.

What is DAST (dynamic application security testing)?#

DAST is automated testing of a running application. The OWASP DevSecOps Guideline calls it black-box testing: it finds weaknesses in a running application by injecting malicious payloads, for example to look for SQL injection or cross-site scripting (XSS). The tool needs no source code and does not care which framework built the app. OWASP DevSecOps Guideline

The same page lists input and output validation, authentication issues and server configuration mistakes as areas where DAST helps most. OWASP also notes that DAST tools usually need little interaction once configured and can run as a nightly scan.

OWASP's tool list groups web application vulnerability scanners under the DAST label and says they scan "normally from the outside". OWASP Vulnerability Scanning Tools The list includes commercial products and open-source tools such as ZAP (Zed Attack Proxy). We name no product as the best choice. The right tool depends on your stack and login method.

DAST does not replace the other testing types in our map of security testing. It covers one question: what can an outside caller trigger on the running app?

How does a DAST scan work step by step?#

A scan has four stages: discover pages and endpoints, send test requests, compare responses and report. The open-source ZAP tool shows the stages clearly, because its documentation splits a scan into a crawl, passive checks and active attacks.

1. Configure the target and scope. You give the tool a base URL, the hosts it may touch and the paths to skip (logout, delete, payment).
2. Discover. A spider follows links and forms. Some tools also run a browser to find routes that JavaScript creates. For an API, you usually import a spec such as an OpenAPI file, since an API has no links to follow.
3. Check passively. The tool reads the traffic it already saw. It flags missing security headers, cookie flags and version banners. This stage sends no attack payloads.
4. Attack actively. The tool replays requests with modified values: quote characters in parameters, script tags in fields, path traversal strings in file names. It reads each response for errors, reflected input or timing changes.
5. Report. The tool lists findings with the request, the response and a confidence rating.

ZAP's documentation states the difference between the stages. Its baseline scan runs the spider for 1 minute by default and waits for passive scanning to finish. The documentation says the script does not perform any actual attacks and runs for a few minutes at most. ZAP Baseline Scan The full scan adds an active scan. ZAP says it performs actual attacks and can run for a long time. ZAP Full Scan ZAP's active scan page states: "Active scanning is an attack on those targets." ZAP Active Scan

WARN  Missing Content-Security-Policy header   GET /
WARN  Cookie without HttpOnly flag: session    GET /login
PASS  Strict-Transport-Security present        GET /

What does DAST find and what does it miss?#

DAST finds flaws that show up in the response to one crafted request. It misses flaws that depend on who you are, what happened before, or what the business rule is. The table sorts common issues by how well a scanner sees them.

The WSTG has a section on business logic testing (4.10, test IDs WSTG-BUSL-xx), and it covers cases such as circumvention of workflows and limits on how many times a function can be used. OWASP WSTG A scanner has no rule that says "a viewer must not change the price", so it cannot test it. Our guides on IDOR testing and business logic vulnerabilities show what testers do instead.

What are the authorization and safe scanning rules?#

Get written permission from the system owner before any active scan, and never scan a system you do not own. A scan sends attack payloads, so it counts as an attack on the target. The ZAP page above says so in plain words.

Use this list before an active scan.

• Written authorization names the hosts, the scan type and the time window.
• You scan staging first. If production is in scope, you agree a rate limit and a stop contact.
• The scanner uses test accounts, not real customer accounts.
• Delete and payment paths are excluded, and outbound email is disabled or sent to a sink.
• Someone watches error rates and can stop the scan.
• Third-party hosts (analytics, payment, CDN) stay out of scope. Their owners did not authorize you.
• You keep the scan configuration and the raw output as evidence.

NIST SP 800-115, published in 2008 and still listed as final, treats testing as something an organization plans and authorizes, and says legal advisors should always be involved in intrusive tests such as penetration testing. NIST SP 800-115 Read the rules of engagement guide for the contents of a written scope.

An active scan against a shared test environment can create thousands of records. Agree a cleanup step before you start.

Where does DAST fit in CI and release checks?#

Run a passive or baseline scan on every build of a staging site, and run active scans on a schedule or before a release. A short scan fits in a pipeline. A long active scan does not, because it can run for a long time and can change data.

Keep the gate narrow. If the pipeline fails on every low-severity header warning, developers will switch it off. Gate on a small list of finding types you agreed on and track the rest as tickets.

DAST supports the release gate. It does not replace the testing that follows a risky change. See how often to pentest for triggers.

How do DAST, SAST and penetration testing compare?#

SAST reads code, DAST tests the running app, and a penetration test is a person who tests the app with goals, accounts and judgment. Each one answers a different question.

OWASP's DAST page describes the method as black-box. A penetration test can also be grey-box or white-box, as described in our black-box, grey-box and white-box guide. For the scan versus pentest question from the buyer side, see the neutral comparison on pentestcompare.com.

How do you read DAST results and cut false positives?#

Treat each scanner finding as a lead and confirm it with the raw request and response. Then decide whether it is real, a false positive or a duplicate. Do this before you open a ticket.

1. Group by type. One missing header on 400 URLs is one finding.
2. Open the evidence. Check that the payload really came back, or that the error really came from your code.
3. Replay by hand. Send the request again with a proxy or curl. A true XSS fires again. A timing result that does not repeat is noise.
4. Check the context. A reflected value inside a JSON response with the right content type is not exploitable the same way as one in an HTML page.
5. Rank by your data. A flaw on a login form matters more than the same flaw on a static page.
6. Record the decision. Mark false positives with a reason, so the next scan does not raise the same ticket.

If the scan shows no authenticated pages, it tested only your public site. Fix the login recorder before you trust a clean result. A clean scan does not show that the app is secure. It shows that the scanner's fixed checks found nothing in the part of the app it could reach.

When you need to know whether one customer can read another customer's data, you need a test with two accounts. Our multi-tenant isolation guide shows that method, and our web application penetration testing service page describes how Excession Labs runs it.