Cybersecurity glossary
What is Dynamic Application Security Testing (DAST)?
Learn what DAST is, how runtime web and API scanners test deployed applications, where DAST excels, what it misses, and how to pair it with SAST and IAST.
Definition
Dynamic Application Security Testing (DAST) is black-box security testing that probes a running application or API from the outside to find exploitable runtime vulnerabilities.
Why Dynamic Application Security Testing (DAST) matters
Applications can be secure in source code review and still fail once deployed. Reverse proxies, auth middleware, feature flags, headers, redirects, and runtime frameworks all shape the attack surface that users and attackers actually reach.
DAST tests that live behavior. It is especially valuable for finding issues that only appear when the application is assembled, configured, authenticated, and reachable over HTTP.
Where DAST adds value
Runtime evidence
Findings include actual requests, responses, status codes, and payload behavior.
No source required
Scans can cover legacy, vendor, or mixed-language apps when code access is limited.
Configuration coverage
Headers, TLS behavior, cookies, routing, and error pages are tested as deployed.
Attacker perspective
The tool approaches the app through exposed routes instead of internal assumptions.
A practical DAST workflow
Choose the target
Use a staging, preview, or controlled production environment that matches real configuration.
Seed discovery
Provide routes, OpenAPI specs, sitemaps, or recorded journeys so the scanner reaches meaningful pages.
Authenticate safely
Create test accounts and session handling so protected workflows are in scope without using real user data.
Run active probes
The scanner sends payloads for injection, traversal, header, redirect, session, and validation weaknesses.
Triage with evidence
Review reproducible requests, remove false positives, and map findings to owning services.
Retest fixes
Rerun focused scans after remediation so closure is based on behavior, not promises.
DAST compared with SAST and IAST
| Method | What it sees | Main tradeoff |
|---|---|---|
| DAST | External runtime behavior, responses, and deployed configuration | Limited visibility into exact code paths |
| SAST | Source, bytecode, and dataflow before the app runs | May not know real runtime reachability |
| IAST | Runtime execution with instrumentation inside the app | Requires agent support and test traffic |
| Manual testing | Business logic, chained abuse, and attacker creativity | Harder to scale across every release |
DAST implementation checklist
- Run scans against environments that match production security headers, routing, and authentication.
- Seed scanners with API specs, browser journeys, and application maps to improve coverage.
- Use dedicated test accounts and test data; never scan with privileged personal accounts.
- Throttle scans to avoid accidental denial of service or noisy monitoring alerts.
- Separate quick pull-request scans from deeper scheduled scans.
- Require reproducible request and response evidence before filing high-severity bugs.
- Pair DAST with SAST, SCA, and manual review for weaknesses external probing cannot infer.
- Retest remediated findings automatically where possible.
The practical takeaway
Dynamic Application Security Testing (DAST) answers a simple question: what can an outside attacker make this running application do? That makes it a strong release-readiness and regression tool.
DAST is not a complete AppSec program. It becomes much more useful when authenticated, seeded with real routes, tuned to the environment, and paired with code-aware testing.
Related security terms
Static Application Security Testing (SAST)
Analyzes code before execution, complementing DAST's runtime view.
Interactive Application Security Testing (IAST)
Uses runtime instrumentation to add code context while tests execute.
API Security Testing
API-focused testing often uses DAST techniques with schemas and authenticated flows.
Application Security (AppSec)
The broader program that decides where DAST belongs in the lifecycle.
Secure Software Development Lifecycle (SSDLC)
Lifecycle model for placing DAST in staging, CI, and release readiness.
Frequently asked questions
What is DAST in simple terms?
DAST points a scanner at a running website or API and tries attack patterns such as injection, broken headers, weak redirects, and unsafe error behavior.
How is DAST different from SAST?
SAST reads code without running the app. DAST tests the deployed app from the outside, so it sees runtime configuration and behavior but usually has less code-level detail.
How is DAST different from IAST?
DAST is mostly external probing. IAST instruments the application during testing, giving richer evidence about which code path handled a request.
Does DAST require source code?
No. That is one reason it works well for third-party apps, legacy systems, and staging environments where a scanner only needs network access and credentials.
What does DAST commonly miss?
It can miss hidden routes, business logic flaws, deep authorization issues, and vulnerabilities that require complex state unless the scan is well authenticated and seeded.
Can DAST run in CI/CD?
Yes, especially as targeted scans against preview or staging deployments. Full crawls may be scheduled nightly to avoid slowing every pull request.
Is DAST safe against production?
Use caution. Prefer staging for active attack payloads. If production scanning is necessary, use safe payloads, rate limits, test accounts, and clear change windows.
References
Explore authoritative guidance and frameworks related to dynamic application security testing (dast).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.