What Is Dynamic Application Security Testing (DAST)?

A scanner that never sees your source code can still find the SQL injection that empties your database. It sends a crafted request to the login form, watches a database error leak back in the response, and flags the endpoint. That is dynamic application security testing: testing a running application from the outside, the way an attacker would, with no access to the code behind it.

DAST is the black-box half of application security. Where static analysis reads the source at rest, DAST attacks the deployed build in motion and reports what actually breaks. It catches the flaws that only exist once the app is running: authentication bypasses, session handling errors, server misconfiguration, and injection that depends on the live stack. It is language-agnostic, because it never reads a line of the code it is testing.

This guide covers what DAST is, how it works step by step, the vulnerabilities it finds, how it differs from static testing, where it fits the development pipeline, its real limitations, and how a defender reads its output. It is written for blue teamers: SOC analysts, AppSec engineers, and responders who have to turn a scanner finding into a decision.

What is dynamic application security testing?

Dynamic application security testing (DAST) is a method that evaluates an application's security by testing it at runtime, from the outside, without access to its underlying source code. It interacts with the running application through its exposed interfaces, the same HTTP endpoints, forms, and APIs a user or an attacker would reach, and it judges security by how the application responds.

This is why DAST is called black-box testing. The scanner knows nothing about the internal structure of the application. It only sees inputs and outputs, so it tests the application as deployed, including the web server, the configuration, and the runtime dependencies, not just the code a developer wrote. A flaw that appears only because of how the app is configured in production is exactly the kind DAST is built to find.

The output is a list of findings tied to a request and a response, not to a line of code. A DAST tool reports that a specific parameter on a specific endpoint produced a response indicating injection, or that a session token did not change after login. That is both its strength and its limit: it proves the application behaves insecurely, but it cannot tell you which function to fix.

DAST sits inside the broader practice of application security testing, the family of methods that also includes static analysis (SAST), interactive analysis (IAST), and software composition analysis (SCA). DAST is the one that treats the running application as the target. It probes the same login and session flows where threats like credential stuffing and broken authentication live.

How DAST works

A DAST scan runs against a deployed application in a test or staging environment, never against the source repository. The sequence is consistent across tools.

1. Point the scanner at a running target. DAST needs a live, reachable application, typically a staging or pre-production build that mirrors production. No source code, no build artifacts, just a URL and, often, credentials so the scanner can test authenticated areas.
2. Crawl to map the attack surface. The scanner spiders the application to discover its endpoints, forms, parameters, and APIs. Coverage of the scan depends entirely on this step: a path the crawler never finds is a path the scanner never tests.
3. Send crafted, malicious inputs. Against each discovered input the scanner fires attack payloads, malformed values, injection strings, manipulated parameters, the same kinds of requests an attacker would send through the exposed interfaces.
4. Analyze the responses. The scanner reads what comes back: error messages, status codes, response timing, reflected content, and changes in application behavior. A database error returned to the browser, an unsanitized payload reflected in the page, or a redirect to an attacker-controlled host each signals a class of vulnerability.
5. Report findings with evidence. Each finding ships with the request that triggered it and the response that proved it, so a triager can reproduce the result. The finding names the vulnerability class and the affected endpoint, not the source line.

Because every step works through the application's external interfaces, DAST is language-agnostic and framework-agnostic. The same scan logic works against a Java monolith, a Node API, or a third-party service you do not have the source for.

Vulnerabilities DAST finds

DAST catches the flaws that surface during execution, the ones an attacker can reach by sending requests. The classic catches include:

• Injection, especially SQL injection, where unsanitized input reaches a backend query and the response leaks data or a database error.
• Cross-site scripting (XSS), where attacker-controlled input is reflected or stored and runs as script in another user's browser.
• Authentication and session flaws, including authentication bypass, weak or guessable credentials, and session tokens that do not rotate after login.
• Server and security misconfiguration, such as exposed admin interfaces, verbose error pages, or missing security headers visible only on the deployed stack.
• Unvalidated redirects and forwards, where an endpoint sends the user to an attacker-controlled destination.
• Business logic flaws that only appear when real request sequences exercise the application's workflow.

