Shadow APIs are API endpoints that are nowhere to be found in your inventory, have no maintenance and monitoring, and nobody knows they're there, but they still exist in production.
Even though they're undocumented, untested, and not secured, they still receive data and accept requests. These are like open side gates in a castle that nobody knows about, but attackers easily find them.
But how often do companies have these endpoints? Often. And they keep growing in numbers.
17% of all tracked endpoints in 2025 are zombie APIs (based on one billion request data report).
38% of cybersecurity breaches happen through zombie endpoints (Gartner's report on API security).
Shadow APIs are often used interchangeably with zombie APIs. They're connected, but not the same. So let's explore the difference, see how we can find them, and what to do once we know their location.
What shadow APIs are (and how they're different from zombie APIs)
The terms get used interchangeably, but they describe different situations.
A shadow API is an endpoint that was never in the official documentation or inventory. It exists, it may be receiving traffic, and the organization doesn't know it's there (or did know once and has lost track of it). Shadow APIs are undiscovered.
A zombie API is an endpoint that was once documented and actively used but has since been abandoned without being decommissioned. It's still live, accessible, and in production, but it receives no (legitimate) traffic. Zombie APIs are forgotten rather than undiscovered.
Both are security risks.
The distinction matters because they require different solutions:
A zombie API needs to be shut down (or revived if consumers still depend on it).
A shadow API needs to be found first, then inventoried, then either secured and documented or shut down.
Now, one termite ant isn't a problem for your wooden construction. 10,000 of them devour your house. That's what API sprawl does to the shadow and zombie APIs problem.
APIs with 100 or more endpoints grew from 4% of production APIs in 2024 to 38% in 2025 (Source: Treblle, Anatomy of an API 2025).
The rate of API creation outpaces the rate of inventory maintenance. This problem can get out of control fast and attackers love them. Shadow APIs don't appear because teams are careless; they just can't keep up (don't have the right tools).
5 ways how shadow APIs appear in the first place
Shadow APIs have consistent origins. Understanding where they come from is the first step toward finding them.
Development and test endpoints are deployed to production. A developer builds a debug endpoint during a sprint and it gets included in a deployment because nobody reviewed what was being deployed. It was never meant for production, never documented, and never removed. In a high-velocity deployment environment, this happens more often than teams expect.
Third-party integrations and SDKs. When you integrate a third-party SDK or service, it may register API routes in your application without you explicitly building them. Webhook receivers, callback handlers, and integration endpoints often appear in production as a side effect of installing a dependency. They're not in your documentation because you didn't write them. Not your fault, but it's your responsibility because it sits on your infrastructure.
Legacy versions left running. An API gets versioned from v1 to v2. However, the old version doesn't magically disappear. It needs to be deprecated, but nobody does that. So the v1 version still keeps running. When you multiply this by hundreds of APIs, you get a parallel API surface that's less secure than current versions because it predates security improvements.
Acquired codebases in M&A. When a company acquires another, it inherits the acquired company's API surface. However, this API surface was built under different security standards, documented differently (or not at all), and integrated into the acquiring company's infrastructure in ways that don't appear in any central inventory. 53% of organizations encountered a critical cybersecurity issue during an M&A transaction, often traced to undocumented APIs in the acquired entity.
Microservice proliferation. In a microservice architecture, individual service teams own their APIs. This is usually built fast. Services that were built quickly, never got proper documentation, or changed ownership, end up outside the central API inventory without anyone deliberately removing them.
Why shadow APIs are a security risk, not just a governance annoyance
Shadow APIs get treated as a documentation problem. They're a security problem that documentation would have caught.
The security risk has a specific shape. Shadow APIs are:
Unmonitored. Nobody is watching the traffic they receive. Attacks land on them without triggering alerts because they're not configured to alert. We found roughly 9 million highly malicious requests, including SQL injection attempts, XSS payloads, and remote code execution probes, among 1 billion production requests. On a shadow API, those attacks are invisible.
Unauthenticated. 47% of production APIs process requests without any form of authentication (Source: Treblle, Anatomy of an API 2025). Shadow APIs are disproportionately likely to fall in that category because they were often built quickly and never hardened. A debug endpoint meant for internal use only gets a public route, and no one adds authentication because it was never supposed to need it.
Untested against current threat patterns. A legacy v1 endpoint was written based on security knowledge from three years ago. It wasn't tested for the attack patterns that emerged since then, and it hasn't received the security patches applied to the current API version. It's a permanently outdated target in your production environment. Even an autonomous AI agent can hack it (like in McKinsey's case).
Outside governance controls. Rate limiting, WAF rules, and API gateway policies are configured against the known API surface. Shadow APIs sit outside that perimeter. An attacker who discovers a shadow endpoint is effectively operating in a gap in your defenses.
The security problem with shadow APIs is that the team's security controls assume they don't. Monitoring, alerting, and defensive tooling configured against the documented API surface provides no coverage for endpoints that aren't on that list. You can't defend what you can't see.
How to discover shadow APIs in your infrastructure
Discovery requires looking in more than one place because shadow APIs don't appear in any single source of truth.
Source code scanning. Scan source repositories, even the ones that the API team doesn't directly own, such as those from acquired companies or third-party integration projects. This will surface endpoints that were never registered in any external catalog. Treblle's API Discovery scans GitHub repositories automatically, identifying route definitions and surfacing endpoints that don't appear in the known API inventory.
Traffic analysis. Production traffic logs contain requests to every endpoint that received a call in a given window. Any endpoint that appears in traffic logs but is absent from the documented API surface is, by definition, a shadow API. This approach finds endpoints that are actively receiving requests. Treblle's Real-Time Request Explorer captures every API call with full request context and no sampling, enabling identification of traffic patterns on undocumented routes that shorter retention periods or sampled logs would miss.
API gateway and infrastructure scanning. Routes registered in API gateways, load balancers, and service mesh configurations represent the endpoints that are actually reachable from outside the service. Gateway configs and infrastructure-as-code repositories are often more up to date than documentation and more complete than source code (which may include endpoints that were never deployed).
Network traffic analysis. In environments where application-level scanning isn't complete, network traffic analysis can surface API calls between services that other methods didn't capture. This is more complex to set up, but catches shadow APIs at the infrastructure level.
In practice, running all four in parallel gives the most complete picture. Shadow APIs hide in different places depending on how they appeared: a legacy v1 endpoint shows up in traffic analysis; a never-deployed debug route shows up in source scanning; an acquired company's API shows up in gateway config review.
What to do once you find them
Discovery produces a list. The list requires a decision for every entry: keep and secure, document and maintain, or shut down.
Triage by traffic and risk. Endpoints receiving active traffic with no authentication are the highest priority because they're live, exposed, and unprotected. Endpoints receiving no traffic are lower urgency but still need a decision: shut down or move to active maintenance.
Identify ownership. Shadow APIs need a team or an individual who is responsible and accountable for the endpoint. Endpoints with no identifiable owner should default to shutdown unless a consumer can be identified who depends on them.
Apply authentication and rate limiting before re-documenting. Before adding a shadow API to the official inventory, bring it up to the same security baseline as the rest of the API surface: authentication enforcement, rate limiting, and input validation. Adding an unsecured endpoint to the documentation makes it official, but not safe.
Add to the API catalog with full metadata. Once secured, register the endpoint in the API catalog, specifying ownership, environment, category, and a deprecation timeline. Treblle's API Catalog supports this: discovered endpoints can be registered with metadata fields, making the catalog the single source of truth for what's running and who owns it.
Decommission cleanly. A server-side deletion is the first step in an API shutdown. Decommission means: notifying any consumers (identified through traffic analysis), returning 410 Gone rather than silently dropping requests, removing the route from all documentation, and verifying the route no longer appears in any subsequent discovery scan. A route that returns 410 is decommissioned; a route that's deleted from the source but still reachable via an old deployment is not.
Close the discovery loop. It's not a one-off. Discovery needs to be continuous so that new shadow APIs are identified quickly rather than letting them accumulate. Treblle's multi-source discovery runs continuously: GitHub scanning, gateway integration, and live traffic analysis in parallel, with new endpoints surfaced as they appear rather than in quarterly audits.
For a broader context on how to secure shadow endpoints once found, read the API security best practices article, which covers it in detail.
5 ways how Treblle helps discover, secure, and govern shadow APIs
API Discovery (Multi-Source). Surfaces shadow APIs from three sources simultaneously: GitHub repository scanning, API gateway integrations, and live traffic analysis. New endpoints appear in the inventory as they're discovered rather than accumulating between manual audits.
API Catalog. Provides the central registry where discovered endpoints are registered with ownership metadata, environment tags, and category. Gives the organization a single source of truth for what's running and who's responsible for it.
Authentication Coverage Tracking. Identifies which endpoints process requests without authentication, with shadow APIs disproportionately likely to surface here. Shows the gap between what the documented API surface shows as secured and what traffic analysis reveals is actually open.
Real-Time Request Explorer. Captures every API call with full request context and no sampling. This makes it possible to identify traffic on undocumented routes that sampled or short-retention logs would miss, the primary method for finding shadow APIs that are actively receiving requests.
Automated Threat Scanning. Scans traffic on all endpoints, including undocumented ones, against 20+ threat categories in real time. Shadow APIs that are receiving attack traffic show up in the threat scan before they appear in any manual discovery process.
A shadow API is an API endpoint that exists in production infrastructure but isn't in the organization's official API inventory or documentation. It may be receiving traffic from internal or external sources, but nobody is actively maintaining, monitoring, or securing it. Shadow APIs typically appear through development endpoints promoted to production, third-party SDK integrations, legacy versions left running, or APIs inherited through acquisitions.
What is the difference between a shadow API and a zombie API?
A shadow API was never in the official inventory — it's undiscovered. A zombie API was once documented and used but has been abandoned without being decommissioned — it's forgotten. Both are security risks, but they require different responses: shadow APIs need to be found and inventoried first; zombie APIs are already known and need a formal decommission process.
Why are shadow APIs a security risk?
Shadow APIs sit outside the security controls configured against the documented API surface. They're typically unmonitored (no alerting), unauthenticated (built for internal use, never hardened), untested against current threat patterns (especially legacy versions), and outside WAF and gateway policies. An attacker who finds a shadow endpoint is operating in a gap in the organization's defenses.
How do you find shadow APIs?
The most complete approach combines source code scanning (to find route definitions in repositories), traffic analysis (to find endpoints receiving requests that aren't in the documentation), API gateway and infrastructure config scanning (to find routes registered in gateways and load balancers), and network traffic analysis (for internal service-to-service calls). Running all four in parallel catches shadow APIs that would be missed by any single method.
What should you do when you find a shadow API?
Triage by traffic and authentication status — actively used, unauthenticated endpoints are the highest priority. Identify ownership through git history or deployment logs. Apply authentication and rate limiting before adding to the official inventory. Register in the API catalog with full ownership metadata. Decommission endpoints that aren't needed, returning 410 Gone rather than silently deleting the route. Establish continuous discovery to prevent the inventory from drifting again.
