DAST: Dynamic Application Security Testing
In plain terms#
Dynamic Application Security Testing (DAST) tests your application while it's running, by making real HTTP requests to it. The way an attacker would. Where SAST reads the source code from the inside, DAST probes the live app from the outside, with no knowledge of the code. It's the difference between reviewing a building's blueprints and walking the halls rattling doorknobs.
Why it matters#
Some vulnerabilities only exist when everything is wired together and running: a reflected cross-site scripting (XSS) flaw that depends on how a response is rendered, an authentication flaw, a misconfigured endpoint that leaks data, a debug page left exposed. Static analysis can't see these because they emerge from behavior, not code shape. DAST catches the runtime reality.
Where it fits#
- Artifact: a running endpoint, ideally a preview or staging deployment.
- Stage: after deploy (to a non-production environment), or on a schedule. It's heavier and slower than PR-time checks, and it needs something running.
Passive vs. active, an important safety note#
- Passive/baseline scanning crawls the app and inspects responses. It's non-destructive and safe to run against your own site.
- Active scanning attacks the app, injecting payloads, submitting forms, which can create data or cause side effects. It's powerful but must only be run against systems you own, with authorization. It's not something to drop into a default CI gate.
Popular & reputable tools#
| Tool | Notes |
|---|---|
| OWASP ZAP | OSS, the reference DAST; full spider + passive/active scans (container-delivered) |
| Nuclei | OSS, single binary; fast template-based runtime checks (exposures, misconfigs) |
| Wapiti | OSS; active crawl-and-inject scanner |
| Burp Suite, StackHawk, Detectify | Commercial DAST platforms |
Common pitfalls#
- Coverage depends on crawling. A DAST tool can only test what it can reach; single-page apps and authenticated areas need configuration to scan properly.
- False positives and runtime cost. DAST is slower and noisier than static checks, reserve it for staging, not every PR.
- Authorization. Only ever scan systems you're permitted to; active scanning especially.
dast control ships today, backed by Nuclei (a single binary, no container needed), checking each host on every release without a scan to stand up per service. Enable it on a component's hosts: and results normalize to SARIF like every other control. By default it checks the unauthenticated perimeter. What any stranger can reach. Give the host an auth: block naming the environment variable holding a token and it scans as a user instead; point it at an openapi.yaml and it exercises the routes the API declares rather than crawling for them, read-only unless you name the write methods you accept. A scanner that would do more to a target than read it declares that, and config.allowEffects is where a descriptor accepts it. A scan that has not been permitted to change something stops before it does, and the refusal says what it would have done. That is the safety note above turned into something a descriptor states and a run enforces, rather than something a person has to remember when they change a target. The native headers control keeps ownership of HTTP security-header checks, and tls covers the transport.
Keep learning#
- SAST, the inside-out counterpart
- HTTP security headers, a fast slice of runtime checking
- TLS assessment, testing the transport layer