Every engineering team knows how many services are in production. Almost none know how many API endpoints those services actually expose. A single deploy can spin up a debug route, a v1 endpoint nobody deprecated, or a partner integration that outlived the partnership — and none of it shows up in the API gateway inventory, the OpenAPI spec, or the security backlog. Gartner has predicted that APIs will be the most frequent attack vector for enterprise web application breaches, and by 2026 most organizations still can't produce an accurate, current count of their own external-facing endpoints. This is the shadow and zombie API problem: undocumented, forgotten, or unmonitored APIs sitting quietly in production, reachable by anyone who finds them. Competing platforms like Checkmarx have started bolting API testing onto their AppSec suites, but scanning code isn't the same as knowing what's actually running. This post breaks down the scale of the problem, real incidents it has caused, and the API security best practices that actually close the gap.
What Exactly Are Shadow and Zombie APIs?
Shadow APIs are endpoints that exist in production but were never registered with security, IT, or API management tooling — they were shipped by a developer, a contractor, or a low-code integration and never entered the inventory. Zombie APIs are the inverse: they were known once, documented once, maybe even secured once, but should have been retired and weren't. A classic example is a mobile app's v1 API that the app store version no longer calls, but which the backend team never decommissioned because "something might still be using it." Both categories share the same root cause: API inventories are built from what teams remember to document, not from what's actually deployed. Salt Security's State of API Security research has repeatedly found that the majority of organizations experienced an API-related security incident in the prior 12 months, and a large share of respondents admitted they did not have full confidence in their API inventory. You cannot apply a WAF rule, a rate limit, or an authentication policy to an endpoint you don't know exists.
How Many APIs Are Actually Unknown to Security Teams?
More than most CISOs would guess, and the gap is measured in the thousands for any organization past Series C scale. Enterprises with mature API programs still report double-digit percentages of their total API surface as "unknown" or "unmanaged" in third-party audits. Part of this is architectural: the shift to microservices means a single monolith that once exposed 30 endpoints now becomes 40 services each exposing 15–20 internal and external routes, multiplying the surface area by an order of magnitude without a corresponding increase in inventory discipline. Part of it is process: API gateways only see traffic that's routed through them, so any service calling another directly, or any endpoint exposed through a load balancer that bypasses the gateway, is invisible to gateway-based inventory tools. Mergers and acquisitions compound this — acquired companies bring their own undocumented API estates, and integration timelines rarely include a full API discovery pass before systems are connected.
What Real Breaches Have Been Caused by Shadow or Zombie APIs?
Several of the largest breaches of the past few years trace directly back to an API that security teams didn't know was exposed or didn't realize was still active. The Optus breach in Australia in September 2022 exposed the personal data of roughly 9.8 million customers through an API that required no authentication and was reachable from the open internet — a textbook shadow API left accessible after being intended for internal testing. T-Mobile disclosed in January 2023 that an attacker had abused a single API for roughly six weeks starting in November 2022, pulling data on 37 million customer accounts before it was detected — the company's eighth API-related incident disclosure in five years. Peloton's 2021 exposure involved an API endpoint that returned user account data to any requester without verifying that the requester should have access to it, a broken object level authorization flaw that OWASP now ranks as the number one API security risk. In each case, the vulnerability wasn't a novel zero-day; it was an endpoint that fell outside the scope of what the security team was actively monitoring.
Why Do Traditional AppSec Tools Struggle to Catch This?
Because tools built around source code scanning and dependency analysis were designed for a world where the attack surface matched the codebase, and that assumption no longer holds. Checkmarx and similar static and dynamic analysis platforms are strong at finding vulnerabilities inside code you point them at — SQL injection patterns, insecure deserialization, known-vulnerable libraries — but that analysis only covers the repositories and branches that are configured for scanning. A shadow API deployed from a script outside the CI/CD pipeline, an endpoint stood up directly on cloud infrastructure, or a zombie route left live in a branch that was never fully decommissioned from production simply never enters the scan scope. SAST and SCA answer "is this code safe," not "what is actually reachable from the internet right now." That's a runtime and inventory question, and it requires continuously discovering the live API surface — traffic analysis, DNS and certificate monitoring, cloud asset discovery — rather than relying solely on what's declared in a spec file or committed to a monitored repo. Enterprises running Checkmarx or comparable AppSec suites alongside a real-time API discovery layer catch a meaningfully different, and often larger, set of exposures than code scanning alone surfaces.
What Do API Security Best Practices Actually Look Like Now?
They start with continuous discovery, not periodic audits, because a quarterly API inventory review is already out of date by the time it's reviewed. The concrete practices that separate organizations with low shadow-API exposure from those without them: first, maintain a live, automatically updated inventory built from actual network and cloud traffic rather than developer-submitted documentation, so new endpoints are flagged within hours of deployment instead of discovered during an incident. Second, enforce authentication and authorization checks at the object level on every endpoint, since OWASP's API Security Top 10 has ranked broken object level authorization as the top API risk in both its 2019 and 2023 editions. Third, set explicit deprecation dates for every API version at launch, with automated alerts when a "deprecated" endpoint still receives traffic 30, 60, and 90 days past its sunset date — this is what actually kills zombie APIs instead of letting them linger indefinitely. Fourth, apply consistent rate limiting and anomaly detection across every endpoint, not just the ones documented in the API gateway, since attackers specifically probe for undocumented routes that are less likely to have those controls. Fifth, correlate API findings with your broader software supply chain posture — an unknown API is frequently the symptom of an unmanaged deployment pipeline, unmanaged third-party integration, or an unreviewed IaC change, so treating it as an isolated AppSec ticket instead of a supply chain signal means the same gap reopens next quarter.
How Safeguard Helps
Safeguard treats API exposure as a software supply chain problem, not a standalone scanning task, because that's what shadow and zombie APIs actually are — the downstream result of deployment pipelines, cloud infrastructure changes, and third-party integrations that never got full visibility. Safeguard continuously maps your real, deployed API surface by correlating signals across your CI/CD pipelines, cloud infrastructure, and code repositories, so new endpoints are surfaced as they're deployed rather than discovered during a breach post-mortem. Where a code-scanning-first platform like Checkmarx tells you whether the code behind an endpoint is written securely, Safeguard adds the missing layer: confirmation that the endpoint you think is retired is actually retired, that the endpoint your inventory doesn't list is actually flagged the moment it goes live, and that ownership and authorization for every exposed route is traceable back to the pipeline and team that shipped it. That combination — supply chain-level provenance plus continuous API discovery — is what turns "we think we know our API surface" into an answer you can actually stand behind during an audit or an incident response call. If your last full API inventory was more than a quarter old, that's the gap Safeguard is built to close.