Most organisations think they know what APIs they expose. The reality on the wire usually tells a different story. Forgotten development endpoints, undocumented administrative paths, legacy versions left running for a single integration partner and shadow APIs deployed without architectural review all expand the attack surface in ways that never appear in the official inventory. The discrepancy between what you think is exposed and what is actually exposed is a major source of breaches.
How Endpoints Stay Hidden In Plain Sight
API endpoints accumulate over time. A new version goes live, the old one stays running for backward compatibility, and a year later nobody remembers it exists. Internal tools get exposed during development and never get removed. A subdomain set up for a one-off campaign continues to serve admin functions long after the campaign ended. None of this is unusual. All of it adds up to attack surface that nobody is actively defending. A serious vulnerability scan services programme will continuously enumerate your real surface, not just the surface the architecture team believes exists.
Discovery Techniques That Actually Work
Effective discovery combines several sources. DNS data reveals subdomains. Certificate transparency logs surface hosts that were never published. JavaScript bundles in production applications reference API paths that nobody documented. Mobile application packages expose endpoint URLs in plaintext. Public archive sites preserve old configurations. None of these techniques are exotic. They are exactly the techniques an attacker will use, and there is no reason your own security team should not get there first.
Expert Commentary
William Fieldhouse, Director of Aardwolf Security Ltd
In nearly every external engagement we find at least one endpoint that the client did not know was still online. It is almost a running joke at this point. The interesting question is rarely whether you have orphan APIs out there. It is how many, and how sensitive the data behind them is.
Continuous Discovery Beats Annual Inventories
Static API inventories age badly. The endpoints in production today may not match the documentation written six months ago. Continuous discovery uses traffic logs, gateway data and outside-in scanning to maintain an inventory that reflects reality. Combine continuous discovery with a workflow that brings newly found endpoints into governance quickly. The discovery is only useful if something happens after the alert. Treating endpoint discovery as continuous infrastructure rather than as a project that runs once produces measurably better inventories. The cost is modest. The protection against shadow APIs is significant.
Decommissioning Is A Security Control
Once you find an endpoint that should not be running, decommission it properly. Renaming a route does not remove the route. Removing the documentation does not remove the route. The only safe decommissioning involves traffic verification, code removal and infrastructure cleanup, in that order. A focused web application pen testing engagement after the cleanup confirms the surface is genuinely smaller and not just hidden behind a different prefix.
You cannot defend what you do not know you have. Inventory is the foundation of every other API security control. API inventory is unglamorous, unfinishable and absolutely essential. The teams that treat it seriously avoid most of the headlines that other teams generate. API security is harder than web application security in some respects and easier in others. The teams that understand the differences and design their controls accordingly tend to produce better outcomes than the ones that simply apply web thinking to API problems.