What is DAST? Dynamic Application Security Testing Explained (2026)

What DAST actually does

Dynamic Application Security Testing finds vulnerabilities by attacking your running application from the outside. It crawls your web app, discovers forms and endpoints, fires malicious payloads at them, and watches what happens.

No source code needed. No knowledge of what language or framework you used. DAST treats the application as a black box, the same way an attacker would.

That is what makes DAST different from SAST. SAST reads your code and looks for dangerous patterns. DAST does not care about your code. It cares about how your application actually behaves when someone sends it ' OR 1=1-- in a login field.

I spent almost 5 years working in the DAST industry, and the biggest shift I have seen is the move from standalone scanning tools for pentesters to CI/CD-integrated scanners that run automatically on every release. The technology is the same, but the workflow has changed completely.

Mordor Intelligence estimates the DAST market reached $3.61 billion in 2025 and will grow to $8.52 billion by 2030, driven by the shift to DevSecOps and the need for automated runtime testing alongside static analysis.

How dynamic scanning works

A DAST scan follows a predictable sequence. Knowing how it works helps you troubleshoot when a scan misses something you expected it to find.

Crawling

The scanner starts by mapping the application. It follows links, submits forms, clicks buttons, and builds a model of every page and endpoint it can reach. Modern tools use headless browsers (Chromium under the hood) to handle JavaScript-heavy applications.

Crawling is where DAST tools differ the most. A weak crawler misses pages and endpoints, which means missed vulnerabilities. For Single-Page Applications where content loads dynamically, the crawler needs to execute JavaScript and wait for DOM changes. Not all tools do this well.

Attack and fuzzing

Once the application is mapped, the scanner sends crafted payloads to every input it found: form fields, URL parameters, headers, cookies, JSON body parameters. SQL injection payloads for database-backed inputs. XSS payloads for fields rendered in HTML. Command injection payloads for inputs that might reach system calls.

The scanner watches how the application responds. A database error message after a SQL injection payload suggests the vulnerability is real. Reflected script content in the response body confirms XSS.

Authentication testing

DAST tools test login mechanisms, session management, and access controls. Good tools support multi-step login sequences, token-based authentication, and role-based testing where you scan as different user roles to check for privilege escalation.

Getting authentication right is the trickiest part of setting up a DAST scan. If the scanner cannot stay logged in, it only tests the unauthenticated attack surface, which is a small fraction of most applications.

Reporting and verification

Results get ranked by severity, usually mapped to OWASP Top 10 or CWE categories. Some tools go further. Invicti uses proof-based scanning that automatically confirms vulnerabilities by extracting actual data (like a database version string) rather than just flagging a suspicious response. False positive rates drop close to zero for confirmed findings.

What DAST catches

DAST is good at finding vulnerabilities that depend on runtime behavior:

SQL injection — The classic. DAST sends malicious SQL in input fields and watches for database errors or data leakage in responses.
Cross-site scripting (XSS) — The scanner injects script payloads and checks whether they get reflected or stored and rendered.
Server misconfigurations — Missing security headers, verbose error messages, directory listing enabled, default credentials. These are invisible to source code analysis.
Authentication and session issues — Weak session tokens, missing logout functionality, session fixation, insecure cookie attributes.
Broken access control — The scanner tests whether it can access resources it should not be able to reach, including horizontal and vertical privilege escalation.
Security header issues — Missing or misconfigured Content-Security-Policy, X-Frame-Options, HSTS, and other headers that protect against common attacks.

DAST catches these because it tests the application as it actually runs. Server misconfigurations and authentication issues do not exist in source code. They only exist in running applications.

Where DAST falls short

DAST has real limitations. Knowing them helps you decide where to supplement it.

No code location. DAST tells you a SQL injection exists at /api/users?id=123, but not which file and line is responsible. Developers still need to track down the vulnerable code. IAST solves this by combining runtime detection with code-level visibility.

Crawl coverage gaps. DAST can only test what it can find. Pages hidden behind complex multi-step workflows or state-dependent interfaces get missed. Some teams supplement automated crawling with manual exploration using Burp Suite.

Speed. A full DAST scan takes hours. Fine for nightly builds, too slow for pull request feedback. Dastardly and ZAP baseline scans address this with quick scan modes, but they trade thoroughness for speed.

SPA challenges. Single-Page Applications built with React, Angular, or Vue load content dynamically through JavaScript. Older DAST tools that rely on HTML parsing miss these entirely. Modern tools use headless browsers, but SPA coverage still varies between products.

