Your security team has documented every API endpoint in the company. Your API gateway enforces authentication on all registered routes. Your penetration test covered every endpoint listed in the Swagger documentation. And yet, an attacker just exfiltrated 2.3 million customer records through an API endpoint that nobody on your security team knew existed.
This is the reality of API security in 2026. According to industry research, 99% of enterprises experienced at least one API security incident in the past year. The majority of those incidents did not involve documented, governed endpoints. They involved the APIs that organizations did not know they had: shadow APIs that were never registered, and zombie endpoints that should have been decommissioned years ago.
The average enterprise now runs hundreds of microservices, each exposing dozens of API endpoints. The documented API inventory represents only a fraction of what actually exists in production. The gap between what security teams think they are protecting and what actually needs protection is where breaches happen.
What are shadow APIs?
Shadow APIs are undocumented endpoints that exist in production but are not tracked in your organization's API inventory. They were created by developers, deployed through standard CI/CD pipelines, and are actively serving traffic. The only thing missing is awareness: nobody on the security or governance team knows they exist.
Shadow APIs are not the result of malicious intent. They form through the normal pressures of modern software development. A backend developer creates a quick internal endpoint to help the frontend team unblock a sprint. A DevOps engineer builds an admin API for a migration script and forgets to remove it. A third-party integration requires a webhook receiver that gets deployed directly to production without going through the API registration process.
The defining characteristic of a shadow API is that it operates outside the security perimeter your organization believes it has established. It is not monitored by your API gateway. It is not covered by your API security testing. It does not appear in your threat model. And because nobody knows it exists, nobody is checking whether it enforces authentication, authorization, rate limiting, or input validation.
How shadow APIs form in practice
Understanding the formation patterns helps organizations build prevention strategies. Shadow APIs emerge from several common scenarios.
Microservices sprawl. As organizations decompose monoliths into microservices, each service develops its own API surface. Service-to-service communication endpoints multiply rapidly. A company with 50 microservices might have 200 documented customer-facing endpoints and 800 internal service endpoints that nobody has inventoried. Those internal endpoints often have weaker authentication because they were designed to run behind a service mesh, but network segmentation gaps or misconfigurations can expose them externally.
Rapid deployment cycles. When teams are shipping multiple times per day, the gap between code deployment and security documentation widens. A developer adds a new endpoint on Monday, it passes code review focused on functionality, deploys through the pipeline on Tuesday, and by Wednesday it is handling production traffic. The API documentation update sits in a backlog that nobody prioritizes. Multiply this across dozens of teams and thousands of deployments per quarter, and the inventory gap becomes enormous.
Legacy migrations. When organizations migrate from legacy platforms to modern architectures, the migration period creates a particularly dangerous window. Both old and new systems run simultaneously. Compatibility shims and adapter endpoints are created to bridge the gap. Temporary data synchronization APIs move information between systems. These transitional endpoints are built for speed, not security, and they frequently persist long after the migration completes.
Development and staging leaks. Debug endpoints, test harnesses, and development utilities get deployed to production through environment misconfiguration or careless promotion. Endpoints like /api/debug/dump-config, /api/internal/seed-data, or /api/test/reset-password were never meant to see production, but infrastructure complexity means they sometimes do. These endpoints often have no authentication whatsoever because they were designed for local development environments.
The scale of the problem: Research from multiple API security vendors consistently shows that organizations have 40-60% more API endpoints in production than they have documented. For a mid-size enterprise with 500 documented endpoints, that means 200 to 300 additional endpoints operating completely outside security governance.
What are zombie API endpoints?
Zombie APIs are the undead of your infrastructure: deprecated endpoints that were supposed to be decommissioned but remain alive and accessible in production. Unlike shadow APIs that were never documented, zombie APIs were once known and governed. They appeared in previous API documentation, were covered by earlier penetration tests, and had security controls applied to them. The problem is that those controls stopped being updated when the endpoint was marked as deprecated.
The typical zombie API lifecycle looks like this: an API version (say, v1) is released with appropriate security controls. A year later, v2 is released with improved authentication, better input validation, and stricter rate limiting. The v1 documentation is removed, clients are notified to migrate, and the security team shifts their focus to v2. But v1 is never actually turned off because a handful of legacy clients still depend on it, or because nobody is sure what will break if it is removed, or simply because the decommission ticket was never prioritized.
The result is that v1 continues running in production with its original, weaker security controls. Authentication improvements applied to v2 were never backported. The newer WAF rules were configured only for v2 paths. Rate limiting was updated only on the current version. The zombie endpoint becomes a time capsule of whatever security posture existed when it was last actively maintained, often years ago.
Why zombie APIs are a favorite attacker target
Attackers specifically hunt for zombie API endpoints because they offer a fundamentally easier path to exploitation. When a penetration tester or attacker identifies that an application runs /api/v3/users, the first thing they test is whether /api/v1/users and /api/v2/users are still accessible. If those older versions are live, they almost always have weaker security controls.
Common patterns we see in zombie API exploitation include deprecated versions that still accept API keys that were rotated for the current version, older endpoints that use basic authentication while the current version requires OAuth 2.0 with PKCE, legacy versions that return full database objects in responses while the current version implements field-level filtering, and deprecated endpoints that lack the input validation improvements added to address vulnerabilities found in previous penetration tests.
Real-world pattern: In a recent engagement, we discovered that an organization's /api/v1/admin/users endpoint was still live and accepted the original static API key from three years prior. The current /api/v3/admin/users required MFA-backed OAuth tokens and IP allowlisting. The v1 endpoint returned full user records including hashed passwords, email addresses, and internal role assignments. The security team had no idea v1 was still accessible.
Shadow APIs vs zombie APIs: understanding the distinction
While both shadow APIs and zombie APIs represent hidden attack surface, they differ in origin, detection difficulty, and remediation approach. Understanding the distinction helps organizations prioritize their discovery and remediation efforts.
| Characteristic | Shadow APIs | Zombie APIs |
|---|---|---|
| Origin | Created but never documented or registered with security | Previously documented and governed, now deprecated but still live |
| Documentation | Never had documentation | Had documentation that was removed or archived |
| Security controls | May have none, or only whatever the developer implemented ad hoc | Has outdated controls from when it was last actively maintained |
| Detection difficulty | High: no historical record to reference | Medium: can be found by testing previous version paths |
| Typical risk | Missing authentication, no rate limiting, excessive data exposure | Weaker auth than current version, unpatched vulnerabilities, stale access controls |
| Remediation | Register, assess, apply controls or decommission | Decommission or backport current security controls |
How attackers discover hidden API endpoints
Understanding attacker methodology is essential for building effective defenses. The techniques used to discover shadow and zombie APIs are well-established and increasingly automated. Approximately 30% of API attacks now come from malicious bots that systematically probe for these hidden endpoints at scale.
JavaScript source analysis
Modern single-page applications embed API endpoint paths directly in their JavaScript bundles. Attackers decompile and analyze these bundles to extract every API route the application references, including internal endpoints, admin paths, and debug routes that the UI never exposes to regular users. Tools like LinkFinder, JSParser, and custom regex scripts automate this extraction. Even if an endpoint is not linked in the UI, if the JavaScript code references it, attackers will find it.
DNS enumeration and subdomain discovery
API infrastructure often lives on dedicated subdomains: api.company.com, api-v2.company.com, internal-api.company.com, staging-api.company.com. DNS enumeration tools like Subfinder, Amass, and SecurityTrails reveal these subdomains, including those hosting shadow APIs on non-obvious subdomains or zombie endpoints on legacy infrastructure. Certificate transparency logs provide another rich source of subdomain data that attackers mine for API endpoints.
Path fuzzing and version enumeration
Once an attacker identifies a base API path, they systematically fuzz for variations. If /api/v3/ exists, they test /api/v1/ through /api/v9/. If /api/users exists, they fuzz for /api/admin/users, /api/internal/users, /api/debug/users, and hundreds of other common path patterns. Wordlists specifically designed for API endpoint discovery are publicly available and continuously updated by the security community.
Traffic analysis and API documentation leaks
Attackers intercept and analyze application traffic using proxy tools to build a map of all API calls the application makes. They also search for accidentally exposed API documentation: Swagger UI instances left accessible at /swagger, /api-docs, or /openapi.json; Postman collections shared publicly or indexed by search engines; and API documentation in public GitHub repositories that references internal endpoints.
Mobile application reverse engineering
Mobile applications are particularly rich sources of API endpoint discovery. Decompiling Android APKs and analyzing iOS binaries reveals hardcoded API URLs, authentication tokens, and endpoint paths that may reference shadow or legacy APIs. Mobile apps are often slower to update than web applications, meaning they may still reference deprecated API versions that the organization believes are no longer in use.
Automation at scale: Attackers are not manually browsing for hidden endpoints. They deploy automated bots that combine these techniques to discover and probe thousands of potential API paths per hour. Your hidden endpoints do not need to be secret enough to evade a determined human researcher. They need to be secure enough to withstand automated discovery and exploitation attempts that run continuously.
Real breach patterns: how hidden APIs lead to compromise
The breach patterns involving shadow and zombie APIs follow predictable chains. Understanding these chains helps organizations prioritize their defenses around the scenarios most likely to result in actual compromise.
The undocumented admin API
A developer creates an administrative endpoint for managing user accounts during initial application setup. The endpoint is built with a simple static API key for authentication because it was only supposed to be used once. It never appears in the API documentation because it was not part of the product's public interface. The endpoint remains live in production, accessible to anyone who discovers the path and the API key embedded in the deployment scripts stored in a semi-public repository.
The attacker discovers the endpoint through JavaScript analysis, finds the API key through repository scanning, and gains full administrative access to the user management system. This pattern accounts for a significant portion of the unauthorized access incidents we investigate.
The deprecated v1 with weaker auth
An organization migrates its API from v1 (API key authentication) to v2 (OAuth 2.0 with scoped permissions). The v1 endpoints are left running for backward compatibility. Two years later, the v2 API has strong security controls including per-operation rate limiting, field-level authorization, and comprehensive audit logging. The v1 API still accepts the original API keys, some of which have been leaked through various channels over the years. The v1 API returns full database objects without field filtering.
An attacker obtains a leaked v1 API key from a public code repository, accesses the v1 endpoints, and extracts data that the v2 API's authorization model would have prevented them from seeing. The organization's security monitoring is focused on v2 traffic, so the v1 data exfiltration goes undetected for months.
The internal service endpoint exposed externally
A microservice exposes an internal API for service-to-service communication. The endpoint was designed to run behind a service mesh with mutual TLS authentication between services. A load balancer misconfiguration or network segmentation gap makes the endpoint accessible from the public internet. Because the endpoint relies on network-level controls rather than application-level authentication, anyone who can reach it has full access.
These internal endpoints often expose sensitive operations: user data synchronization, payment processing callbacks, configuration management, and health check endpoints that reveal infrastructure details. When they become externally accessible without their intended network-level protections, the impact is immediate and severe.
Building an API inventory management program
Solving the shadow API and zombie endpoint problem requires a systematic approach to API inventory management. This is not a one-time audit. It is an ongoing operational capability that must keep pace with the rate at which your organization creates, modifies, and deprecates API endpoints.
Automated API discovery
Manual inventory maintenance cannot keep up with modern deployment velocity. Organizations need automated tools that continuously discover API endpoints across their infrastructure. This includes network traffic analysis that identifies API calls flowing through load balancers and API gateways, infrastructure scanning that discovers endpoints on known and unknown hosts, code repository analysis that extracts API route definitions from source code, and runtime discovery that monitors application behavior to identify active endpoints.
Attack surface management platforms provide this continuous discovery capability, identifying new endpoints as they appear and flagging those that do not match the documented inventory. The goal is to eliminate the gap between what exists and what is known.
API gateway as enforcement point
An API gateway should serve as the single entry point for all API traffic, both external and internal. When properly implemented, an API gateway ensures that no endpoint can receive traffic without being registered. Any API that bypasses the gateway is, by definition, a shadow API that needs to be brought under governance or decommissioned.
The gateway enforcement model works best when combined with infrastructure controls that prevent direct access to backend services. If services can only receive API traffic through the gateway, shadow APIs cannot persist because they cannot receive requests. This requires disciplined network segmentation and service mesh configuration, but it is the most reliable way to prevent shadow API formation.
CI/CD pipeline integration
The best place to catch a shadow API is before it reaches production. Integrating API inventory checks into your CI/CD pipeline means that any code change introducing a new endpoint triggers a validation step: is this endpoint documented? Has it been registered in the API gateway? Has it been reviewed by the security team? If not, the deployment can be flagged or blocked until the governance requirements are met.
This shift-left approach addresses the root cause of shadow API formation rather than trying to detect shadow APIs after they are already in production. It adds minimal friction to the development process when implemented well, typically requiring only that developers include an API specification file with endpoint changes.
Testing methodology: finding what your inventory missed
Even with the best inventory management program, some shadow and zombie APIs will slip through. This is why comprehensive API discovery must be a core component of every API penetration test, not an optional add-on.
The testing methodology for hidden API discovery follows a systematic approach that mirrors attacker techniques.
- Documentation analysis. Collect all available API documentation: Swagger/OpenAPI specs, Postman collections, developer portal content, internal wikis. This establishes the baseline of what the organization believes exists.
- Client-side source analysis. Decompile and analyze all client applications (web, mobile, desktop) to extract every API endpoint they reference. Compare these against the documented inventory to identify undocumented endpoints.
- Infrastructure reconnaissance. Enumerate DNS records, certificate transparency logs, and cloud infrastructure to identify all hosts and subdomains potentially serving API endpoints.
- Version enumeration. For every documented API version, test for the existence of previous and subsequent versions. Test path variations including internal, admin, debug, test, staging, and legacy prefixes.
- Traffic interception. Proxy all application traffic during functional testing to capture every API call made by the application, including those triggered by edge-case user flows that documentation may not cover.
- Inventory comparison. Compare discovered endpoints against the documented inventory. Every endpoint that exists in production but not in documentation is a finding that needs investigation, regardless of whether it has exploitable vulnerabilities.
This discovery phase typically adds one to two days to an API penetration test but dramatically increases its value. Finding a completely unprotected admin API that nobody knew about is infinitely more valuable than confirming that the documented endpoints have proper input validation.
The discovery gap in traditional testing: Most API penetration tests focus exclusively on the endpoints provided by the client in a Swagger file or endpoint list. This approach tests only what the organization already knows about and misses precisely the endpoints that represent the highest risk. A comprehensive API security assessment must include a discovery phase that identifies what exists beyond the documented inventory.
The role of attack surface management in continuous API discovery
Point-in-time assessments, no matter how thorough, cannot keep pace with the rate at which shadow APIs form and zombie endpoints accumulate. An organization that deploys hundreds of times per month can create dozens of undocumented endpoints between annual penetration tests. This is where attack surface management (ASM) provides critical continuous coverage.
ASM platforms designed for API discovery operate continuously, monitoring for new endpoints as they appear rather than waiting for the next scheduled assessment. They combine multiple discovery techniques including DNS monitoring, certificate transparency analysis, port scanning, and web crawling to maintain a real-time view of an organization's API surface area.
When ASM discovers a new endpoint that does not appear in the API inventory, it triggers an alert for investigation. Is this a legitimate new endpoint that needs to be registered and governed? Or is it a shadow API that bypassed the governance process? Is it a zombie endpoint from a migration that was supposed to be completed? Each discovery is an opportunity to close a gap before an attacker finds it.
The combination of continuous ASM for ongoing discovery and periodic penetration testing for deep technical assessment provides the most robust defense against shadow and zombie API risks. ASM catches endpoints as they appear, while penetration testing validates that the security controls on both documented and discovered endpoints are actually effective.
Practical steps to reduce your hidden API attack surface
Eliminating shadow APIs and zombie endpoints entirely is unrealistic for any organization operating at scale. The goal is to minimize their formation, maximize their detection, and reduce the time between an endpoint appearing and security governance being applied to it. Here are the concrete steps that make the biggest difference.
- Mandate API gateway registration for all endpoints. No API reaches production without being registered in the gateway. Enforce this through network controls that block direct access to backend services.
- Integrate API inventory validation into CI/CD. Any pull request that adds or modifies API routes should be automatically checked against the API registry. Flag unregistered endpoints before they deploy.
- Implement formal API deprecation procedures. Deprecation must include a hard decommission date, automated monitoring for traffic to deprecated endpoints, and actual removal from production infrastructure. Marking an endpoint as deprecated in documentation is not decommission.
- Deploy continuous attack surface management. Monitor your external and internal attack surface continuously for new API endpoints. Investigate every discovery that does not match your inventory.
- Require API discovery in every penetration test. Insist that your penetration testing provider includes endpoint discovery as a standard phase, not just testing endpoints you provide them.
- Conduct quarterly API inventory audits. Compare your documented API inventory against discovered endpoints from ASM tools, penetration test results, and infrastructure scans. Treat every discrepancy as a finding that requires remediation.
- Apply consistent security controls to all API versions. If you must maintain legacy API versions, backport all security improvements from current versions. A deprecated endpoint with production traffic must receive the same security attention as your primary API.
- Monitor for API credential leaks. Scan public code repositories, paste sites, and other channels for leaked API keys and tokens. Rotate any credentials found exposed and investigate which endpoints they could access.
Building a culture of API accountability
Technology solutions alone cannot solve the shadow API problem. The root cause is organizational: developers create endpoints without informing security teams because the process for doing so is too slow, too bureaucratic, or simply nonexistent. Fixing this requires cultural change alongside technical controls.
Engineering teams need clear, lightweight processes for registering new API endpoints. If the registration process takes longer than deploying the endpoint, developers will skip it. Self-service API registration through developer portals, automated registration through code annotations, and API-as-code approaches that generate gateway configurations from source code all reduce the friction that causes shadow API formation.
Security teams need to shift from gatekeeping to enabling. Instead of reviewing every API endpoint before deployment (which creates bottlenecks that developers route around), provide guardrails that automatically apply security baselines to new endpoints and flag only those that deviate from standards for manual review. This approach scales with development velocity and maintains security coverage without creating the friction that drives shadow API creation.
Ultimately, every API endpoint in production should have a clear owner who is accountable for its security posture, its lifecycle management, and its eventual decommission. API ownership maps, tied to service ownership more broadly, ensure that no endpoint exists without someone responsible for it. When ownership is clear, shadow APIs are identified faster, zombie endpoints are decommissioned sooner, and the hidden attack surface that breaches enterprises stays as small as possible.
Discover Your Hidden API Attack Surface
Our API security assessments include comprehensive endpoint discovery that finds the shadow APIs and zombie endpoints your inventory missed. Combine with Lorikeet ASM for continuous API monitoring.
