What is DAST?

What is DAST?

Dynamic application security testing (DAST) evaluates a web application or API by interacting with a deployed, running instance of it. The scanner knows nothing about the source code; like an outsider, it maps what the application exposes, fires malicious and malformed input at it and draws conclusions from how the application answers. That makes DAST a black-box technique, and it means DAST can test any application regardless of programming language, including commercial software whose code you cannot read. It normally runs against a test or staging copy of the application after each deployment. Common tools include ZAP and Burp Suite.

How DAST works

1. Discovery: the scanner crawls links and forms, or imports an API definition such as an OpenAPI file, to build a list of endpoints and parameters.
2. Authentication: it signs in with a test account so it can reach pages behind the login, and keeps the session alive during the scan.
3. Passive checks: it reviews every response for problems that need no attack, such as cookies without Secure or HttpOnly, missing headers like Strict-Transport-Security and Content-Security-Policy, verbose error pages and server version banners.
4. Active checks: it injects payloads for SQL injection, cross-site scripting, path traversal, command injection and similar flaws, and looks for evidence in the response: database errors, reflected payloads, unexpected file contents or timing differences.
5. Reporting: each finding lists the URL, parameter, request and response that demonstrated it.

Example: a DAST finding

The scanner sends GET /search?q=%3Cscript%3Ealert(1)%3C%2Fscript%3E and finds <script>alert(1)</script> in the returned page without HTML encoding. It reports reflected XSS in the q parameter of /search, with the request and response as evidence. The developer still has to find the line of code that writes q into the page, because DAST sees only behavior, not code.

Strengths and limits of dynamic testing

DAST finds problems that exist only at runtime: server and framework misconfiguration, weak session handling, missing headers, exposed admin pages and flaws introduced during deployment. A confirmed finding comes with a working request, which makes it easier to rule out false positives than with static analysis.

The limits are coverage and timing. A scanner tests only what it can reach, so multi-step workflows, hidden API routes and pages behind complex logins may be missed. It runs late, after the code is built and deployed, so fixes cost more than flaws caught in the editor. Active scans can submit forms thousands of times, create junk records or lock accounts, so they belong in staging, or in production only with approval and a careful scope. Business logic and authorization flaws still need people to find them.

DAST vs. SAST, fuzzing and penetration testing

• SAST reads the code without running it and reports the file and line; DAST runs the application without the code and reports the URL and request. Most pipelines use both.
• Fuzzing bombards a program with huge amounts of malformed or random input to find crashes and unhandled errors. It is also a dynamic technique, and DAST tools include some of it.
• Penetration testing is people, under written authorization, chaining weaknesses to prove impact. A DAST scan is automated and reports individual issues.
• Vulnerability scanning of hosts looks for known CVEs and missing patches; DAST looks for flaws in the application's own behavior.

DAST on the CompTIA Security+ exam

SY0-801 objective 4.1 lists static code analysis among its application security controls; DAST is taught beside it as the contrasting technique, and questions usually ask you to tell the two apart. Wording such as assess the deployed application from outside, the testers do not have the code, scan the staging site after each deployment or find missing security headers and insecure cookie settings points to DAST. If the question says the code must be examined before it runs, the answer is SAST. If it describes random, malformed input meant to crash the program, the answer is fuzzing, and if testers manually exploit and chain flaws, it is a penetration test.