Business logic flaws. Like SAST, DAST cannot understand your application’s business rules. If a discount code can be applied twice because of a logic error, no scanner will find it.

DAST in your CI/CD pipeline

The days of running a DAST scan once a quarter and emailing a PDF report are over. Modern DAST fits into automated pipelines, though the setup differs from SAST.

The catch: DAST needs a running application. Your pipeline needs to deploy to a staging environment before the scan can start.

Quick scans on every PR

Use lightweight tools that finish in minutes. Dastardly has a built-in 10-minute cap. ZAP baseline scans run in under 5 minutes. Nuclei with targeted templates finishes quickly. Not comprehensive, but they catch regressions and obvious issues fast.

Full crawls on nightly or weekly builds

Schedule thorough DAST scans outside the PR workflow. A full crawl with Invicti, HCL AppScan, or Veracode DAST against staging takes hours and covers more ground. Run it nightly and review results in the morning.

Quality gates

Block production deploys when critical findings appear. Invicti, StackHawk, and HCL AppScan have CI/CD integrations that can fail a pipeline based on finding severity.

DAST for APIs and SPAs

Traditional DAST was built for server-rendered web pages. Modern applications look different: SPAs with React frontends talking to REST or GraphQL APIs. The tools have had to adapt.

API scanning

Most DAST tools now support API scanning by importing OpenAPI/Swagger specs or Postman collections. The tool reads the spec, understands the endpoints and parameter types, and tests each one for injection, broken authentication, and data exposure.

Escape is built specifically for API and business logic testing. StackHawk has strong API scanning through its HawkAI feature. Tenable WAS handles REST, GraphQL, and SOAP APIs.

For API-heavy architectures, dedicated API scanning is more effective than forcing a traditional web scanner to understand your API.

SPA scanning

For SPAs, you need a DAST tool that uses a real browser engine to render JavaScript and interact with the DOM. Burp Suite, Invicti, and HCL AppScan handle SPAs better than most. Always verify that the tool can discover your SPA’s routes and interact with dynamic content before committing to it.

Top DAST tools

These are the tools I would look at first. For full reviews and comparisons, see the DAST tools page.

Free and open-source

ZAP — The most popular open-source DAST tool. Now maintained by Checkmarx. Works for both manual testing and CI/CD automation.
Nuclei — Template-based scanner with 9,000+ community templates from ProjectDiscovery. Fast, precise, and great for targeted scanning.
Dastardly — Free CI/CD scanner from PortSwigger. The 10-minute scan cap makes it practical for pipelines.
Wapiti — Python-based black-box fuzzer. Good for XSS, SQL injection, and XXE detection.
Nikto — Classic web server scanner with 7,000+ checks. Fast but focuses on server-level issues rather than application logic.

Commercial

Burp Suite — The industry standard for manual penetration testing. Burp Suite Professional adds automation. PortSwigger also offers Burp Suite Enterprise for team use.
Invicti — Proof-based scanning with automatic vulnerability confirmation. Scales to thousands of applications.
HCL AppScan — Gartner Leader in 2025. AppScan 360 platform with DAST + SAST + IAST.
StackHawk — Developer-first DAST built on ZAP. Good API scanning and CI/CD integration.
Veracode Dynamic Analysis — Part of the Veracode platform. Gartner Leader in 2025.

Getting started

If you have never run DAST before, here is a practical path.

Set up a staging environment. DAST needs a running application. Never scan production directly unless you understand the risks (DAST sends malicious payloads that can create test data or trigger errors).

Start with a free tool. ZAP is the safest starting point. Well-documented, large community, runs everywhere. Install it, point it at your staging URL, run a baseline scan.

Configure authentication. Your first scan will only cover the unauthenticated surface. Set up the scanner with login credentials to test authenticated functionality. This is where most people get stuck, so allocate time for it.

Review and triage results. Go through the findings. Verify the real ones, dismiss the false positives. DAST false positive rates are lower than SAST, but not zero.

Add it to CI. Once you trust the results, integrate the tool into your pipeline. Quick scans on PRs, full scans nightly.

Consider adding SAST. DAST covers runtime behavior. SAST covers your source code. Together they give you much better coverage than either alone. See our SAST vs DAST vs IAST comparison for guidance on combining approaches.

FAQ

Written by

Suphi Cankurt

Suphi Cankurt works at Invicti Security and has spent over 10 years in application security. He reviews and compares AppSec tools across 10 categories on AppSec Santa. Learn more.