Dynamic Application Security Testing: What DAST Finds and What It Misses

Picture a release that did everything right. The Dynamic application security testing scan ran against staging the night before and reported eleven low-severity findings: a missing header, a cookie flag, a server banner. The release shipped on time.

Three weeks later a customer emailed support. She had changed one number in her invoice download link, from 10452 to 10453, and received someone else’s invoice.

The scanner had requested that same endpoint. To a scanner, a 200 OK carrying a well-formed PDF is a success. It doesn’t know who owns invoice 10453, so it can’t know the wrong person just downloaded it.

That flaw is an insecure direct object reference, part of Broken Access Control, and number one in the OWASP Top 10:2025. In the data behind that list, every application tested had some form of broken access control. And this kind, where the wrong person gets a perfectly valid response, is exactly what dynamic application security testing struggles to see.

This isn’t an argument against DAST. It’s still the part of application security testing that sees your software the way an attacker does: running, deployed and reachable. But a DAST report describes only what the scanner could reach and recognize, on the day it ran. Here’s what that includes, what it leaves out, why the queue fills with noise, and how DAST compares with SAST and pen testing.

How Dynamic Application Security Testing Works

Dynamic application security testing (DAST) examines a running application from the outside, with no access to its source code. It’s a black-box method: the scanner knows only what an attacker would know, which is whatever the application exposes over HTTP.

A DAST scan works in three stages:

• Discover. Map the attack surface by crawling links, driving a headless browser through JavaScript-heavy pages and, in better scans, importing API definitions, because a crawler can’t find an endpoint nothing links to.
• Attack. Send crafted input into every parameter, header and cookie it found: SQL fragments, script tags, path traversal strings, oversized values.
• Observe. Read the responses for evidence. A database error after a single quote. A script reflected back un-escaped. A reply that arrives exactly five seconds late when the payload asked the database to sleep for five.

Most scanners also run passive checks on the traffic they see, flagging missing security headers, insecure cookies and sensitive data in URLs.

That outside-in view is DAST’s real strength. It doesn’t care what language the app is written in, and it tests third-party and legacy code you have no source for. It also finds problems that only exist once everything is deployed together: a proxy leaking internal headers, a framework left in debug mode, a TLS setting changed on the load balancer. Of all the methods in application security testing, it’s the one that tests the system you actually run from where an attacker stands, rather than the code you meant to ship.

The same view is also its limit. DAST sees responses, not intentions. It can tell that a request succeeded. It can’t tell whether it should have.

Coverage: The Variable Nobody Reports

Every DAST report lists what the scanner found. Very few lead with what it tested. Yet coverage decides whether a clean report means anything, and it collapses in four predictable places.

1. The login page

Most of what matters in a business application sits behind a login. A scanner that can’t sign in, or quietly loses its session ten minutes in, spends the run testing the login form and public pages. Timeouts, CSRF tokens, single sign-on and multi-factor prompts all break simple login scripts. Crawlers also find the logout link and click it, the most efficient way yet invented to end an authenticated scan.

Authenticated scanning fixes this, but only if someone checks it’s working. A good configuration defines a logged-in indicator, text that only appears in a valid session, so the scanner notices when it’s been signed out. It excludes logout URLs. And it scans as more than one role, because an administrator and a clerk are effectively using different applications.

The most dangerous DAST result isn’t a critical finding. It’s a clean report on a scan that never got past the login page.

2. Multi-step flows

A checkout or approval chain only reaches its interesting code once earlier steps have created the right state. A crawler that lands on step three without steps one and two gets an error page and moves on. Validation does the same thing quietly: if a required field only accepts a valid VAT number and the scanner fills it with a placeholder, every submission fails, and the payloads in the other fields never reach the code.

3. Single-page applications

Classic crawlers read HTML links, but a React or Angular front end builds its routes in JavaScript and calls APIs the HTML never mentions. Modern scanners drive a real browser to compensate, yet they only see the states they click into. A filter panel nobody opens is a set of parameters nobody tests.

4. APIs nobody linked

Mobile back ends, partner integrations, admin endpoints and the old /v1/ API nobody switched off don’t appear on any page a crawler can follow. Without an API definition, the scanner doesn’t know they exist.

