- › Every API security control assumes an inventory, and the inventory is the part almost nobody has.
- › The dangerous endpoints are the old versions still running, because they were built before the controls you are proud of.
- › Four discovery sources cost nothing and contradict each other usefully: the gateway, DNS, the load balancer, and your own code.
- › A deprecated endpoint that still answers is not deprecated, it is undocumented, and those are different risks.
- › Publish the count before you publish the fix, because the number is what gets the work funded.
Open an electrical junction box in a building that has been extended three times and you will find more wires than the box was built for, none of them labeled, several going somewhere nobody currently employed can name. Every one of them is live. That is the honest picture of the API surface at most organizations that have been shipping software for more than about four years.
We have written a fair amount about securing APIs, including best practices, fine-grained authorization, and the machine identities that call them. All of that guidance shares one assumption that goes unstated, which is that you know which APIs you have. Take that assumption away and the rest of it stops being a program and becomes a set of controls applied to whatever somebody happened to remember.
Why the Inventory Is Always Wrong
Carelessness has almost nothing to do with why the inventory is wrong. It drifts because of how endpoints come into existence in the first place.
An API gets built for a mobile app that was retired two years ago, and the endpoint stays up because turning it off requires somebody to confirm nothing calls it. A partner integration gets stood up in a hurry with its own authentication path, on the reasonable grounds that the main gateway could not do what the partner needed in the time available. A version two ships and version one keeps running for the customers who never migrated. Somebody builds an internal tool with an endpoint that was never meant to leave the office, and the office turned out to include a VPN and eventually a cloud egress rule.
None of those are mistakes at the moment they happen. Each one is a reasonable decision made under a real constraint, and each one produces an endpoint that exists in production and appears in no register. The register was accurate on the day it was written and it has been decaying at the rate your organization ships.
The Old Versions Are the Dangerous Ones
Here is the part that changes how you prioritize. The endpoints you have forgotten are systematically more dangerous than the ones you remember, and the reason is chronological rather than technical.
Your current endpoints were built after you introduced rate limiting, after you standardized on the gateway, after somebody wrote the authorization middleware, and after the security review became mandatory. The forgotten ones predate all of it. Version one of an API is running the authorization model you had in 2021, and it is running it against the same database that your properly reviewed version three talks to.
An attacker does not need to defeat your current controls when an older door into the same room is still open. This is why enumeration is the first thing any competent adversary does, and it is the same logic behind external attack surface management: they are building the inventory you did not, and they are doing it from the outside with no access at all.
Four Places to Look, and Why You Need All Four
Any single source of truth will be incomplete, and the useful part is where they disagree. Each of these takes an afternoon.
Your API gateway
Pull every route the gateway knows about. This is the list you probably think of as the inventory, and it is the one that flatters you most, because anything deliberately routed around the gateway is invisible here. Treat it as the floor.
Your DNS records
Enumerate every hostname in every zone you control, including the ones inherited from an acquisition and the ones somebody registered on a corporate card. Hostnames outlive the services behind them, and a name that still resolves to an address you own is a name an attacker will probe. Anything here that is not in the gateway list is your first real finding.
Your load balancer and reverse proxy configuration
Read the actual configuration instead of the diagram. Backend pools accumulate entries the way an attic accumulates boxes, and a pool member that still receives traffic is a live service no matter what the architecture document says. This is usually where the partner integrations surface.
Your own source code
Search the repositories for route definitions and framework decorators. This finds the endpoints that exist in code and are reachable in production without ever having been registered anywhere else, which is the category that the other three sources structurally cannot see.
Run all four and compare. The gateway will show you what you meant to build, DNS will show you what still answers, the proxy configuration will show you what actually receives traffic, and the source will show you what the application will respond to if asked. Every disagreement between them is a real question with a real answer.
Deprecated Is a Word About Documentation
Once you have the list, the sorting question is which endpoints still answer, and age is only a proxy for that. An old endpoint somebody switched off years ago is a line in a spreadsheet, while a recent one nobody registered is a live service.
There is a meaningful difference between an endpoint that has been switched off and an endpoint that has been marked deprecated in a document. The first one is gone. The second one is running, unmonitored, unpatched, excluded from the last three security reviews on the grounds that it was on its way out, and still connected to production data. Deprecation is a statement about the documentation and not about the service, and attackers read the service.
The test is mechanical and takes about a minute per endpoint. Send a request, and if something comes back, that endpoint is in scope for everything: authentication, rate limiting, logging, patching, and your next assessment. If nothing comes back, delete the DNS record too, because a dangling name pointed at infrastructure you no longer control is its own category of problem.
What This Costs and What It Returns
The discovery work is roughly a week for one engineer at most organizations, and it produces two things worth having. Both of them are more useful to a budget conversation than to an architecture one.
The first is the count. Nearly everybody who runs this exercise finds between thirty and sixty percent more endpoints than their register listed, and the number itself is the most useful artifact, because it converts an abstract concern into a figure a budget holder can act on. Nobody funds better API security. People fund closing a gap between 40 documented endpoints and 61 real ones.
The second is a shorter list of things to actually fix. Most of what you find will be legitimate and simply unregistered, which is a paperwork outcome. A small number will be old versions running old authorization against current data, and those are the ones that would have been the incident. Finding four of them in a week is a good week.
Start With the Disagreement
If you do nothing else from this, run the gateway list against the DNS list. It is two exports and a comparison, it takes an afternoon, and the names that appear in one and not the other are the beginning of the real inventory.
Everything in every API security guide we or anybody else has published assumes that list exists. Building it is unglamorous, it produces no architecture diagram, and it is the only step that makes the rest of the program mean anything.
If you want an outside read on your API surface, contact Grab The Axe and we will start by asking for your endpoint inventory and then going to find the rest of it. You can also take our free Human Attack Surface Score to see where the people-shaped gaps sit.
Chris Armour is Director of Information Security at Grab The Axe.
Operating on the philosophy that 'you can't build a secure system if you don't know how to break it,' Chris leads our engineering division. A top 1% National Cyber League competitor, he hardens our digital infrastructure against the very exploits he has mastered.
View Author Page →
