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, with the central finding that schema-led testing is bounded by what teams already know about their APIs, while agentless discovery and authorization testing expand coverage into shadow and zombie endpoints.

Why it matters: It matters because IAM, PAM, and application security teams need visibility into real access paths, not just documented schemas, when APIs expose user-scoped data or business logic.

👉 Read Escape's comparison of Bright Security and DAST coverage for shadow APIs

Context

Application security teams often inherit a false assumption that a scanner can only protect what the team already knows exists. In API environments, that assumption breaks down because shadow endpoints, zombie services, and mismatched schemas can sit outside the documented inventory while still remaining reachable.

This comparison is really about control coverage, not product preference. For identity and access governance, the critical question is whether testing proves the system honours authenticated user boundaries, role boundaries, and exposed attack surface across the full runtime estate, including any secrets, tokens, or delegated access used to reach it.

Key questions

Q: How should security teams test REST APIs for broken authorization?

A: Test each endpoint with multiple identity contexts: no authentication, invalid or expired credentials, least-privilege service accounts, and users outside the resource ownership boundary. A good result is not just a 403, but consistent rejection of data access and state changes that the caller should not control.

Q: Why do schema-based scanners miss some API security risks?

A: Because they depend on a known schema or a crawled surface, they only test what the team already documented or linked. If a service is exposed through a forgotten subdomain, a rogue deployment, or a changed route, the scanner may never see it, which leaves shadow APIs and related access flaws outside coverage.

Q: What do security teams get wrong about business logic vulnerabilities?

A: They often assume that a secure-looking request means a secure workflow. Business logic flaws usually exploit ordinary functions such as changing identifiers, replaying state, or combining requests in an unexpected order. Those failures are hard to find because they require understanding the application’s intended behaviour, not just its input fields.

Q: Should organisations prioritise API discovery before deeper vulnerability testing?

A: Yes, when the estate is incomplete or fast-changing. If you cannot reliably identify all exposed APIs, deeper testing will understate risk because it will miss services that are live, reachable, and potentially sensitive but absent from the original scan plan.

Technical breakdown

How schema-led API testing limits discovery coverage

Schema-led DAST depends on a known OpenAPI specification, GraphQL schema, or a crawled surface that is already reachable from the entry point. That works well for documented endpoints, but it cannot reliably find forgotten subdomains, rogue deployments, or externally exposed APIs that were never linked into the schema. In practice, the scanner tests the map, not the entire territory. When the attack surface is dynamic, that creates blind spots around shadow APIs and changed routes that still accept traffic.

Practical implication: teams should validate whether API testing can discover endpoints independently of the published schema, not just verify known routes.

Why multi-user authorization testing matters for BOLA and IDOR

Business logic flaws such as BOLA and IDOR emerge when an authenticated user can access another user’s object, role, or function because authorization checks are incomplete or inconsistently applied. The key mechanism is not payload fuzzing alone, but cross-user and cross-role testing under real authentication states. Multi-user testing forces the application to prove that every request is checked against the current identity, role, and scope rather than assuming the caller is entitled because the endpoint is reachable.

Practical implication: teams should require tests that authenticate as multiple roles and compare access outcomes across users, not rely on single-session scans.

What agentless discovery adds to cloud and API governance

Agentless discovery combines passive DNS, certificate-transparency logs, service fingerprinting, and observed traffic to reconstruct where APIs actually live. That matters because modern exposure is often distributed across cloud estates, internal services, and integration layers where the source of truth is incomplete. For identity governance, the useful part is not only finding the endpoint, but also tracing whether exposed interfaces depend on secrets, tokens, or delegated identity paths that should be governed as part of the application trust boundary.

Practical implication: security teams should treat discovered APIs as governed assets and map the identities, secrets, and access paths that can reach them.

Threat narrative

Attacker objective: The attacker objective is to use undocumented API reachability and broken authorization to access business data or execute actions across user boundaries.

1. Entry occurs through an exposed API, shadow endpoint, or schema gap that was not in the documented inventory.
2. Escalation happens when insufficient authorization checks allow cross-user or cross-role access to protected objects or functions.
3. Impact follows as attackers reach data or actions they were never meant to access, often without triggering obvious authentication failure.

NHI Mgmt Group analysis

Schema visibility is not attack-surface visibility: a scanner that only tests known OpenAPI or GraphQL inputs can still leave shadow and zombie APIs outside governance. That is a control gap, not a tuning issue, because the organisation is implicitly trusting its inventory to be complete when it is not. For API security programmes, the right question is whether discovery is independent of documentation and whether unknown endpoints are treated as first-class assets.

