DAST (Dynamic Application Security Testing)

DAST tests a running application over the network, with no access to its source. It crawls the deployed surface to find every page, form, parameter and API endpoint, then sends crafted requests to each one and reads what comes back. If a request produces a response that a correctly-behaving application would not produce, that is a finding.

It is the only technique that tests what is actually deployed, rather than what the repository says should be deployed. Misconfigured headers, a debug endpoint left enabled, an expired certificate, a reverse proxy that strips an authentication header — none of these exist in source code, and all of them are exploitable.

DAST finds the gap between the codebase and the deployment. Every organisation has one: a staging header that shipped to production, a route that bypasses the authentication middleware, an S3 bucket policy nobody reviewed. Static analysis cannot see any of it because none of it is in the source tree.

It is also the closest a scanner gets to an attacker's view. A DAST finding needs no interpretation — the request is right there, and running it again reproduces the result. That property is why DAST evidence tends to survive a triage meeting when SAST findings do not.

The cost is time. A thorough crawl of a large site is slow, and the check suite multiplies by the number of endpoints found, so a scan needs an explicit wall-clock budget rather than an open-ended one.