None of these failures produces an error. Each produces a shorter, cleaner report. So before trusting a result, check three numbers: endpoints scanned against endpoints in your API inventory; the share of 401, 403 and login-redirect responses, the signature of a lost session; and how many signed-in-only pages appear in the crawl.

What DAST Finds and Misses: The OWASP Top 10:2025 Map

The OWASP Top 10:2025 is the closest thing application security has to a shared vocabulary, which makes it the fairest yardstick for DAST coverage. Here’s how dynamic testing does against each category.

Ratings are our assessment, not OWASP’s, and assume an authenticated scan with API definitions imported. Without those, most ratings drop.

On that reading, DAST is strong in two categories, partial in four, weak in two and blind in two. It’s strongest where a flaw leaves evidence in a single response, such as an error message or a reflected script. It’s weakest where the problem is a correct-looking response sent to the wrong person, or a process that completed when it should have failed.

A10, new in 2025, shows the split. A scanner is very good at provoking exceptions and spotting stack traces. It can’t tell whether the application failed safely or failed open. OWASP’s own A10 examples include financial transactions left corrupted after an incomplete rollback, which you only catch by checking the ledger, not the HTTP response.

A FREE DETECTION DRILL FOR A09 DAST can’t test A09, but every active scan is a free drill for it. Next time a scan fires its thousands of payloads at an environment with production-grade monitoring, ask your security operations team what they saw. If nobody was alerted, you’ve found a logging and alerting failure without writing a test.

Your Scanner Passed. Your App Still Got Breached. Here’s Why.

When a breach follows a clean scan, the post-mortem usually lands on one of four explanations. Knowing which applies tells you what to fix, and it’s rarely the scanner.

It didn’t reach the flaw

The endpoint sat behind a login the scanner lost, at the end of a flow it couldn’t complete, or in an API nobody described to it. It’s the most common explanation and the cheapest to fix, because it’s configuration, not capability.

It reached the flaw but couldn’t recognize it

The invoice story. The response was well formed, and nothing about it was wrong apart from who received it. Authorization flaws and business-logic abuse look exactly like normal use. No payload library catches them, because there is no payload.

It ran before the flaw existed

A quarterly scan tests the code deployed that week. A team shipping daily has pushed around sixty releases since, each able to add an endpoint, change a permission or upgrade a component. The scan was right about the application it tested. That application no longer exists.

It found the flaw and nobody acted

The finding was rated medium, below the pipeline’s fail-on-high gate. Or it sat on page nine of 300 results. Or someone marked it a false positive while clearing the queue on a Friday afternoon. Scanners rarely fail silently. Triage does.

Only the second explanation is a hard limit of the technology. The other three are about how DAST is run, so they can be fixed.

Access Control and Business Logic: Where DAST Stops

To catch the invoice bug, a test needs two things the scanner doesn’t have: a list of users, and what each should be allowed to do.

That’s an authorization matrix: roles down one side, resources and actions across the top, an expected answer in every cell. Can a clerk approve a payment? Can customer A read customer B’s order? The tests follow simply: sign in as user B, request user A’s object, expect a refusal. Some scanners and proxy extensions can run these comparisons across sessions, but only someone who knows the business can supply the matrix.

Business-logic abuse works the same way. A negative quantity that turns a purchase into a refund. A discount code applied twice. A request that skips straight to order confirmation. Two refunds submitted in the same instant, both approved. Each returns a normal response, so the only way to catch them is to check the outcome: the order total, the balance, the approval status.

In ERP systems this problem has an older name. Segregation of duties is an authorization matrix with audit consequences: whoever creates a supplier shouldn’t approve its payments. Our guide to segregation of duties testing covers verifying it when AI agents hold roles of their own.

Three practices cover the ground DAST can’t:

• Threat modelling before a feature is built, asking what a malicious or careless user could make it do. The output is a list of abuse cases.
• Outcome-based abuse-case tests that turn that list into automated checks, run alongside functional regression on every release.
• Human penetration testers for the chains no list anticipates: an error message revealing an ID format, plus a missing ownership check, plus a bulk export.

Why DAST False Positives Eat Your Review Time

Ask a security engineer what they dislike about DAST and the answer is usually the queue. False positives are a structural consequence of black-box testing, not a sign of a bad tool: the scanner infers vulnerabilities from indirect evidence, and indirect evidence is ambiguous. The usual sources:

