Dynamic Application Security Testing (DAST) takes a different approach than static analysis. Instead of examining source code, DAST tools interact with running applications the way an attacker would: sending requests, probing for vulnerabilities, and analyzing responses.
The key advantage of DAST is that it tests application behavior, rather than just looking at the code. A configuration issue, a vulnerable library, or a deployment mistake might not show up in source code but will be visible when testing the running application.
How DAST Works
A typical DAST scan starts by crawling the application to discover all accessible endpoints. The tool then sends various attack payloads to these endpoints (SQL injection attempts, cross-site scripting probes, authentication bypass attempts) and watches how the application responds.
When the application returns an error message that reveals database information, or reflects malicious content back in the page, or grants access when it shouldn't, the DAST tool flags a potential vulnerability.
The OWASP Testing Guide provides comprehensive methodology for this type of testing.
Limitations
However, DAST has some inherent limitations. It can only test what it can reach. If a feature is behind authentication that the tool can't navigate, or can only be accessed through a path the crawler doesn't find, it won't be tested.
DAST also runs late in the development lifecycle. You need a running application, which typically means code has already been written, reviewed, and deployed to at least a staging environment. Findings at this stage are more expensive to fix than issues caught earlier.
For AI-generated code specifically, DAST remains useful for testing deployed applications but doesn't address the core challenge of code being generated faster than it can be reviewed. That's where approaches like ACSM come in, providing security during generation rather than after deployment. Corridor catches vulnerabilities while the AI is still writing code, long before DAST would see it.