Shadow API discovery gaps expose the limits of schema-led DAST

At a glance

What this is: This is a comparison of two DAST approaches, showing that schema-led scanning can leave undocumented APIs and business logic flaws outside coverage.

Why it matters: It matters because AppSec and platform teams need testing that can find exposed API surface area, not just validate routes already described in a schema.

Context

Schema-led DAST assumes the API surface is already known, but modern application estates rarely stay neatly documented. Shadow and zombie APIs appear when forgotten deployments, undocumented routes, or schema drift create live attack surface that a crawler tied to a known spec cannot reconstruct.

That gap is especially relevant where business logic and authorization are the real risk, not just input validation. In identity terms, cross-user access testing is what separates a scanner that checks endpoints from one that can validate whether one user can improperly reach another user’s data or functions.

Key questions

Q: What breaks when API tests are not aligned with changing schemas and integration dependencies?

A: Tests become brittle when schemas drift, documentation is incomplete, or dependent services are unstable. That creates false failures, missed coverage, and slow remediation. Teams should use schema validation, mock servers, and contract testing where integrations are complex. Without those controls, even well-written test suites lose value as the application evolves.

Q: Why do shadow APIs increase insurance and breach risk?

A: Shadow APIs expand the attack surface without corresponding ownership, testing, or monitoring. That creates unmanaged paths to sensitive data and business functions, which increases the chance of loss and makes claims harder to defend. If a team cannot identify an API, it usually cannot prove it is tested, monitored, or retired on schedule.

Q: What do teams get wrong about testing API authorization?

A: They often assume a single successful response proves the control is sound. In practice, authorization failures appear across object IDs, scope changes, role transitions, and alternate workflows. Good testing must try the same action under different identities and permissions to see whether the API leaks access through unexpected paths.

Q: How should teams balance discovery and schema validation in DAST?

A: Teams should use schema validation to confirm known routes, then add discovery methods that find routes independently of the spec and compare them against the declared inventory. That combination catches undocumented exposure and reduces the chance that an orphaned service escapes security testing.

Technical breakdown

Why schema-bound scanning misses shadow APIs

Schema-led DAST starts from an OpenAPI or GraphQL document, then exercises the routes it already knows. That works well for documented interfaces, but it fails when the live surface diverges from the spec, or when a forgotten host, subdomain, or version is never added to the schema at all. In practice, those are the shadow and zombie APIs that become invisible to a schema-first crawler. The technical limitation is discovery, not just test depth: if the scanner cannot infer the endpoint, it cannot validate it.

Practical implication: pair schema-based scans with discovery methods that find live endpoints independently of published specifications.

Business logic testing needs multiple identities

Authorization flaws such as BOLA and IDOR are not proven by a single request from a single session. They emerge when the tool can authenticate as more than one user and attempt cross-user or cross-role access against the same object or function. That means the scanner has to model identity context, not just request structure. Multi-user testing is therefore a separate capability from ordinary API fuzzing, because the vulnerability lives in the relationship between subjects, objects, and privileges.

Practical implication: validate object and role boundaries with multi-user test flows, not only with unauthenticated or single-user scans.

Why API inventory quality now drives detection quality

A DAST program is only as complete as its inventory of live services. When internal and external endpoints are discovered through passive DNS, certificate transparency, and authenticated traffic inference, the tool can compare observed routes with declared schema and surface drift. That shifts the control problem from simple scan coverage to continuous inventory reconciliation. The operational question is whether your programme can keep pace as services appear, change, or persist after teams have forgotten they exist.

Practical implication: treat API inventory reconciliation as part of the control plane, not as a one-time discovery task.

Threat narrative

Attacker objective: The attacker’s objective is to reach live but undocumented API functions and exploit authorization weaknesses to access data or actions across user boundaries.

