Shadow APIs and Zombie APIs: Finding the Endpoints You Forgot

You cannot secure an API you do not know exists. Many organisations discover, often through a breach or bug bounty report, that they were running endpoints nobody had documented or remembered.

Shadow APIs vs zombie APIs

• Shadow APIs are live but undocumented: an endpoint added for a mobile feature, an internal tool exposed publicly, a partner integration that was never added to the spec.
• Zombie APIs are deprecated but still running: /v1 after /v2 launched, a beta endpoint that was supposed to be removed.

Both tend to be less maintained, less tested and missing newer security controls.

How they appear

• Rapid development without updating API specifications.
• Old versions kept alive "for that one customer."
• Debug and admin routes left in production.
• Microservices exposed directly instead of through the gateway.
• Staging or test environments reachable from the internet.
• Third-party or acquired codebases with their own endpoints.

Why they are dangerous

• Missing authorisation fixes applied only to the current version.
• No rate limiting because they bypass the gateway.
• Verbose debugging or older dependencies.
• No monitoring, so attacks go unnoticed.

A typical finding: /api/v2/users/{id} was fixed for BOLA, but /api/v1/users/{id} still returns any user.

Building an API inventory

Combine several sources, since none is complete alone:

1. Specifications: OpenAPI files, GraphQL schemas and Postman collections.
2. Code: route definitions extracted from your codebase.
3. Traffic: API gateway, load balancer and CDN logs showing what is actually called.
4. Clients: endpoints referenced in frontend bundles and mobile apps.
5. External discovery: subdomain enumeration, crawling and probing common API paths from the outside.

For each endpoint, record its owner, authentication method, data sensitivity, version and status.

Retiring APIs safely

1. Announce deprecation with a timeline.
2. Monitor usage and contact remaining callers.
3. Return warnings, then errors, before removal.
4. Remove the code and routes, not just documentation.
5. Verify from outside that the endpoint is gone.

Keeping it current

Inventories decay as fast as code changes. Automate: generate specs from code, fail builds when routes are undocumented, and continuously discover endpoints externally.

Discovering your attack surface

SecurityInfinity's recon and API agents discover subdomains, crawl applications, extract endpoints from JavaScript bundles and probe for older versions, then test what they find. Shadow and zombie APIs show up in your results alongside the documented ones. Start free.

Frequently asked questions

Is improper inventory management in the OWASP API Top 10?

Yes. It is API9 in the 2023 OWASP API Security Top 10.

Can an API gateway prevent shadow APIs?

Only if all traffic is forced through it. Services reachable directly bypass the gateway and its controls.

How do attackers find undocumented endpoints?

By reading JavaScript bundles and mobile apps, guessing common paths and versions, and examining old documentation and archives.