• Timing checks. Blind SQL injection is detected by asking the database to pause. A slow server or network jitter looks identical.
• Encoded reflections. The payload comes back, but encoded or somewhere it can’t execute.
• Soft 404s and generic errors. A 200 OK saying “page not found”, or one error page for everything, makes every probe look like a discovery.
• WAF interference. Block pages and rate limits resemble evidence, and they also hide real flaws from the scanner.
• True but irrelevant. A missing header on a static image. Not false, just not worth an afternoon.
• Duplicates. One vulnerable search component on 200 pages is one fix, reported 200 times.

A playbook for draining the queue

• Demand evidence. Every finding should carry the request, the response and the reason it was flagged. Reproduce before you raise a ticket.
• Tune the policy to your stack. PHP checks against a .NET application only generate noise.
• De-duplicate by root cause, grouping findings by component and parameter rather than by URL.
• Scan the application, not the WAF. Allow-list the scanner in test environments and assess the WAF as a separate control.
• Suppress with a reason and an expiry date. A permanent false-positive mark survives the code change that made it wrong. Ninety days and a one-line justification keep suppressions honest.
• Track the false-positive rate per check. A check that’s wrong 80% of the time needs fixing or switching off, decided once, with data.
• Give triage one owner. A queue that belongs to everyone belongs to no one.

FALSE NEGATIVES COST MORE A false positive costs twenty minutes. A false negative costs whatever the attacker found. Tuning a scanner until its quiet is the easiest way to create false negatives, so keep checking it can still see. Plant a canary, a deliberately vulnerable endpoint in staging, or point the same configuration at an intentionally insecure app such as OWASP Juice Shop, and confirm every scan still finds it. A scanner that stops finding the canary has stopped working, whatever its report says.

Scans That Run Late, or Not at All

The other pain point is timing. Full-surface DAST needs a running, seeded environment and takes time in proportion to the application’s size, so it drifts from every sprint to every quarter. Our guide to DevSecOps testing tools covers the three fixes that work: scope scans to what changed, split targeted and full scans onto different cadences, and fix the environment bottleneck, which is usually slower than the scan.

Two additions belong here. Scan the API before the UI: an OpenAPI-driven scan needs no crawler, usually finishes much faster and suits every pull request. And start new scans in report-only mode, because a gate that fails builds on an un-tuned scanner gets switched off within a month.

When scans stop altogether, it’s rarely a decision. A test password expired, the staging URL changed, or the job broke and nobody owns its alerts. Alert when the scan fails, and when the number of signed-in pages it reaches drops.

DAST vs SAST, IAST, SCA and Pen Testing: The Layers of Application Security Testing

Most frustration with DAST comes from expecting it to do another method’s job. Each layer looks at something different, and each is blind where another can see.

Read the “blind to” column as a chain. SAST misses runtime context, which DAST covers. DAST can’t point to the line of code, which SAST and IAST can. Neither tracks known flaws in third-party packages as well as SCA does. And no automated method understands your business, which is why penetration testing hasn’t been automated away.

So DAST and SAST aren’t rivals. SAST is fast and early but noisy without runtime context. DAST comes later but shows what’s actually exploitable. Use SAST to stop flaws reaching the build, and DAST to catch what only exists once it’s deployed.

Mobile adds a layer a web scanner never sees: DAST covers the API back end, but device-side risks such as insecure local storage need mobile-specific tooling. Our guide to mobile app security testing 2026 covers the OWASP Mobile Top 10 and the tools for each method.

DAST for APIs and AI Features

APIs

For most applications the API is now the bulk of the attack surface, and an API scan is only as good as the definition you feed it. Give the scanner the OpenAPI or GraphQL schema your API test automation already uses and it will test every operation, including ones no screen calls.

It won’t find the API’s most common serious flaw. Broken Object Level Authorization is number one in the OWASP API Security Top 10 (2023), and it’s the invoice bug again: a valid token, a valid request, someone else’s object. Catching it takes the multi-user tests above, run against the API directly.

AI features

