Home / Knowledge hub / Shadow API
Knowledge hub
Shadow API
An API running in production that nobody has documented, tracked or secured.
What it means
A shadow API is an API, or an endpoint on one, that is live in production but missing from your documentation, inventory and security reviews. Nobody is deliberately hiding it. It was added for a feature, a test or a partner and then forgotten.
The related term in OWASP's list is improper inventory management. Nobody is lost, but nobody is looking either. If you do not know what is exposed, you cannot say what was tested, who owns it or who gets paged when it misbehaves.
Why it matters
Unknown endpoints miss the controls that known ones get, such as review, monitoring and routine updates. They may lack authentication, rate limits, logging or recent patches. They are also what attackers find first, because they probe for routes rather than reading your documentation.
For a business, this means exposure you cannot account for. A customer or auditor who asks for an API inventory will notice the gap, and a breach through an undocumented route is harder to explain than one through a known one.
How it shows up
Shadow APIs come from internal services made reachable by mistake, debug or admin routes left in a release, mobile back-ends nobody listed, partner integrations, and endpoints created by frameworks automatically. A new route can ship in a pull request that nobody tagged for review.
Find them by comparing what is documented, such as the OpenAPI specification, with what is seen in gateway logs, source code and a crawl of the live app. Treat any difference as work to do: document it, secure it or remove it. Repeat on a schedule, because new ones appear.
Questions people ask
Shadow API, answered
Is a shadow API the same as a zombie API?
Related, not identical. A shadow API was never documented. A zombie API was documented once but should have been retired.
Both are inventory failures, and both tend to be less protected than the current API.
How do shadow APIs appear?
Through fast releases, internal tools exposed by mistake, forgotten test endpoints, and framework features that create routes automatically.
The common thread is change without a step that updates the inventory.
How do we find ours?
Compare your API specification with gateway or server logs, scan your source for route definitions, and test the live application for paths that your documentation does not list.
Doing all three finds more than any one.
Why are they dangerous if nobody uses them?
Because attackers do. An unused endpoint can still answer requests, often without the authentication or limits that the main API enforces.
Unused is not the same as unreachable. Treat any live route as part of your exposure.
Can an API gateway solve this?
It helps by putting a single front door and a log of what passes through. But routes that bypass the gateway, or services exposed directly, remain unseen.
Pair it with regular discovery and a rule that every route needs an owner.
Sources
Where this comes from
Related
Terms that sit next to this one
Zombie API
An old API version that should be retired but still answers requests.
API inventory
A maintained list of every API you expose, who owns it and what it returns.
API versioning
Running old and new API versions together, and the security gaps the old ones keep.
Attack surface
Everything about your application an outsider can touch.
Forced browsing
Typing the address of a page you were never linked to and finding it opens.
What is exposed that you did not list?
In white-box mode we read your code while testing the running app, so a route that exists in the code gets tested whether or not it is documented, and a finding points to the file and line. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.