These map onto the web application risks catalogued in the OWASP Top 10, the industry reference list of the most critical web application security risks, whose current edition is the 2025 release. A DAST finding of "reflected XSS" or "SQL injection" is not an abstract score; it is an entry point an attacker would use.

DAST vs SAST

The cleanest way to understand DAST is against its opposite. Static application security testing (SAST) reads the source code at rest without running it. DAST attacks the application in motion without reading the code. They see different things and run at different times, which is why mature programs run both.

Three points matter more than the cells.

First, the two are complements, not rivals. SAST sees the code but not the running behavior; DAST sees the behavior but not the code. A flaw that SAST flags as a risky pattern, DAST confirms as actually exploitable, or never reaches at all because the path is dead. Running only one leaves a structural blind spot.

Second, they remediate differently. A SAST finding points at a file and a line, so a developer fixes it directly. A DAST finding points at an endpoint and a payload, so someone has to trace the bad response back to the code that produced it. DAST proves the bug exists; it does not hand you the fix location.

Third, they run at different stages, so you sequence them rather than choose. SAST fires on commit, where fixes are cheapest. DAST runs later, against a deployed build, as the backstop for everything that only appears at runtime.

Where DAST fits in the pipeline

DAST is most useful wired into the continuous integration and delivery (CI/CD) pipeline as an automated gate, not run once as a pre-launch audit. The natural home is the stage where a real, deployed build exists.

On commit, static analysis and secrets scanning run first, in the IDE and on every push, because they need only the code. These are the cheapest gates and they catch most code-level flaws before a build exists.

Against a staging or test build, DAST attacks the deployed application the way an external attacker would. This is where runtime and configuration flaws surface, the ones the earlier static gates structurally cannot see. Teams often run a fast, targeted DAST scan on each build and a fuller scan on a schedule, because a complete crawl-and-attack pass is slow. A failed gate here blocks promotion to production.

In production, the testing handoff becomes monitoring and runtime defense. Runtime application self-protection (RASP) and web application firewalls run inside or in front of the live application and block exploit attempts in real time. These are defenses, not testing methods. DAST finds the flaw before release; RASP and the WAF mitigate attacks against the running system after it.

The principle is the same one that makes layered detection useful to defenders: place a control at every stage so a flaw that slips one gate trips another. Pushing DAST into CI/CD shifts that catch earlier, but it stays a runtime check, because that is the only place its target exists. This wiring of security checks into the development pipeline is the discipline of DevSecOps, and DAST is one of its instruments. It is also a core piece of cloud security, where deployed applications and their exposed APIs are the attack surface.

Limitations of DAST

DAST is not a complete program on its own, and treating it like one creates false confidence. Its limits are the mirror image of its strengths.

No code pointer. DAST tells you an endpoint is exploitable, not which function or line is wrong. Remediation starts with a request-and-response pair and a developer who has to find the cause. This is slower than fixing a SAST finding that names the file.

Coverage is only as good as the crawl. DAST tests the paths it can discover and reach. Endpoints hidden behind complex multi-step workflows, single-page-app routes the crawler cannot follow, or authentication it cannot complete are simply never tested. A clean DAST report can mean a secure app or an under-crawled one.

It runs late and slowly. Because DAST needs a deployed build, it catches flaws later in the lifecycle, where fixes cost more than they would on commit. A thorough scan that exercises every input is also resource-intensive and time-consuming, which is why teams scope incremental scans during development and run full scans less often.

Authentication is hard to configure. Modern auth (multi-factor, single sign-on, token rotation) can break a scanner's session mid-scan, causing it to test only the unauthenticated surface. Misconfigured authentication is a common cause of both false negatives, the scanner missed the protected area, and wasted scans.

Findings need tuning. Out of the box, DAST produces false positives and false negatives. The fix is ongoing work: tune the configuration, refine the filters that suppress noise, and confirm findings before routing them. An untuned scanner either drowns the team in alerts or quietly misses real flaws.

The practical conclusion is that DAST belongs in a stack, alongside SAST, IAST, SCA, and manual penetration testing, not as a standalone guarantee.

