Ask a security team how many APIs their company runs and you will usually get a number. Ask engineering the same question and you will get a different one. Ask us after a week of testing and you will get a third number, and it is almost always the largest. That gap is not a documentation problem. It is an attack surface problem. Every endpoint that exists but is not on anyone's list is an endpoint that no one has threat modeled, no one has rate limited, and no one has reviewed for authorization logic. Attackers do not care about your inventory. They enumerate what is actually reachable.
Why APIs Became the Primary Attack Surface
The application you present to the world is mostly a thin client now. The browser or mobile app renders state; the API does the work. That inversion moved the interesting logic — pricing, entitlements, account relationships, data access — behind HTTP endpoints that speak JSON and expect a token. Attackers followed, because that is where the decisions are made.
APIs are also honest in a way that user interfaces are not. A web form hides fields, disables buttons, and validates input before submission. The API underneath frequently accepts all of it anyway. When we test an application, one of the first things we do is stop using the interface entirely and talk directly to the endpoints it calls. The controls the front end implied are often the only controls that existed.
How Sprawl Actually Happens
Nobody decides to run undocumented APIs. Sprawl is an accumulation of individually reasonable choices.
- Microservices multiply endpoints: decomposing a monolith turns one internal function call into a network-addressable service, and each service exposes its own surface with its own authorization assumptions.
- Shipping speed outpaces governance: a feature ships Friday with a new versioned endpoint, and the inventory spreadsheet is updated whenever someone remembers.
- Acquisitions inherit unknowns: you buy a company and you buy its API estate, including endpoints whose original authors have moved on.
- Partner integrations create side doors: a one-off endpoint built for a single integration is rarely deprecated when that integration ends — it just stops receiving attention.
- Versions never die: v1 stays online because one client still calls it, and v1 predates the authorization middleware you added in v2.
The result is two categories worth naming. Shadow APIs are endpoints that exist without ever entering the inventory. Zombie APIs are endpoints that were retired on paper but still answer requests. Zombies are frequently the more dangerous of the two, because they carry old code, old assumptions, and old data access with none of the current controls.
The Flaws We Find Behind Undocumented Endpoints
The OWASP API Security Top 10 is a useful conceptual map here, and the patterns it describes show up consistently in real engagements.
- Broken object-level authorization: the endpoint checks that you are authenticated, then trusts the object ID in your request. Change the identifier and you read someone else's record. This is the single most common serious API finding we report.
- Broken authentication: tokens that do not expire, refresh flows that can be replayed, or endpoints that accept a valid token issued for a different scope entirely.
- Excessive data exposure: the API returns the full object and expects the client to display only part of it. The internal notes, the password hash, the other tenant's identifier — all of it is sitting in the response body.
- Missing function-level authorization: the administrative endpoint is not linked anywhere, so it was never given a role check.
Shadow and zombie endpoints concentrate these flaws because they were never subject to the review that caught them elsewhere.
Why Scanners Are Not Enough
Automated tooling is good at the things that look like patterns: injection payloads, known CVEs, missing headers, TLS configuration. It is structurally bad at authorization. A scanner sends a request, gets a 200, and records success. It has no concept of whether that record was supposed to belong to you.
Business-logic flaws are the same story. A scanner cannot tell that applying the same discount code eleven times should have failed on the second attempt, or that a workflow meant to require approval can be completed by skipping straight to the final state transition. Those require a human who understands what the application is for. That is the core of our API penetration testing work — enumerating what actually exists, then reasoning about it the way an attacker with a valid account would.
Discovery First, Then Testing
You cannot test what you have not found, so the work starts with discovery: traffic analysis, specification review, subdomain and route enumeration, mobile and single-page application teardown to extract the endpoints the client actually calls. Compare that against the documented inventory and the delta is your immediate priority.
Then test it properly, with multiple accounts at multiple privilege levels, which is the only way object-level authorization gets exercised honestly. This fits inside the same discipline as our broader application penetration testing services, because in practice the API and the application are the same system viewed from different angles.
Where to Start
Treat API inventory as a security control, not a documentation nicety. Make endpoint registration part of the deployment path, set real deprecation dates and enforce them, and assume the estate is larger than the list until someone has proven otherwise.
If you want to know what your API surface actually looks like from the outside, get in touch. We will tell you what we find, including the endpoints you did not know you had.