DAST, or Dynamic Application Security Testing, is a method of testing an application for security vulnerabilities while it is running, by interacting with it from the outside – much as an attacker would – without access to its source code. Because it examines the application in its operational state, DAST is often called “black-box” testing: it sends inputs, requests, and crafted payloads to the live application and analyzes the responses to detect vulnerabilities that manifest at runtime.
DAST tools automatically crawl an application, discover its inputs and endpoints, and then probe them with malicious or malformed data to surface issues such as injection flaws (like SQL injection), cross-site scripting, authentication and session weaknesses, security misconfigurations, and improper error handling. Because it tests the running system, DAST can catch vulnerabilities that only appear in a deployed, configured environment – including issues arising from server configuration, runtime behavior, and interactions between components – which static analysis of code alone might miss.
DAST is frequently contrasted with SAST (Static Application Security Testing), which analyzes source code without running it. The two are complementary. SAST examines internal code early in development and can pinpoint the exact line of a flaw but may produce false positives and cannot see runtime issues; DAST tests the running application from the outside, finds real exploitable behavior and configuration problems, but sees the application as a black box and cannot point to the specific vulnerable code. IAST (Interactive Application Security Testing) blends both approaches. Using SAST, DAST, and IAST together provides broader coverage across the software development lifecycle.
DAST is valuable for APIs and web applications because it validates how the deployed system actually behaves under attack. However, traditional DAST can struggle with modern APIs and business-logic vulnerabilities, since it primarily looks for known technical vulnerability classes rather than the authorization and workflow abuses (like BOLA or business logic attacks) that require understanding of application-specific context. As a result, DAST is best used as one layer within a comprehensive testing program spanning development and runtime, complemented by tools and testing designed for API-specific and logic-based risks.