If your application now includes a chatbot or an agent, its riskiest input may not be a form field. Prompt injection, number one in the OWASP Top 10 for LLM Applications (2025), hides instructions in text the model reads, often inside an uploaded document, an email or a supplier invoice rather than a parameter a scanner fuzzes. Whether an injection worked is also a question of meaning, not a matching string, which payload libraries weren’t built to judge?

DAST still catches one part: model output rendered into a page can carry cross-site scripting like any untrusted input. The prompt-level testing is its own discipline, covered in our guide to prompt injection testing for ERP agents.

Building a DAST Program That Actually Runs

Here’s the order that works. Each step removes one of the failure modes from the post-mortem above.

Step four depends on test data management more than teams expect: a scan against an empty database mostly tests empty pages.

Step nine is the one most program’s skip. Every finding a pen tester reports that your scanner should have caught is a bug in the scanner’s configuration. Feed it back.

Automate Your Security Testing with Sofy

Sofy comes at application security from the testing side, and that shapes what it covers.

Sofy’s security testing agents bring DAST to mobile and web apps. They analyses an application’s network traffic, APIs and headers, check for OWASP Top 10 classes such as injection flaws, broken authentication and insecure configurations, and run automated compliance checks for GDPR, HIPAA and SOC 2. Detection runs continuously rather than quarterly, findings route into the incident tooling your team already uses, and each comes with a remediation guide, so developers get a fix path rather than a URL and a severity score.

Because the same platform runs your functional tests, three problems from this guide get easier:

• Coverage follows your tests. Security checks run alongside functional test execution, so they reach the flows your tests already walk, including the multi-step journeys a crawler abandons.
• Abuse cases become regression tests. The authorization and business-logic cases DAST can’t recognize become ordinary outcome-based tests: sign in as user B, request user A’s invoice, expect a refusal.
• Findings keep pace with releases. Security signal arrives with the functional result, in the same run.

What Sofy doesn’t replace: threat modelling, SAST and SCA in the pipeline, and a periodic human penetration test, still the only reliable way to find creative attack chains. The goal is a cleaner baseline, so specialists spend their time on new problems rather than old ones.

Frequently Asked Questions

What is dynamic application security testing?

Dynamic application security testing (DAST) tests a running application from the outside, without source code. A scanner maps the app’s pages and APIs, sends crafted malicious input and analyses the responses for evidence of vulnerabilities such as injection, misconfiguration and weak session handling.

What is the difference between DAST and SAST?

SAST analyses source code without running it and points to the line to fix, but can’t see runtime configuration. DAST attacks the deployed application and shows what’s actually exploitable, but can’t see the code. Mature programmes use both.

What can’t DAST detect?

DAST struggles with flaws that look like normal use: one user reading another user’s data, business-logic abuse, and insecure design and logging failures. It also misses anything it can’t reach, such as pages behind a lost login, flows it can’t complete and APIs nobody described to it.

What is authenticated DAST scanning?

An authenticated scan signs in as a real user so it can test the application behind the login page. It needs a working login sequence, a logged-in indicator to detect lost sessions, logout URLs excluded from the crawl, and ideally one test account per role.

How do you reduce DAST false positives?

Require evidence for every finding and reproduce it before ticketing. Tune the scan policy to your stack, de-duplicate by root cause, allow-list the scanner past your WAF in test environments, and give every suppression an expiry date.

Is it safe to run DAST against production?

Passive checks generally are safe. Active scans submit forms, create records, trigger emails and can slow fragile services, so run them against a production-like test environment. If you must scan production, agree the scope, a time window and a rollback plan first.

Does DAST replace penetration testing?

No. DAST automates the search for known vulnerability patterns at scale. Penetration testers find what patterns can’t: business-logic flaws, authorization abuse and chains of small issues that add up to a serious one. A common pattern is DAST on every release and a pen test at least yearly.

The Bottom Line

DAST is the automated test that comes closest to seeing your application the way an attacker does, which is exactly why a clean report is so easy to over-read. It proves that what the scanner reached didn’t show patterns it recognizes, on the day it ran. That’s valuable. It isn’t the same as secure.

Treat coverage as the first finding in every report. Make authentication work and prove it, feed the scanner your APIs and drain the noise with evidence. Then cover what DAST can’t with tests that know the right answer, because that’s where the breaches that follow clean scans live.