DAST

How it works

DAST (Dynamic Application Security Testing) tests a running application from the outside, sending crafted requests and observing responses to find vulnerabilities, without access to the source code. It behaves like an automated attacker: it crawls the app, probes inputs for issues like injection, cross-site scripting, and broken authentication, and reports what it can actually trigger against the live system. Because it exercises the deployed app, DAST catches runtime and configuration flaws that source-code analysis cannot see. It is black-box testing, the dynamic counterpart to SAST.

When it matters

DAST matters for validating an application as it actually runs, including the server, configuration, and integrations that static analysis never touches. It typically runs later in the pipeline, against a staging or test environment, and its findings tend to be more directly exploitable (and so higher-signal) than static ones. The tradeoff is coverage: DAST only tests paths it can reach, so it can miss code that is hard to exercise. Pair it with SAST for both perspectives. See Application Security 101.

Common misconceptions

• "DAST replaces [SAST](/glossary/sast/)." They are complementary: SAST reads code early, DAST attacks the running app later.
• "DAST needs the source code." No. It tests from the outside, black-box, which is also its limitation on coverage.
• "A clean DAST scan means secure." It only covers reachable paths; combine it with static analysis and manual testing.