When a company commissions an API test, it usually hands over an OpenAPI specification or a Postman collection. That is helpful, and it is also a list of the endpoints somebody remembered to document. The ones that cause trouble are frequently somewhere else.
Where undocumented endpoints come from
Mobile apps are the most common source. They are often built against a version of the API tuned for the app — returning whole objects so the phone can filter them, or skipping checks because “only our app calls this”. Partner integrations add more. Old versions that were supposed to be retired keep running because one customer still uses them.
The OWASP API Security Top 10 has a category for exactly this: improper inventory management. It sits alongside the problems it tends to hide — broken object level authorisation, and object property level authorisation, where an endpoint returns or accepts more fields than it should.
“The specification is a list of the endpoints somebody remembered. Attackers read the traffic instead.”
How we find them
We proxy the mobile and web apps and record every call they make, then compare that with the documentation. We look for version prefixes, predictable naming patterns and references in client-side code. Each new endpoint gets the same authorisation tests as the documented ones — and it is common for the undocumented ones to fail them.
Related engagement The mobile API that trusted the app too much →What to fix
Enforce authorisation on the server for every object and every field, never in the client. Return only the fields each consumer needs, ideally through explicit response schemas. Keep an inventory of every API version that is reachable, with an owner and a retirement date. And route everything through a gateway that logs it, so the next unknown endpoint shows up in your own data before it shows up in someone else’s.