Security basics
Shadow APIs: how to find and secure them
Why undocumented and forgotten APIs are a security gap, how impersonated callers exploit them, and what a buyer should expect from an API security program.
Key takeaways
- You cannot protect an API that is missing from your inventory.
- Shadow APIs skip review; zombie APIs outlive their replacement.
- Reconcile declared specifications against live traffic to find gaps.
- Authenticate both the calling service and the end user on every call.
- Validate requests and responses against the API schema.
A shadow API is an endpoint that runs without being documented, inventoried or security reviewed, such as a test or debugging interface left reachable. You secure shadow APIs by finding them, through an inventory reconciled against live traffic, then giving each one an owner, a specification, strong caller authentication and schema validation, or switching it off.
What is a shadow API?
Many companies run more APIs than they have listed. Product teams build them for mobile apps, partner integrations, internal tools and quick fixes, and not every one reaches the catalog or the security review.
Definition
A shadow API is an endpoint that is live and reachable but missing from the organization's API inventory, so nobody reviews, monitors or patches it as part of normal security work.
NIST's guidance on API protection describes two flavors of the problem. Rogue or shadow APIs are those "defined for internal use (e.g., debugging, testing, ad hoc solutions to business problems)" which "may not be appropriately documented and often bypass standard security review practices."[2] Zombie or deprecated APIs have been replaced by newer systems but not fully removed, for example because callers have not migrated or no team is responsible for them any more.[2]
We cover this topic as context for buyers who are weighing API security tools and partners. It is not a service we sell.
Why do shadow APIs appear?
NIST notes that most organizations have gaps in their API inventories, even when their other inventory management is mature.[2] The reasons it lists are organizational more than technical: APIs are built by many teams, deployed across cloud and on-premises environments and inherited through mergers, and inventories lack automation.[2]
In practice that looks like:
- An endpoint built for one sprint that never got registered.
- An older version kept "just in case" after a new one shipped.
- A staging or test deployment that is reachable from the internet.
Why are they a security risk?
The OWASP API Security Top 10 lists improper inventory management as its own risk. It says threat agents "usually get unauthorized access through old API versions or endpoints left running unpatched," and that outdated documentation makes vulnerabilities harder to find and fix.[1] It also flags blind spots such as having no retirement plan for each version and data flowing to third parties without a business justification or approval.[1]
A forgotten endpoint tends to miss whatever changed since it was built: a new authentication standard, a tightened permission model, a rate limit or a logging rule. That gap is what makes it attractive.
How does API spoofing fit in?
In this article, API spoofing means a caller pretending to be someone it is not: a script presenting a stolen API key, a token replayed from another client, or a lookalike endpoint posing as a trusted service. Shadow APIs make this easier because they often rely on weaker checks, such as a static key, and nobody watches their logs.
NIST points out that every API call carries at least two identities, the software calling the API and the end user of that software, and recommends authenticating and authorizing both.[2] When a service accepts a request only because it arrives from inside the network, a spoofed caller has less to overcome.
Want this checked on your account?
A free growth diagnostic finds your top 3 leaks. Written findings in 2 business days.
How do you find shadow APIs?
Start with what you know, then compare it with what is running. OWASP's prevention advice begins with "Inventory all API hosts and document important aspects of each one of them," including the environment each runs in, who should have network access and which version is live.[1]
NIST recommends an organizational inventory of all internal and external APIs, explicitly including shadow and zombie ones, with each API's specification, its owner and runtime information.[2] It adds that API discovery tools should run at runtime and that declared specifications should be reconciled with live traffic, to find differences between what is deployed and what should be, "including shadow, orphan, and zombie API endpoints."[2]
A specification format gives that inventory a common shape. The OpenAPI Specification defines "a standard, programming language-agnostic interface description for HTTP APIs."[4] OWASP also recommends generating documentation automatically by adopting open standards.[1]
How do you stop spoofed callers?
Identity between services matters as much as identity for users. NIST describes services validating workload identity through the transport, for example with mutual TLS certificates, in addition to user tokens.[2]
For OAuth, RFC 8705 defines mutual TLS client authentication and access tokens bound to a client certificate. With a certificate-bound token, "only the party in possession of the private key corresponding to the certificate can utilize the token."[3] A copied token alone is then not enough.
Other controls that help:
- Replace long-lived static API keys with short-lived, scoped credentials where the platform allows it.
- Authorize the calling service and the end user separately on each request.[2]
- Rotate and revoke credentials when an integration or partner ends.
What role does schema validation play?
NIST recommends validating each request and response against the API schema before the business logic processes it, so applications only receive well-formed input and responses do not leak data they should not.[2] It also recommends the order: authenticate, authorize, then validate, because validation messages can leak information.[2]
Validation does not catch a well-formed request with stolen credentials, so it works alongside identity checks and monitoring, not instead of them. NIST recommends logs, metrics and traces tagged with the API being called, so that enforcement results and errors can be tied back to a specific endpoint.[2]
What should you ask API vendors?
If you are assessing tools or a specialist firm, useful questions are:
- How does discovery work: from gateway configuration, from live traffic, or both?
- Does it reconcile what it finds against our specifications and flag the difference?
- How does it record an owner for each endpoint?
- Which identity controls does it check for between services?
Illustrative sample
A hypothetical software company compares the endpoints in its API catalog with what its gateway and service mesh actually see in traffic. It finds a few versioned paths with no named owner, assigns each one to a team, and either documents and secures it or schedules it for retirement.
Where does this fit in wider security?
Shadow APIs are one part of a broader visibility problem: assets that exist outside the list you defend. The same pattern shows up with forgotten DNS records in subdomain takeover, with stolen session tokens in session hijacking and with network access in zero trust network access. For the human side of account security, see our executive cybersecurity checklist. Our wider digital asset security work focuses on domains, email authentication and impersonation.
Sources
Written under our Editorial and AI Policy. Sources checked 19 Oct 2026. Reviewed by DGo Digital on 19 Oct 2026.
FAQ
Questions about shadow APIs
A shadow API was never properly documented or reviewed, for example an endpoint built for testing or debugging. A zombie API was once known but has been replaced, and still runs because callers have not migrated or no team owns it any more. NIST guidance treats both as inventory gaps.