What is dynamic application security testing (DAST)?

DAST is commonly applied to web applications and APIs. Unlike static analysis, it evaluates how the deployed application actually responds to requests and potentially hostile interactions.

DAST, or dynamic application security testing, tests the security behavior of an application while it is running.

It takes an outside-in perspective, interacting with the application through surfaces an external user or attacker could reach. Instead of analyzing source code, a DAST process interacts with reachable pages, endpoints, forms, APIs, authentication flows, and other exposed application surfaces.

The testing may send unusual or potentially malicious inputs and examine the resulting responses for signs of security weaknesses. Because it works against the running system, DAST can identify issues related to runtime behavior and deployment configuration that may not be visible from source code alone.

DAST is a testing approach rather than one specific security product. Testing can be automated with scanners, supplemented with manual assessment, or used alongside other application security techniques.

DAST works by exploring a running application, interacting with exposed functionality, and analyzing how the system responds.

A typical automated DAST process includes:

1. Discover reachable application surfaces. The scanner identifies pages, parameters, forms, endpoints, or API operations it can access.
2. Interact with the application. It sends requests in much the same way a browser, API client, or external user would.
3. Test unexpected inputs. The scanner modifies requests to check how the application handles potentially unsafe or malformed data.
4. Observe runtime behavior. Responses, error messages, headers, redirects, and other behavior are examined for evidence of weaknesses.
5. Report potential findings. Detected issues are recorded for review, validation, and remediation.

DAST findings depend heavily on scan coverage. If the scanner cannot authenticate properly, discover an endpoint, or reach a particular workflow, it cannot meaningfully test that part of the application.

DAST can identify security weaknesses that become observable when an application is running and receives external input.

Depending on the application and scanner coverage, findings may include:

• Injection vulnerabilities. Certain SQL, command, or other injection patterns may become visible through application responses.
• Cross-site scripting. DAST can test whether untrusted input is reflected or handled in ways that allow browser-side script execution.
• Authentication and session weaknesses. Some problems involving login flows, cookies, sessions, or exposed authentication behavior may be detectable dynamically.
• Input-validation issues. Unexpected input can reveal insufficient validation or unsafe error handling.
• Unexpectedly exposed surfaces. Crawling and API testing may reveal undocumented or unintentionally reachable endpoints and functionality.
• Security misconfigurations. Some server, application, TLS, or security-header misconfigurations are visible from the deployed environment.

Coverage is not automatic. DAST only evaluates functionality it can discover, reach, authenticate to, and exercise under the test conditions.

DAST and static application security testing (SAST) examine application security from different perspectives.

SAST analyzes source code, bytecode, or binaries without needing to run the application. Source-level analysis provides visibility into implementation details and allows teams to identify certain security weaknesses earlier in development.

DAST tests a running application externally and does not require access to its source code. Its strength is observing actual runtime behavior, including weaknesses related to deployment, configuration, exposed interfaces, and interactions that become visible only when the application is executing.

Neither approach replaces the other: SAST can expose code-level weaknesses that a dynamic scan cannot reach, while DAST can reveal runtime and configuration problems that source analysis may miss.

DAST is used once a testable version of the application is running, which means it generally enters the lifecycle later than static code analysis.

Teams may run dynamic testing:

• Against test or staging environments.
• Before a release.
• As recurring security scans within CI/CD workflows.
• Periodically against deployed applications where the environment and testing scope make this appropriate.

Automated DAST can make runtime checks repeatable as an application changes. Scan timing should account for application size, authentication requirements, test data, and the potential effect of active security testing on the environment.

There is no universal scan frequency that works for every system. DAST is most useful as one repeatable part of a broader application security process.

DAST cannot provide complete visibility into an application's security because it evaluates only the functionality and behavior it can reach externally.

It may miss:

• Unreachable application areas. A scanner cannot test pages or endpoints it fails to discover.
• Unexercised code paths. Vulnerable code may exist without being triggered during dynamic testing.
• Complex business-logic flaws. Understanding whether a workflow violates intended business rules often requires human context.
• Source-level weaknesses. Some implementation problems are difficult or impossible to infer from external behavior alone.
• Protected workflows. Complex authentication, session handling, or multi-step processes can reduce automated coverage.
• Dependency vulnerabilities. Risks inside third-party libraries may require software composition or source-level analysis rather than external scanning.

A clean DAST scan does not prove that an application is secure. It means the testing did not identify vulnerabilities within the surfaces and scenarios it successfully exercised.

Manual security testing and penetration testing can add context, human-led exploration, and validation for business logic or attack paths that automated DAST may miss. For a closer look at that distinction, see our article "Vulnerability Assessment vs. Penetration Testing."