Shadow API
A shadow API is an interface that is live and reachable but absent from the inventory the organisation defends: undocumented, forgotten after a migration, or left running from a version that was supposed to be retired. It is authenticated and monitored to whatever standard applied on the day it was built, which is usually none.
They accumulate in predictable ways. A versioned endpoint stays reachable after the client moves on. A staging host is left resolvable. An internal service is exposed to a partner through a gateway and never added to the register. A mobile application calls a backend that the web team does not know exists. In each case the gateway policies, the rate limits and the logging that protect the documented estate simply do not apply.
On an external engagement they are among the first things we look for, and the sources are unglamorous: certificate transparency records, DNS enumeration, JavaScript bundles that name hosts the site never calls, mobile application traffic, and specification documents left published at conventional paths. An old version of an endpoint frequently answers with weaker authentication than its replacement, which is what makes the finding matter.
The finding is written against the inventory process rather than the individual host, because the specific endpoint we found is evidence of a gap rather than the gap itself. The durable fix is that every published interface is discovered by attack surface management and reconciled against the asset inventory, with retirement treated as a deployment step. This is where the API testing that starts from what we can find rather than from the documentation earns its place.