1. Entry begins when undocumented or shadow API endpoints exist outside the published schema and therefore outside the scanner’s normal test scope.
2. Credential or authorization abuse follows when an attacker reaches those endpoints and tests cross-user or cross-role access paths that were never validated.
3. Impact occurs when object-level or business logic flaws expose data or actions that the organisation assumed were protected by schema coverage and routine DAST.

Breaches seen in the wild

• CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.

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

Schema-led DAST creates visibility debt when discovery stops at the spec. A scanner that trusts OpenAPI or GraphQL inputs can validate documented routes while leaving live endpoints untouched. That is a control gap, not just a tooling preference, because undocumented APIs are part of the attack surface whether they appear in inventory or not. Practitioners should treat discovery coverage as a governance issue, not a scan setting.

Shadow API discovery is now an identity problem as much as an application problem. Once an endpoint is exposed, the question becomes which identities can reach which objects and actions. That makes business logic testing, especially cross-user authorization testing, a direct control for IAM-adjacent risk in API programmes. Teams that only test request handling but not user boundaries are measuring the wrong layer.

Business logic testing needs to move from payload abuse to relationship abuse. BOLA and IDOR are not primarily about malformed inputs; they are about one identity being able to act on another identity’s object. That means the decisive control is multi-user validation against real application state, not just generic fuzzing. Security teams should reframe API testing around privilege relationships, because that is where exposure becomes material.

Discovery plus authorization validation is the new minimum for API assurance. As API estates sprawl across internal, external, and forgotten deployments, the governance burden shifts toward continuous inventory plus identity-aware validation. Schema-led scanning still has value, but only when it is paired with techniques that can find what the schema misses and prove what one user can do to another’s data. Practitioners should align testing strategy to live exposure, not declared design.

From our research library:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• Read next: CI/CD Pipeline Identity Security Guide

What this signals

Discovery is now the gating control for API assurance: when the testing model starts from a schema, any endpoint that never enters the schema can also evade the control. That changes the programme question from “is the scanner thorough?” to “how do we keep inventory current enough for testing to matter?”

Cross-user authorization validation should sit beside discovery in API risk management. If a tool cannot authenticate as distinct users and prove what one user can do to another object, it is not measuring the failure mode that matters most in business logic abuse.

For practitioners

• Combine schema-led scans with independent endpoint discovery Use passive DNS, certificate transparency, and authenticated traffic inference to find endpoints that are live but absent from OpenAPI or GraphQL documentation.
• Test authorization with multiple real users Run cross-user and cross-role checks for each sensitive object and action so BOLA and IDOR are validated against actual privilege boundaries.
• Track schema drift continuously Compare observed traffic and reconstructed routes against declared API inventory so newly exposed, renamed, or orphaned services are not left untested.
• Prioritise findings by exposure and repro context Rank issues by whether the endpoint is internet-facing, reproducible without authentication, or tied to sensitive business flows, not only by severity labels.

Key takeaways

• Schema-led DAST can still leave live APIs untested when discovery depends on OpenAPI or GraphQL inputs rather than the observed attack surface.
• Cross-user access flaws such as BOLA and IDOR require multi-user validation, not just request-level scanning.
• API assurance now depends on continuous inventory reconciliation plus identity-aware authorization testing, not on schema coverage alone.

Key terms

• Shadow API: An API endpoint that exists in production but is not fully known, reviewed, or governed by the security programme. Shadow APIs often emerge through fast delivery, copy-paste development, or overlooked internal routes, and they create untracked exposure because they sit outside inventory, policy, and ownership processes.
• Zombie API: A zombie API is a deprecated or abandoned interface that remains accessible after the organisation believes it should be retired. It is risky because old permissions, secrets, or backend trust can survive the business purpose, turning legacy access into an active exposure.
• 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.
• Schema-led DAST: A dynamic application security testing approach that uses an API schema, such as OpenAPI or GraphQL, as the starting point for scanning. It is efficient for documented routes, but it can miss live endpoints and business logic flaws if discovery depends too heavily on the published specification.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives security practitioners a practical foundation for governing identity-bound access across modern environments.