DAST: Dynamic Application Security Testing Explained

DAST (dynamic application security testing) is automated testing of a running web application or API from the outside. A DAST scanner sends crafted requests, such as injection payloads and malformed input, and analyses the responses for signs of a vulnerability. It needs no access to source code, which makes it the opposite of SAST.

What is DAST?

DAST is black-box testing: the tool sees the application as an outsider does, through its pages, forms, parameters and API endpoints. Because it tests what is actually deployed, it finds problems that only exist at runtime, including server and TLS misconfiguration, missing security headers, weak cookie settings, exposed admin pages, and injection or cross-site scripting that really triggers. It works the same whatever language the application is written in.

How does DAST work?

A DAST scan runs in four stages:

1. Discover. The scanner crawls the application to map pages, forms and parameters. For an API, you import the definition, such as an OpenAPI file, because a crawler cannot find endpoints nothing links to.
2. Authenticate. You give it test accounts and a login sequence so it can reach pages behind the login. Without this, most of the application goes untested.
3. Attack. Passive checks inspect normal responses; active checks send payloads into every input and watch for errors, reflected content or timing changes.
4. Report. Findings are mapped to weakness types, often CWE entries, and given a severity rating. Some tools express it as a CVSS score; others use their own high, medium and low scale.

Active scans submit forms and can create, change or delete data, so run them against a test or staging environment rather than live customer data.

What are DAST tools?

DAST tools are the automated scanners that crawl and attack a running application. Many of the checks they automate are described in the OWASP Web Security Testing Guide. They come in three broad forms:

• Open-source scanners, such as ZAP, which run on a desktop or inside a build pipeline.
• Commercial desktop tools, such as the scanner in Burp Suite Professional, which testers often use alongside manual work.
• Hosted or enterprise platforms that schedule DAST scanning across many applications and track results over time.

When comparing tools, look at how well each one handles logins and sessions, single-page applications, API definitions and false positives, because those decide how much of your application really gets tested.

What a manual tester adds is judgement. A scanner does not know what your application is for. A tester logs in as each role and tries to reach other users’ records (IDOR), abuses workflows such as discounts, refunds and approvals, chains low-rated findings into one serious attack, and confirms each scanner finding so false positives never reach your developers.

SAST vs DAST: what is the difference?

SAST (static application security testing) reads source code, bytecode or binaries without running them; DAST tests the running application from outside. One works inside-out, the other outside-in, and each finds things the other cannot.

Two more approaches often appear in the same conversation. IAST (interactive application security testing) puts an agent inside the running application to combine both views, and SCA (software composition analysis) checks the third-party libraries you depend on:

When should you run DAST in a release cycle?

Run each test where it is cheapest to act on its findings:

• While coding and on every build: SAST and dependency checks, so flaws are fixed before they merge.
• On each deployment to test or staging: DAST testing with a quick baseline scan, and a full authenticated scan before major releases.
• Before significant releases and at least yearly: a manual web application penetration test, plus a secure source code review for code that handles payments or personal data.
• Between tests: scheduled scanning to catch new vulnerabilities in deployed components.

A DAST scan does not replace a manual penetration test: our guide to penetration testing vs vulnerability scanning explains why.

Where does DAST fit in PCI DSS and ISO 27001?

Neither standard names DAST or SAST, but both expect application security testing that these tools help to evidence.

Before 31 March 2025, PCI DSS Requirement 6.4.1 let you protect public-facing web applications with a vulnerability assessment at least every 12 months instead of an automated solution; 6.4.2 has now superseded it. The full wording is in the PCI SSC document library.

Why Sovereign Secure?

We are a PCI SSC Qualified Security Assessor (QSA) company and ISO 27001 certified. We test web applications, APIs, networks, cloud, mobile apps, hardware and IoT, wireless, social engineering, red team, source code and AI/LLM systems, and run vulnerability scanning. Our source code reviews combine manual review with static analysis, and we map findings to PCI DSS 6.2.3 and 6.2.4.

More terms are in our cyber security glossary. To scope a web application test or code review, call +44 161 523 5276 or request a quote through our penetration testing quote form.