Ghost APIs

At every audit, the same exercise: we ask how many APIs the organisation has, we note the answer, then we go and measure. The ratio between the two figures is remarkably stable, between two and three. An organisation that declares 80 APIs usually exposes between 150 and 250.

The difference is the ghost APIs: exposed, called, and absent from every inventory.

Where they come from

Nobody creates a ghost API on purpose. They come out of entirely ordinary situations:

• the "mobile app" API, exposed directly by the team that was up against a deadline, bypassing the platform "temporarily", four years ago.
• the debug endpoint opened for an incident and never closed again.
• the microservice whose "internal" API is called by three other teams that found it in the code.
• the previous version, officially decommissioned, actually still called by two forgotten consumers.
• the SaaS integration that exposes an inbound webhook nobody watches.

None of these cases is exotic. All of them probably exist in your organisation right now.

Why it is the number one risk

A ghost API stacks up everything a platform is supposed to prevent: no consistent authentication, no quotas, no centralised logs, no owner you can reach, no security patching that anyone follows.

The most widely reported data exposure incidents of recent years share this pattern: it is not the API in the catalogue that leaks, it is the one nobody was looking at. The security of an estate is measured at its weakest point, and the weakest point is by construction outside the catalogue.

That is why discovery is a pillar in its own right, and not a portal convenience: you only govern what you can see.

How to flush them out

No single source is enough on its own. Reliable mapping cross-references four viewpoints:

1. Traffic. The logs of the load balancers, the reverse proxies and the internal DNS say what is really called, over HTTP, on paths that look like APIs. It is the most faithful source and the least flattering.
2. Code. The repositories hold the exposed routes: a sweep of the annotations and the routing files across every repository turns up a list of endpoints that nobody ever declared.
3. Infrastructure. Ingress objects, cloud API gateways, security groups open on 443: the infrastructure inventory reveals the exposure paths, including the ones that go through no platform at all.
4. People. A one hour interview per business domain with the question "who calls you, and who do you call?" always brings up flows that nothing else was showing.

The result is not only a list. It is a gap: declared catalogue against observed estate. That gap is the most honest measure of a platform's maturity, far more than its number of policies.

What comes next

Every API discovered gets an explicit fate, and there are only three: onboard it to the platform, decommission it with a date, or document an accepted exception with an owner. The fourth fate, oblivion, is the one you have just paid to eliminate.

The point that matters is recurrence. A map is a photograph, and the estate moves every week. Mature organisations replay the detection continuously, by wiring the traffic-versus-catalogue comparison into their monitoring. The others will run the exercise again in three years, and will find the same one to three ratio.