Shadow API discovery is the practice of finding active but undocumented, ungoverned API endpoints that live outside your official inventory and security controls. Most tools discover them by watching live traffic. Reading source code finds them earlier and more completely, including endpoints that no request has hit yet.
Key takeaways
- Shadow APIs are live endpoints your inventory does not know about. In one measurement across real traffic, Cloudflare discovered 30.7% more API endpoints than organizations had self-reported: nearly a third of the API estate was invisible.
- Runtime and gateway discovery can only see an endpoint that is already taking traffic through a sensor. Anything deployed-but-quiet, internal-only, behind a different gateway, or long-forgotten stays hidden exactly while it is most exposed.
- Source-derived discovery reads supported REST codebases to find documented, undocumented, shadow, and zombie endpoints before deployment.
- OWASP lists Improper Inventory Management as API9:2023 for a reason: you cannot secure, patch, or retire what you never catalogued.
The endpoints you never wrote down
Every engineering team ships APIs faster than it documents them. A quick fix adds a route on a Friday. A v1 endpoint gets superseded but never turned off. An internal service gets a public path "just for testing." None of it lands in the official spec, and all of it is reachable.
Cloudflare's 2024 API Security and Management Report found 30.7% more endpoints through automated discovery than customers had self-reported. That is enough to turn inventory drift from an operational nuisance into a security problem: a meaningful part of the API estate can sit outside the systems that document, test, and govern it.
The category has a vocabulary problem, so let us fix it before going further.
Shadow, zombie, undocumented: what actually differs
- Undocumented API: a live endpoint with no spec entry. Not necessarily malicious or old, just unrecorded.
- Shadow API: an undocumented endpoint that also sits outside your security and governance controls. That missed review may also mean missed auth, validation, logging, or rate limiting controls.
- Zombie API: a deprecated version or endpoint that was never decommissioned. It still answers requests, often on older, weaker security requirements.
OWASP folds all three under API9:2023, Improper Inventory Management, and is blunt about the cost: "Lack of assets inventory and retirement strategies leads to running unpatched systems, resulting in leakage of sensitive data." Attackers, OWASP notes, "usually get unauthorized access through old API versions or endpoints left running unpatched."
Why the invisible ones are the dangerous ones
A shadow endpoint is not just an untracked one. It is often an untested one. Because it never went through the process that documents an API, it may also miss the process that secures it: explicit authentication checks, input validation, logging, or rate limits. That makes it an unusually soft target on your perimeter, and nobody is watching it.
The breach record is consistent. In September 2022, Optus disclosed a breach affecting millions of current and former customers after attackers obtained customer data through what public reporting and Australian government comments described as an exposed or vulnerable API. In January 2023, T-Mobile disclosed that an attacker had abused a single vulnerable API to pull data on about 37 million accounts, undetected for roughly six weeks. In both cases the failure was not an exotic zero-day. It was an endpoint doing exactly what it was built to do, with no one accounting for it.
You cannot patch, monitor, or retire an endpoint you do not know exists. Discovery is the control that makes every other control possible.
Three ways to discover an API, and where each one goes blind
There are really only a few ways to find your APIs, and they differ by what they can observe.
- Spec or inventory upload. You test what you documented. By definition it cannot surface the undocumented, which is the entire shadow problem.
- Runtime traffic mirroring. Watch live traffic and infer endpoints from what fires. Powerful for behavior analysis, but it can only see an endpoint after it has taken a request through the sensor.
- API gateway discovery. Catalog what routes through the gateway. Anything behind a different gateway, or none, is out of view.
- Source-derived discovery. Read the application code and enumerate route definitions in supported frameworks, whether or not those routes have ever been called.
The first three share one structural blind spot: they can only discover an endpoint that is already generating observable traffic through a sensor you control. That is the exact condition a dangerous shadow or zombie API violates. The deployed-but-not-yet-called route, the internal-only service, the forgotten version, the quick fix behind a different ingress, none of them produce the traffic those methods depend on. They stay invisible while they are most exposed.
| Capability | Spec upload | Runtime traffic | API gateway | Source-derived |
|---|---|---|---|---|
| Finds documented endpoints | Yes | Yes | If routed | Yes |
| Finds undocumented endpoints | No | Only once called | Only if routed | Yes, in supported codebases |
| Finds shadow endpoints | No | Only once called | Only behind it | Yes, in supported codebases |
| Finds zombie endpoints | No | Only if still called | Only if routed | Yes, if still in code |
| Needs live traffic | No | Yes | Yes | No |
| Needs a proxy or gateway | No | Sometimes | Yes | No |
| Finds endpoints pre-deployment | No | No | No | Yes |
| Produces a testable spec | Sometimes | Sometimes | No | Yes |
To be fair to runtime discovery: it is the right tool when you have no source, such as a third-party or black-box API you consume but do not own. For that surface, watching traffic is often the only option. The point is not that one method is useless. It is that source-derived discovery is the strongest way to find first-party shadow and zombie endpoints before an attacker's scanner does, because you can read code you already own even when you cannot watch traffic you have never seen.
Discovering APIs from the code that defines them
NightVision discovers REST APIs directly from source code rather than from captured traffic. For supported codebases, it statically analyzes an application's route definitions and parameters and writes an OpenAPI specification, without needing a running application or a proxy to record live requests. Because the inventory is derived from the code, it can surface undocumented and shadow endpoints that never show up in traffic logs.
Two properties fall out of that approach:
- Completeness. Coverage is a function of what you can observe. Source gives you a view into the routes defined in the application, not just the ones that happened to take a request during a capture window.
- Timing. Reading source finds the endpoint at commit or build time, before it is deployed and before it is exposed. Discovery shifts left instead of arriving after the fact.
This is the discovery-first argument we made in You Can Learn a Lot From Discovery, and the same reason AI-assisted development is widening the gap, covered in Beware the Invisible APIs: endpoints are being generated faster than any team documents them, and the only inventory that keeps up is one drawn from the code itself.
From a discovered endpoint to a tested one
An inventory is a means, not an end. Finding the endpoint only matters if you then prove whether it is exploitable. Because NightVision's discovery produces the API surface as a spec, that spec can feed straight into dynamic testing: discovered endpoints can be exercised for real vulnerabilities, not merely listed in a catalog. Discovery and validation can happen on one platform, not as a handoff between two tools.
And when a finding comes back, it is anchored to the exact source location that produced it, which is what makes it trustworthy and fixable. That is the subject of Source-Linked DAST: The Answer to Findings AI Can't Reproduce Twice. Determinism on the finding, agents on the fix, humans on the merge. It starts with discovery: none of that chain runs on an endpoint you never found.
Related readingPart of our series on modern application security testing. Start with What You Should Know About Application Security Testing, see how source-derived discovery supports API inventory integrity, and read the wider trust argument in Autonomous Penetration Testing: A CISO Reality Check.
Frequently asked questions
What is a shadow API?
A shadow API is a live endpoint that exists outside your documented inventory and your security governance. It may have been deployed without the review that would have checked authentication, validation, logging, or rate limiting, so it is both untracked and often untested.
What is the difference between a shadow API and a zombie API?
A shadow API is an undocumented endpoint that was never brought under governance. A zombie API is a deprecated version or endpoint that was supposed to be retired but is still answering requests, usually on older and weaker security requirements. Both are invisible to an inventory; both expand your attack surface.
How do shadow APIs happen?
Speed and drift. Quick fixes, internal test routes that get exposed, microservice sprawl, and CI/CD churn all ship endpoints faster than teams document them. AI coding assistants accelerate this further by generating routes in bulk. The endpoint is real long before it is recorded anywhere.
How do you detect shadow APIs?
Three broad methods: analyzing live traffic, inspecting an API gateway, or deriving the API surface from source code. Traffic and gateway methods only see endpoints that are already receiving requests through a sensor. Source-based discovery reads supported first-party code and finds route definitions, including ones with no traffic yet.
Can you discover APIs from source code?
Yes. For supported REST codebases, static analysis of the application's routes and parameters produces an OpenAPI specification directly from the codebase, no running app or proxy required. This approach can catalog documented, undocumented, shadow, and zombie endpoints before deployment.
Why are shadow APIs a security and compliance risk?
Because they sit outside normal inventory and review, they can miss authentication, input validation, logging, and rate limiting controls, making them harder to assess and easier to expose. They can also handle data no one is auditing, creating GDPR, HIPAA, or PCI risk. OWASP ranks the underlying problem, improper inventory management, as API9:2023.
How do you prevent shadow APIs?
You cannot prevent developers from creating endpoints, and you should not try. You prevent shadow APIs from becoming shadow risk by making discovery continuous and source-based, turning the resulting inventory into an enforceable control, for example a policy gate in CI/CD, so a new endpoint can be catalogued and tested when it is committed.
See your full API surface
You cannot secure traffic you have not seen yet. You can secure code you can read. NightVision discovers REST APIs from source for supported codebases, documented and shadow alike, and can test the discovered surface, with findings anchored to the source line that caused them. NightVision is SOC 2 Type II attested; report available under NDA.