Many development teams rely on static code analysis and manual reviews. While these are important components of secure software development, they cannot cover every security risk. Vulnerabilities do not arise solely from the source code itself; they can also emerge from component interactions at runtime, or from deployment configurations, dependencies, or runtime behavior – factors that cannot be fully captured by static analysis.

Dynamic Application Security Testing (DAST) closes this security gap by testing a running web application or API from an attacker’s perspective. This allows for the identification of vulnerabilities that only become visible during operation.

In this article, you will learn how DAST works, which vulnerabilities can be identified, where the method’s limitations lie, and how DAST can be meaningfully integrated into CI/CD processes.

How Does DAST Work?

DAST examines applications from the perspective of external attackers. To this end, the scanner sends automated test requests to the application and analyzes the responses generated in return. Unlike static methods, this approach does not inspect the source code, but rather the application’s actual runtime behavior.

The Four Phases of a DAST Scan

1. Discovery: A spider or crawler analyzes the application and records reachable endpoints, parameters, and forms.
2. Authentication: The scanner performs the login process and manages session information for authenticated scans.
3. Attack simulation: The scanner sends automated test requests with generic payloads to detected input points and analyzes the application’s responses.
4. Reporting: Identified vulnerabilities are classified by severity and documented along with technical evidence.

As a general rule: DAST requires a running environment. Scans against production systems are not recommended because they may modify database entries or affect services. The appropriate environment is a dedicated staging environment configured as closely as possible to production.

Shift Left: Integrating Security Early On

Shift left refers to the approach of integrating security testing as early as possible in the development cycle. Vulnerabilities identified during development can thus be fixed with far less effort.

Once deployed, remediation of an issue becomes significantly more complex. Studies show that fixing vulnerabilities in later phases can be 10 to 100 times more expensive. Security testing is not limited to just the source code. DAST consistently extends the shift-left principle into the runtime phase. A DAST scan that runs automatically against a freshly deployed staging environment with every nightly build or merge request puts the shift-left principle into practice for an application’s runtime behavior.

Why Is Authenticated Scanning Crucial?

The most security-relevant part of an application is almost always found after the login: data management, transactions, authorization logic, and administrative functions – a DAST scan limited to publicly accessible endpoints only checks the surface and may provide an incomplete – or, in the worst case, even misleading – picture of the real attack surface.

NO AUTHENTICATED SCANNING = NO MEANINGFUL SCAN

Authenticated scanning means that the DAST tool performs the login process automatically and manages session tokens throughout the scan. In practice, this requires careful configuration, especially for modern authentication methods such as OAuth 2.0 or OIDC.

OWASP ZAP, the best-known open-source DAST tool, supports several authentication methods, including form-based logins, script-based flows for complex scenarios, and automatic detection of login mechanisms. Configuration is typically handled through the Automation Framework, a YAML-based configuration file that allows the entire scan workflow to be described and versioned as code.

What Are the Benefits and Limitations of DAST?

DAST uses automated testing methods, known attack patterns, and generic payloads to detect vulnerabilities in an application’s runtime behavior. While this automation is a major strength, it also creates limitations when context or in-depth application knowledge is required.

Where DAST Can Provide Valuable Indicators

• Possible injection attack vectors: SQL, command, or SSTI injection through known payloads and noticeable differences in application behavior
• Potential XSS vectors: especially reflected XSS and, in some cases, DOM-based scenarios in detected input paths
• Misconfigurations: missing security headers, exposed administrative interfaces, or insecure cookie configurations
• Weak session management: faulty session handling or obvious weaknesses in authentication flows
• Insecure access patterns: detectable IDOR patterns or insecure redirects
• Insufficiently protected API endpoints: for REST APIs, ideally based on an OpenAPI/Swagger specification, because traditional crawling often reaches its limits with API-heavy applications and single-page applications (SPAs) such as React, Vue, or Angular