How blue teams read DAST output

DAST output is a build-pipeline artifact, but it lands on the blue team during triage, vulnerability management, and incident response. Reading it well is a defender skill.

Confirm exploitability before escalating. A DAST report is a list of candidate flaws, not confirmed breaches. The first job is reproducing the finding from the request-and-response evidence the scanner attached, and discarding the false positives. A confirmed SQL injection on a public endpoint is a different priority than a flagged redirect on an internal admin page.

Read each finding as attacker capability. A reflected-XSS or auth-bypass finding is not a number on a dashboard. It is an action an adversary could take. Translating "this endpoint is injectable" into "an attacker reads the user table from here" is the same instinct used in API security review and threat modeling, and it is what turns a scan result into a risk decision.

Feed findings into incident response. When an application is breached, the DAST history is evidence. Accepted or deferred findings are a map of where the weakness probably was, and the endpoint inventory the scanner built scopes the investigation faster. A responder who knows the app's known runtime flaws does not start from zero.

Close the loop. Every confirmed finding should become a fix and, where possible, a detection or a WAF rule. A recurring class of finding, the same injection pattern across services, points at a missing secure-coding standard or a gap in the pipeline gates. DAST is most valuable when its output changes how the next build ships, not just what gets patched this week.

Frequently Asked Questions

What is dynamic application security testing (DAST)?

Dynamic application security testing (DAST) is a method that evaluates a running application's security from the outside, without access to its source code. It sends crafted requests through the application's exposed interfaces and analyzes the responses to find runtime vulnerabilities like injection, authentication flaws, and misconfiguration. Because it never reads the code, it is language-agnostic and tests the application as actually deployed.

What is the difference between DAST and SAST?

SAST (static testing) reads the source code at rest without running the application and catches code-level flaws like injection patterns and hardcoded secrets early, but it cannot see runtime behavior and produces false positives. DAST (dynamic testing) attacks the running application from the outside and catches authentication, session, and configuration flaws that only appear at runtime, but it cannot point to the offending line of code. They are complements: SAST runs on commit, DAST runs against a deployed build, and a mature program uses both.

What vulnerabilities does DAST detect?

DAST detects flaws that surface at runtime: SQL injection, cross-site scripting (XSS), authentication and session-management flaws, server and security misconfiguration, unvalidated redirects, and some business logic flaws. These map onto the OWASP Top 10 web application risks. It does not detect issues that live purely in source code, such as a hardcoded secret in a file path the application never reaches at runtime.

When in the SDLC should DAST run?

DAST runs against a deployed build, so it fits the test and staging stages rather than the commit stage. Wired into CI/CD, it runs as an automated gate on each build, often as a fast targeted scan with a fuller scan on a schedule, and a failed gate blocks promotion to production. Static analysis and secrets scanning run earlier on commit; DAST is the runtime backstop.

Is DAST black-box or white-box testing?

DAST is black-box testing. The scanner has no knowledge of the application's internal structure or source code and judges security only by the inputs it sends and the outputs it gets back. SAST, by contrast, is white-box: it has full visibility into the source code. IAST is sometimes called gray-box, because an in-application agent gives it partial internal visibility while the app runs.

Can DAST be automated in CI/CD?

Yes. DAST tools integrate into CI/CD pipelines and run automatically against a staging build on each commit or release, returning findings to developers as a gate. Because a full crawl-and-attack pass is slow, teams typically run incremental or targeted scans during active development and reserve comprehensive scans for scheduled runs or pre-release.

The bottom line

DAST tests a running application from the outside, with no access to its source code, and finds the flaws that only appear at runtime: injection, authentication and session errors, misconfiguration, and unvalidated redirects. It is the black-box complement to static analysis, language-agnostic, and most useful as an automated gate against a staging build in the CI/CD pipeline.

Its limits are real and the reason it is never run alone: no code pointer, coverage bounded by the crawl, late and slow scans, and findings that need tuning. Run it alongside SAST, IAST, SCA, and manual testing, and read its output the way a defender should, confirming exploitability, mapping each finding to attacker capability, and closing the loop so the next build ships fewer flaws.