Summary
Dynamic Application Security Testing (DAST) tests running applications by simulating real-world attacks against exposed interfaces to identify exploitable vulnerabilities that cannot be detected through source code analysis alone.
Description
Dynamic Application Security Testing (DAST) analyses applications in their running state by sending crafted requests to exposed endpoints and observing the responses. Unlike SAST, which examines source code, DAST tests the application as an attacker would — through its HTTP interfaces, APIs, and authentication flows — making it effective at finding runtime and configuration vulnerabilities such as injection flaws, broken authentication, security misconfigurations, and sensitive data exposure. DAST is language- and framework-agnostic because it operates against the deployed artefact rather than the code. In regulated financial services environments, DAST provides evidence that applications have been tested against real attack scenarios prior to production release and on an ongoing basis thereafter.
Requirements
- DAST MUST be performed against web applications and APIs as part of the software development lifecycle
- DAST MUST be automated — manual-only dynamic testing is not sufficient as a primary control
- The frequency and trigger points for DAST scans MUST be defined based on release cadence, application risk profile, and deployment model
- DAST tooling MUST be configured to test against the OWASP Top 10 vulnerability categories at a minimum
- Authenticated scanning MUST be performed where applicable to test functionality behind login flows, ensuring coverage of authorisation and session management vulnerabilities
- API-specific scanning MUST be performed for all REST, GraphQL, and other API endpoints, using OpenAPI specifications or equivalent API definitions where available
- DAST scans MUST be executed in environments that do not compromise production data integrity — production-equivalent staging environments are preferred
- DAST results, including findings, remediation actions, and exceptions, MUST be retained in accordance with the organisation’s record retention policy
Examples & Commentary
- Pipeline Integration: Trigger DAST scans automatically after deployment to a staging environment as part of the CI/CD pipeline. Gate promotion to production on scan results
- Authenticated vs Unauthenticated Scans: Run both unauthenticated scans (simulating an external attacker) and authenticated scans (simulating a logged-in user) to maximise coverage of the application’s attack surface
- API Contract Testing: Feed OpenAPI/Swagger specifications into DAST tooling to ensure all documented endpoints are tested, including edge cases such as malformed inputs, missing authentication headers, and parameter tampering
- Crawl Depth & Coverage: Configure scan policies to adequately crawl modern single-page applications (SPAs) and JavaScript-heavy frontends, which may require headless browser-based scanning capabilities
- Environment Considerations: DAST generates real traffic and may modify application state. Use dedicated staging environments with synthetic data, and ensure scans do not trigger denial-of-service conditions or corrupt shared test data
- Complementing SAST: DAST and SAST are complementary — SAST finds issues in code that may not be reachable at runtime, while DAST finds runtime and configuration issues invisible to static analysis. Both should be used together for defence in depth