Legacy DAST tools miss API runtime flaws that attackers exploit

At a glance

What this is: This article argues that DAST remains valuable for runtime testing, but legacy scanners often miss the API-specific logic and authorization flaws that matter most in modern production systems.

Why it matters: IAM, AppSec, and platform teams need to treat API discovery, authentication paths, and object-level authorization as runtime governance problems, not just scanning problems, because clean results can still hide exploitable access flaws.

By the numbers:

• Over 70% of successful breaches in 2023 stemmed from vulnerabilities in application layer components, especially APIs and web services.

Context

Dynamic Application Security Testing is a black-box method for probing a live application the way an attacker would, which makes it useful for finding issues that code review and perimeter controls can miss. The governance problem appears when that testing model meets modern APIs, where hidden endpoints, dynamic authentication, and stateful business logic create exposure that a traditional crawler may never fully observe.

For identity and access teams, the practical issue is not only vulnerability discovery but whether the test can actually follow real authorization paths across users, tokens, and services. When DAST cannot model those runtime conditions, it can return a false sense of coverage even though the access boundary has not been validated in production-like behaviour.

Legacy DAST assumptions fit static web interfaces far better than distributed API estates. That mismatch is typical across modern DevSecOps programmes, especially where service-to-service access, short-lived tokens, and undocumented endpoints have become normal.

Key questions

Q: Why do legacy DAST tools miss broken authorisation in APIs?

A: Legacy tools often rely on static schemas, limited crawling, and isolated requests. That approach struggles with role-based access decisions, chained authentication, and object-level checks that only fail in context. If the scanner cannot model the workflow, it cannot reliably prove whether authorisation is working.

Q: How do teams know whether API testing is actually covering business logic risk?

A: Look for evidence that the testing can change user context, sequence calls, and verify whether ownership and function-level checks are enforced across endpoints. If the process only sends payloads and records responses, it is still pattern scanning. Coverage is real when the test can show how a valid request becomes invalid in the wrong identity context.

Q: What are the signs that API testing is not covering production reality?

A: The biggest warning signs are incomplete endpoint discovery, heavy dependence on manual schema uploads, fragile authentication setup, and scan results that look clean even though the API estate changes frequently. If the tool cannot follow real user and service journeys, it is probably testing the documentation instead of the application.

Q: Should security teams prioritise runtime API testing over generic web scanning?

A: They should prioritise runtime API testing where business logic, delegated access, or service-to-service authorisation drives risk. Generic web scanning still has value for traditional input flaws, but it cannot replace identity-aware validation for modern API estates. The right balance is both, with the runtime view given more weight when APIs carry sensitive access.

Technical breakdown

Why legacy DAST works better on web pages than APIs

DAST tests a running system from the outside, crawling interfaces, submitting payloads, and watching responses for exploitable behaviour. That works well when the surface is predictable, but APIs often expose hidden routes, conditional states, and non-human authentication patterns that are not discoverable through simple crawling. In practice, the tool may only see what documentation or entry points reveal, not what the application actually does in context. That is why runtime coverage and endpoint discovery are now inseparable.

Practical implication: Treat API discovery as part of the testing architecture, not a documentation exercise.

Why business logic flaws escape static scanning

Business logic flaws are not simple input-validation defects. They emerge when a request is technically valid but operationally abusive, such as reusing a token across roles, changing an object identifier, or chaining calls in an unintended order. Traditional DAST engines often lack the state and context needed to simulate those flows because they test isolated requests rather than user journeys. As APIs become more stateful, the gap between protocol correctness and authorization correctness grows wider.

Practical implication: Validate multi-step workflows and role transitions, not just endpoint responses.

How authentication complexity weakens runtime coverage

Modern APIs often use OAuth, JWT, short-lived tokens, and chained service authentication. A scanner that depends on static sessions or manual configuration can miss entire branches of access control because it cannot continuously adapt to changing tokens or delegated flows. That problem is especially important in environments with service accounts and machine identities, where the security question is not just whether a request is authenticated, but whether the right identity is authorised for the right action at the right moment.

Practical implication: Test auth flows with real token lifecycles and service identities, not fixed sessions.

Threat narrative

Attacker objective: Exploit runtime API behaviour to bypass authorization and reach data or actions that the application should have restricted.

