Dynamic application security testing evaluates a running application from the outside to identify security weaknesses in behavior and exposed functionality.
Dynamic application security testing (DAST) evaluates a running application from the outside to identify security weaknesses in its behavior. In plain language, it interacts with the live system like a user and observes how the app responds.
DAST matters because some weaknesses only show up when the application is running. Configuration, request handling, session behavior, and runtime responses can expose issues that are not obvious from code review alone.
It also matters because security teams need a view of the real deployed surface, not only the intended code structure. External behavior is what attackers and defenders both ultimately encounter.
DAST appears in QA security testing, pre-release validation, web-application review, and recurring security assessment. Teams use it to probe exposed behavior and verify whether protections around requests, sessions, and responses are working as expected.
Security teams often use DAST alongside SAST, because the two approaches complement each other rather than replacing each other.
A staging environment for a web portal is tested with DAST before release. The testing workflow finds that a settings endpoint accepts a state-changing request without the expected protections, so the team fixes the issue before production.
| Strength | What it reveals |
|---|---|
| Runtime behavior | How the live app handles requests and sessions. |
| Real configuration | Exposure created by deployed settings and middleware. |
| External surface | What an external user or tester can actually reach. |
| Regression checks | Whether known fixes still hold after releases. |
DAST works best when it is run against realistic environments, authenticated flows are represented safely, and findings are triaged with development context. Otherwise, scans may miss important areas or produce noisy results that teams stop trusting.
Defensive DAST programs should also define safe test windows, target scope, and escalation paths so testing validates security without disrupting production service.
DAST is not the same as SAST. DAST does not inspect source code directly; it evaluates the running application’s exposed behavior.
DAST is also not complete coverage. If a feature is hidden, hard to reach, or poorly represented in the test flow, DAST can miss issues that secure coding review or code analysis would catch.