Dynamic Application Security Testing
DAST probes a running application from the outside, finding exploitable flaws in the real deployed configuration.
Definition
Dynamic application security testing (DAST) exercises a running application as an attacker would: sending crafted requests, fuzzing inputs, and observing responses to detect vulnerabilities such as injection, broken authentication, and misconfiguration. Because it tests the deployed artefact, it sees configuration and runtime behaviour that static analysis cannot, but it can only find flaws it manages to trigger, and it cannot point to the offending line of code.
Context and scope
Run against staging and production-like environments in CI or on a schedule, complementing SAST with runtime evidence.
Common misconceptions
- DAST finds every flaw — it finds only reachable, triggerable issues; unexercised endpoints and logic bugs remain hidden
- Pixel-perfect false positives mean no value — DAST findings are exploitable by construction, which is why they rate highly
- Scanning production is always dangerous — well-run scans use test accounts and rate limits; blind aggressive scans can corrupt data
Anti-patterns
- Running an aggressive scan against production without test data, corrupting records or triggering alarms
- Scanning an environment with authentication disabled, missing every authenticated flaw
- Reporting raw scanner output to developers with no reproduction steps or prioritisation
Related concepts
Related examples
Authoritative source
https://owasp.org/www-community/Vulnerability_Scanning_Tools
What it is
A DAST scanner drives the running system over its real interfaces — HTTP endpoints, forms, APIs — and mutates requests looking for evidence of exploitation. It crawls to discover endpoints, injects payloads, and checks responses against signatures of vulnerable behaviour. Because the target is the deployed build, its findings reflect the actual configuration, including the framework version, the WAF, and the headers actually served.
Why it matters
Many breaches exploit runtime conditions that no source scan sees: a debug endpoint left enabled, a default credential, an HTTP header misconfiguration, a dependency behaviour only visible when running. DAST catches these, and its findings are, by nature, reproducible against a live system, which removes debate about exploitability and sharpens prioritisation.
How to use it well
Run authenticated scans against a staging environment identical to production, with seed data and safe credentials, so authenticated and complex flows are covered. Keep the scan aggressive only in isolated environments; in production prefer passive and bounded scans. Feed findings into the same triage process as SAST, add regression tests for confirmed issues, and use the crawl to keep the endpoint inventory, and therefore the attack surface, honest.