Dynamic application security testing was designed around a specific application shape: a server rendering HTML, links between pages, forms that submit parameters. The scanner starts at a root URL, follows links, builds a site map, and fuzzes what it found.
That shape describes very little modern software. In 2026, enterprises increasingly run applications composed of APIs, microservices, containers, and serverless functions, where the frontend is a JavaScript bundle and the actual attack surface is a set of JSON endpoints the bundle calls at runtime.
Point a link-following crawler at that and it finds one HTML file. The scan completes successfully. The report is clean. Coverage is close to zero, and nothing in the output says so.
What specifically breaks
Discovery. There are no <a href> elements to follow. Endpoints are constructed in JavaScript at runtime, often assembled from configuration. A crawler cannot enumerate what it cannot see referenced.
Authentication. Classic DAST handles form login and a session cookie. Modern estates use OAuth flows, short-lived bearer tokens, refresh rotation, mTLS between services, and signed requests. A scanner that cannot maintain valid credentials tests only the 401 handler — thoroughly.
State and sequence. Meaningful API testing frequently requires ordered operations: create a resource, then act on it, then verify. Stateless fuzzing of individual endpoints misses everything that depends on sequence.
Input structure. Form parameters are flat. API bodies are nested JSON with types, schemas, and validation. Mutating a deeply nested field intelligently requires understanding the schema, not string substitution.
Authorisation, which is the big one. The OWASP API Security Top 10's leading risks are object-level and function-level authorisation failures. Detecting them requires authenticating as user A, requesting user B's resource, and knowing that the response should have been denied. A scanner with one set of credentials and no model of who owns what cannot make that determination — it sees a 200 and moves on.
That last point is worth sitting with. The most prevalent API vulnerability class is close to invisible to generic dynamic scanning, which is why organisations with clean DAST reports still lose data through IDOR.
What replaces link crawling
Specification-driven testing. Feed the scanner an OpenAPI or GraphQL schema so it knows the endpoints, methods, and body structures. This is the single biggest improvement available — and it inherits the API inventory problem exactly. Your coverage is bounded by your spec's accuracy, and specs are systematically incomplete.
Traffic-derived surface. Record real traffic — from staging, from integration tests, from a gateway — and derive the tested surface from it. This finds the endpoints the spec omits, which are disproportionately the risky ones.
Test-suite-driven scanning. Run your existing integration tests through a proxy that fuzzes as they execute. Your tests already know how to authenticate and how to sequence operations. Reusing that is far cheaper than teaching a scanner the same thing, and it scales with a suite the team already maintains.
Purpose-built authorisation tests. Two accounts in different tenants, and an assertion for every object-scoped endpoint that A cannot read, update, or delete B's resources. This is not a scanner feature; it is a test-suite pattern. It is also the highest-value security testing most teams are not doing.
Where DAST still earns its place
The argument here is against crawler-based DAST as a coverage claim, not against dynamic testing. Runtime testing finds things static analysis structurally cannot:
- Configuration and deployment issues — TLS settings, headers, exposed debug endpoints, permissive CORS
- Behaviour of the assembled system, including gateways, proxies, WAFs, and service meshes
- Authentication and session handling as actually deployed
- Runtime issues in authentication flows and third-party integrations, which is where a growing share of real breaches originate
The practical combination is well established: manual review for authorisation logic, dynamic API testing with tools such as Burp Suite or OWASP ZAP for authentication and misconfiguration, and behavioural analysis for business logic abuse. No single technique covers the surface.
Measure coverage, not findings
The most useful change most teams can make is to stop reporting DAST results as a finding count and start reporting them as coverage.
- How many endpoints exist, from traffic and route analysis?
- How many did the scan actually exercise?
- Of those, how many were exercised authenticated, as more than one identity?
- Which endpoints were never touched at all?
A scan that exercised 200 of 900 endpoints and found nothing is not a clean result. It is a 22% sample with no findings, and stating it that way changes the conversation with leadership from "we're secure" to "here is the gap and what closing it costs."
This is the same discipline that makes code coverage useful. A test suite that passes tells you nothing without knowing what it ran.
How Safeguard helps
Endpoint inventory derived from build-time route analysis and observed traffic, not from a hand-maintained spec — which is the input every dynamic testing strategy depends on and the one most commonly wrong.
Coverage measured against the discovered surface. Safeguard compares what your scanning actually exercised against the full inventory of endpoints, so untested surface is reported explicitly rather than silently omitted.
Reachability to connect findings to real exposure. A dependency vulnerability behind an endpoint that is live, authenticated, and internet-facing is a different problem from the same finding in a code path nothing invokes. Safeguard combines exposure, reachability, KEV membership, and EPSS in the ranking.
Shadow and zombie endpoint detection. Endpoints serving traffic that appear in no specification, and specified endpoints that serve nothing, both surface as actionable findings with ownership attached.
Griffin for closing the loop. Adding authorisation test coverage, removing dead endpoints, and upgrading vulnerable dependencies across many services is mechanical work at scale. Griffin authors and tests those changes as reviewable pull requests.
Pull your last DAST report and count the distinct endpoints it exercised. Compare that to your gateway's endpoint count. That ratio is your real coverage, and it is usually the most surprising number in an AppSec programme.
Sources: OX Security — DAST Tools in 2026 · Penligent — DAST Tools in 2026 Technical Guide · AppSecMaster — OWASP API Security Top 10 · Astra — Common Web Application Vulnerabilities in 2026