1. Entry begins with attackers targeting exposed API endpoints in production environments rather than relying on code-level weaknesses alone.
2. Credential and session handling become the leverage point when dynamic authentication, short-lived tokens, or delegated access flows are not fully validated.
3. Privilege escalation occurs when business logic or object-level authorization allows a valid user or token to reach data or actions outside its intended scope.
4. Impact is achieved through unauthorized access to application data, service actions, or downstream systems that trusted the compromised API path.

Breaches seen in the wild

• ASP.NET machine key attacks 2025: Developers copied ASP.NET machine keys from public sources; attackers used one to run Godzilla via ViewState. Microsoft found 3,000+ such keys.
• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime testing has become an identity and authorization control, not just an AppSec control: when APIs depend on tokens, delegated access, and role-sensitive workflows, the testing question is whether those runtime decisions behave as intended. A scan that cannot observe live authorization paths is not validating access governance, only endpoint reachability. Practitioners should treat runtime API testing as part of entitlement assurance.

Legacy DAST creates API inventory debt: scanners that rely on crawling or stale schemas reinforce blind spots in undocumented, orphaned, and partner-facing APIs. That problem is not merely operational, because untracked endpoints are ungoverned attack surfaces with no clear owner, no test coverage, and no reliable offboarding path. The result is governance drift, not just missed findings.

Authorization blind spot is the core failure mode here: many organisations assume a clean DAST result means the application is secure, but business logic and object-level authorization are often invisible to traditional scans. That assumption collapses in distributed systems where access is stateful and identity-bearing requests can be replayed, chained, or redirected. Security teams should stop treating pass/fail scan output as proof of access control.

Machine identities intensify the problem: API testing now has to account for service accounts, tokens, and workload-to-workload trust, not just human users. When runtime testing ignores those non-human identities, it misses the very access paths attackers increasingly target. For IAM and AppSec leaders, the issue is whether identity-aware validation is built into the testing workflow.

Modern API security needs behavioural validation, not just coverage counts: endpoint totals and scan frequency do not tell you whether authorisation, sequencing, and context are being exercised. The better measure is whether the tool can prove that a request is denied when it should be denied, even when the identity, token, or workflow changes. Practitioners should require proof of negative testing, not just more alerts.

What this signals

API inventory is now an access-control problem as much as a discovery problem: undocumented or orphaned endpoints are not just missing from reports, they are missing from governance. Once an API is outside inventory, it is also outside consistent authorization testing, ownership, and lifecycle offboarding, which is why visibility and entitlement assurance have to move together.

Runtime validation is where modern AppSec meets IAM: the important control question is no longer whether an endpoint exists, but whether the right identity can use it in the right state. That makes token handling, role transitions, and service-account behaviour central to secure API operations, especially in distributed microservice environments.

For practitioners

• Map API testing to real authorization paths Ensure DAST exercises role changes, token changes, and object-level access decisions rather than only probing public endpoints.
• Inventory hidden and undocumented APIs Use discovery processes that identify orphaned, partner, and backend service APIs so they are not excluded from security validation.
• Validate OAuth and JWT flows under runtime conditions Test short-lived tokens, chained authentication, and service-account access in environments that mirror production behaviour.
• Require evidence of business logic testing Ask for test cases that show what happens when a valid identity attempts an out-of-scope action, not just when malformed input is submitted.

Key takeaways

• Legacy DAST can still catch runtime flaws, but it is not enough on its own for modern APIs where authorization depends on state, identity, and workflow.
• The main gap is not simple vulnerability detection, it is validation of business logic and object-level access under real production-like conditions.
• Security teams should anchor API testing to discovery, token lifecycle handling, and negative authorization checks so clean scans do not mask access-control failure.

Key terms

• Dynamic Application Security Testing: Dynamic Application Security Testing evaluates a running application from the outside to identify weaknesses that only appear under real execution conditions. It is useful for validating authentication, session handling, and API behaviour, especially where configuration and integrations change how the system actually responds to attack.
• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
• Business Logic Flaw: A business logic flaw is a weakness in how an application handles intended behaviour, such as permissions, workflow order, or transaction state. These flaws often bypass signature-based checks because the problem is not a malformed input, but a legitimate action used in the wrong sequence or context.
• Runtime Authentication Path: A runtime authentication path is the live sequence of steps, tokens, and identity checks an application uses to decide who can act. In API-heavy environments, these paths may involve OAuth, JWTs, short-lived sessions, and service-to-service trust that change during execution.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, IAM, human identity, identity lifecycle, and secrets management. It gives practitioners a common control language for governing identities across modern security programmes.