Security Engineering In progress
Intermediate 16 min read Security Engineering
DAST: Dynamic Testing on a Running App
Test the running application the way an attacker would: crawling, injection probes, and authen-thresholding — on environments you control.
DASTZAPactive scanOWASP ZAPcrawlingconfig vs runtime
Introduction
What is this?
DAST (Dynamic Application Security Testing) attacks a running application with real HTTP requests to uncover vulnerabilities visible from outside — no source code required.
Motivation
Why do you need it?
- DAST sees what SAST can't: the behavior of assembled dependencies, config, and wiring at runtime.
- It tests 'can an unauthenticated attacker actually do this' — the question SAST answers poorly.
- ZAP and peers make baseline scans a five-minute CI chore, catching config-drift regressions.
Think about it
Mental model
Imagine
Reading the car's service manual
Think of
Test-driving the finished car
The manual (SAST) knows the parts; the road test (DAST) discovers what they actually do together.
Mechanics
How it works
- Spider/crawler maps the app's routes from a starting URL (your own staging).
- Active scans replay requests with payload injections (SQLi, XSS, path traversal, header checks).
- Auth-aware scans replay as an authenticated session to cover gated routes.
- Results arrive as findings with request/response evidence ready for triage.
DAST against a staging app
Spiderenumerate routes
Authsession replay for gated parts
Probeinjection + header payloads
Reportrequest/response evidence
Triageconfirm, dedupe, fix
Real world
In production
- A startup runs a ZAP baseline nightly against staging and catches a config regression the unit tests missed.
- A pentest uses DAST output as the map, then manually verifies the top findings to remove noise.
- A SOC teams scans its own login flows to size brute-force resistance before legal red-team week.
Guidelines
Best practices
- Target staging/test environments you own; never point DAST at third-party or production without explicit scope.
- Run with auth-enabled sessions to cover routes your users actually reach.
- Set timeouts and harnesses so the scan cannot hammer the target into an outage — rate-limit deliberately.
- Pair with SAST: DAST finds what shipping assembled, SAST finds what coding introduced.
Watch out
Common mistakes
- Scanning production 'to check the patch' and triggering the WAF, altercation, and a support ticket.
- Letting the spider wander into admin or cross-tenant data routes in a shared staging.
- Running unauthenticated scans only, believing the auth-gated flaws don't exist.
- Publishing a raw DAST dump as 'the report' without any manual confirmation.
When things break
Debugging tips
- When a scan reports no findings on gated routes, confirm the auth session actually replays.
- Inspect the exact request the scanner sent; false positives are often scanner-specific artifacts.
- Re-run the repro on the same build after a fix; the regression check is the whole point.
Security
Security considerations
- DAST actively sends attack traffic — keep it scoped, rate-limited, and on dedicated test envs.
- Session tokens used by the scanner are real credentials; store them in the scan config, not the logs.
Interviews
Interview checkpoint
Practice
Hands-on lab
Nightly-Style DAST Baseline Against a Local Staging App
45 min · intermediate
Objectives
- Run ZAP in baseline mode against local staging (DVWA).
- Review a handful of findings with evidence.
- Design the 'CI won't false-fail' gate tweaks.
Nightly-Style DAST Baseline Against a Local Staging App
45 min · intermediate
0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself
Quick quiz
0/2
1
DAST is most valuable for...
2
An unauthenticated DAST scan alone...
Go deeper