DAST (dynamic application security testing)
A scanner that attacks a running app from the outside, looking for security holes visible through its real pages and APIs.
See it
What it is
DAST treats a running application like an attacker would: it sends HTTP requests, changes parameters and headers, and studies the responses for exploitable behavior. It does not need the source code. OWASP ZAP and Burp Suite can crawl web routes and probe for problems such as reflected XSS, injection, and exposed server details.
Run it against an isolated staging environment after deployment, then give it an OpenAPI document or authenticated session so it can reach more than the login page. It is especially useful for checking the behavior created by your real framework, proxy, headers, and runtime configuration.
The gotcha is that probes are real traffic. A scan can create records, send email, trigger rate limits, or delete data if the account and environment allow it. Scope the target, seed disposable data, block production, and review every finding. A crawler also misses routes and authorization states it cannot discover, so a clean report does not mean the app is clean.
Ask AI for it
Set up DAST for this application's authorized staging environment with OWASP ZAP. Import the app's OpenAPI document, configure an authenticated ZAP context with a disposable test account, and run zap-baseline.py on every deployment plus a scheduled ZAP full scan. Exclude logout, billing, email-sending, destructive, and third-party routes; enforce the staging hostname in CI so the job cannot target production. Save the HTML and JSON reports as build artifacts, fail only verified high-risk findings, and reproduce each alert with the exact request and response before fixing it and adding a regression test.