Shadow and Zombie APIs

This category is not about a flaw in an endpoint. It is about an endpoint nobody is thinking about, which is a different problem and often a larger one.

OWASP lists it as API9:2023 Improper Inventory Management, with CWE-1059 as its reference.

Two ways the list goes wrong

Zombies are versions and endpoints that were replaced and never switched off. Version 1 keeps answering after version 2 ships, carrying the code it had on the day it was superseded, which means it misses every fix since. An attacker comparing the two versions gets a map of what was fixed and a live host that still has it.

Shadows are endpoints that answer without being written down. A debug route, an internal tool, a one-off partner integration or a feature that shipped from a branch that never reached the specification. They are outside the process, so the reviews and tests that cover the documented surface do not cover them.

Both are the same failure seen from two sides. The list of what you run and the set of what answers have drifted apart, and security work is being applied to the list.

Non-production environments are part of the inventory

OWASP's guidance is explicit about this, and it is the part teams underestimate.

A staging or demo deployment usually has weaker controls, because that is what makes it convenient. When it also carries production data, or a copy of it, the weaker controls now protect real records. The guidance is that if production data must be used outside production, that deployment needs the same security controls as production, at which point the convenience has been paid for honestly.

Retiring something is a process, not a deletion

The reason zombies survive is that switching an old version off breaks a consumer you cannot enumerate, so nobody does it and the decision is deferred indefinitely.

What breaks that cycle is announcing the end date before it arrives, signalling it on the responses themselves, and watching whether anyone is still calling. The mechanics of that are the subject of the versioning guide, which covers deprecation and the Sunset header and running multiple versions at once. The security argument for doing it is this chapter, because an old version that nobody plans to switch off is an old version nobody plans to patch either.

In Routebase

api9-inventory runs two discovery probes and raises Medium findings from both.

The old-version probe reads the base URL, and where the path contains a version segment it requests every lower version down to zero. Anything that answers successfully is reported as a still-reachable old version. The shadow-endpoint probe sends OPTIONS to a small set of conventional paths, including /admin, /api/internal, /health, /metrics and /openapi.json. A path that answers with a 2xx, 401 or 403 is flagged as reachable but undocumented.

Both probes produce expected findings on a healthy API, which is why they are Medium rather than higher. A health endpoint is meant to answer, a metrics endpoint is meant to answer to your monitoring, and an old version you are patching deliberately is a decision rather than an oversight. Mark those as accepted risk with the reason, and the next scan stops arguing with you.

The other half is the retirement itself. A deprecation plan carries a sunset date, an optional successor endpoint and a migration guide. The intent to remove an endpoint then exists as a record with a date on it rather than as a conversation.

See Deprecation for the retirement workflow, Versioning for version aliases and status, and the Scanner Reference for the two probes.