Business logic testing is an identity problem as much as an AppSec problem: BOLA and IDOR are failures of object-level authorization, which means the application did not consistently verify what the current identity is allowed to touch. That puts API testing squarely inside IAM-adjacent governance, especially where session state, delegated access, or role scoping determines business actions. Teams should view these flaws as authorization assurance failures, not just vulnerability findings.

Agentless discovery creates a more realistic control boundary: passive DNS, certificate-transparency logs, and traffic inference align better with how exposed APIs actually appear in modern estates than URL-based crawling alone. Shadow API exposure: the organisation assumes only known services matter, while forgotten services still process traffic and hold sensitive data. Practitioners should require discovery methods that reveal the real boundary before they claim coverage.

API security reporting should prioritise business context, not raw severity lists: a high count of findings tells teams little about which endpoints are externally exposed, reproducible without authentication, or connected to sensitive workflows. Without that context, remediation is noisy and teams waste effort on low-value fixes. The better model is to score exposure, reachability, and identity sensitivity together so the programme can target the largest governance gaps first.

Workload identity and API governance are converging: as more systems rely on tokens, service credentials, and machine-to-machine calls, the same access boundary that protects users also protects workloads. That means API security tools need to surface where secrets, delegated credentials, or authenticated traffic are part of the route to sensitive operations. Practitioners should align API testing with identity governance instead of treating it as a separate control silo.

What this signals

API teams should expect the boundary between application testing and identity governance to keep narrowing. Once an interface depends on tokens, service credentials, or delegated access, discovery is only half the job. The other half is proving that the current identity can only reach the data and functions it is actually entitled to use.

Hidden endpoint governance: organisations that cannot inventory shadow APIs will continue to understate their true exposure, especially where internal services are later made reachable through cloud routing or integration changes. That creates a persistent blind spot for both AppSec and IAM programmes, and it makes remediation ordering unreliable.

For identity-heavy API estates, the control model should move toward NIST SP 800-53 Rev 5 Security and Privacy Controls around access control and auditability, while discovery findings are cross-checked against secret hygiene in the Guide to the Secret Sprawl Challenge.

For practitioners

• Test for undocumented endpoints first Require discovery modes that can surface shadow APIs, zombie APIs, and service variants not present in the published schema, then reconcile them against the application inventory. Treat any endpoint found outside the approved map as a governance exception until it is owned, classified, and tested.
• Validate authorization with multiple identities Run BOLA and IDOR tests using at least two authenticated users with different roles or object ownership so the scanner proves whether access checks change by identity. Single-session testing is not enough to expose cross-user failures.
• Map discovered APIs to identity dependencies For each exposed API, record whether access depends on browser sessions, OAuth tokens, service credentials, or other secrets, then identify who owns rotation and revocation. This prevents exposed interfaces from becoming unmanaged identity pathways.
• Prioritise findings by exposure and reproducibility Rank issues higher when they are externally reachable, reproducible without authentication, or tied to sensitive workflows such as account changes, object retrieval, or admin actions. That reduces noise and keeps remediation tied to business risk.

Key takeaways

• Schema-led DAST can leave shadow and zombie APIs outside coverage, which is a discovery failure rather than a tuning issue.
• BOLA and IDOR are authorization failures tied to identity and object ownership, so multi-user testing is essential.
• API security programmes need discovery, identity mapping, and business-context prioritisation to turn findings into governance decisions.

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.
• BOLA: Broken Object Level Authorization occurs when an application fails to verify that a user is permitted to act on a specific object. It is closely related to IDOR, but the core issue is authorisation logic, not the visible object reference itself.
• IDOR: Insecure Direct Object Reference is a vulnerability where an application exposes internal object identifiers and fails to verify whether the requesting principal is entitled to access them. The flaw often produces unauthorized reads, writes, or account-level actions.

What's in the full article

Escape's full comparison covers the operational detail this post intentionally leaves for the source:

• Agentless API discovery workflow using passive DNS, certificate-transparency logs, and traffic inference
• Side-by-side feature matrix for GraphQL, authentication, reporting, and CI/CD integration differences
• Remediation and workflow details for developer-ready fixes, Jira syncing, and compliance matrix reporting
• Operational examples of how reconstructed schemas and custom rules are used in live testing

👉 Escape's full comparison covers discovery depth, authorization testing, and remediation workflow detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is suited to practitioners who need to connect identity controls to broader security and application governance programmes.