Where DAST Reaches Its Limits

• Context-dependent and complex injections that require specific knowledge of the application
• Business logic flaws because a scanner does not know an application’s business requirements
• Stored XSS in complex application flows with multi-step workflows
• Authorization flaws between roles that can only be identified through manual analysis

Where is DAST in the CI/CD Pipeline?

DAST provides the greatest value when it is not used as a one-time check, but as a recurring part of the deployment process. This allows release candidates to be tested automatically before they reach production.

To get started, OWASP ZAP with the official Docker image is recommended. The included scripts distinguish between two operating modes:

• zap-baseline.py for fast CI checks with passive tests and low application load
• zap-full-scan.py for active scans with full attack simulation, suitable for nightly builds or before major releases

Those who need authenticated scanning, API import, or custom scan policies can use the scripts as a starting point and extend them with their own YAML configuration through the Automation Framework.

A note on modern architectures: Traditional crawlers can reach their limits with single-page applications (e.g., React, Vue, or Angular). JavaScript-rendered content and complex state handling may not be captured completely. For API-heavy applications, directly importing an OpenAPI or Swagger specification as the basis for scanning is recommended. This significantly increases coverage and is more precise than crawling alone.

A structured quality gate automates the decision: Findings at or above a defined severity level block the deployment process. Configuration, target URL, authentication, scan depth, and exclusion lists are maintained as a YAML file in the repository and are versioned and reviewed just like code.

How Does DAST Differ From Static Tests (SAST)?

In application security, static and dynamic testing methods complement each other. Both follow different approaches and examine the application from different perspectives.

The recommendation is not SAST or DAST, but a combination of both:

• SAST early in the development process to review source code
• DAST in the staging environment to validate runtime behavior

Using both methods provides coverage across the development cycle, with each method applied where it delivers the most value.

How Does DAST Help With Compliance?

DAST also provides concrete value from a compliance perspective:

• PCI DSS v4.0 explicitly requires security testing for web-based applications.
• ISO 27001 Control 8.29 requires demonstrable security testing in the development process.
• The EU Cyber Resilience Act requires manufacturers of digital products to provide evidence of systematic security testing starting in 2027. An automated, versioned DAST process is one of the few approaches that can fully document compliance with these requirements.

What Are Common Mistakes When Using DAST?

Based on our experience in security consulting, similar challenges repeatedly arise when using Dynamic Application Security Testing. The following mistakes should be avoided:

• Scanning only once a year – DAST should run continuously, not only right before the annual penetration test. Every code change can introduce new vulnerabilities.
• Scanning against production – Active scans can modify database entries and affect services. Testing should always be performed against an isolated staging environment.
• Scanning without authentication only – The relevant parts of the application are usually behind the login. Without authenticated scanning, results remain incomplete.
• No process or budget for findings – DAST can initially generate a large number of findings, some of which may be false positives, that need to be assessed. Those who do not have a defined remediation process and do not allocate sufficient capacity to their teams to address these issues will stop using DAST after the first scan. The process, responsibilities, and remediation budget should be in place before scanning begins.
• Using DAST as a replacement for penetration testing – DAST can automate the detection of known patterns, but business logic flaws and application-specific vulnerabilities require experienced testers. DAST should therefore be viewed not as a replacement, but as a complement to penetration testing and other security processes.

Conclusion and Next Steps

Web applications and APIs are among the most common entry points for cyberattacks (Data Breach Report). Those who check only the source code for security risks may overlook potential threats that emerge during operation. DAST closes this gap in an automated, reproducible, and auditable way.

The business logic is clear: The earlier vulnerabilities are found, the less expensive they are to fix. Making DAST an integral part of the deployment process shifts the point at which vulnerabilities are detected from the production environment to the staging environment, thereby reducing both costs and risks.

A practical first step is to run a baseline scan in a staging environment. The results reveal the largest gaps and provide the foundation for a structured application security strategy.