In August 2023, T-Mobile disclosed its ninth breach in five years — this time traced to a single API that had gone unnoticed by its own security team. An attacker exploited it for over a month, from late November 2022 to early January 2023, quietly pulling data on 37 million customers before anyone noticed. The API wasn't hidden by some sophisticated attacker trick. It was simply never fully accounted for in T-Mobile's own inventory. This is the story behind two of the most under-discussed entries in the OWASP API Security Top 10: shadow APIs and zombie APIs, both symptoms of what OWASP formally calls "Improper Inventory Management." Security teams can't protect what they don't know exists, and in modern software supply chains — where APIs are created, versioned, forked, and abandoned faster than anyone can track — that blind spot is becoming the default state, not the exception.
What Is Improper Inventory Management, and Why Does OWASP Rank It a Top API Risk?
Improper Inventory Management is the failure to maintain an accurate, current record of every API a company runs, in every environment, at every version. OWASP has flagged it as a distinct API security risk since its original 2019 API Security Top 10 and reaffirmed it in the 2023 update, precisely because inventory gaps aren't a hypothetical concern — they're a leading root cause of real incidents. Salt Security's State of API Security Report (Q1 2023) found that 100% of surveyed organizations had experienced API security problems in production, and a majority couldn't say with confidence how many APIs they actually had. Cequence Security's 2023 API Threat Report separately measured over 5 billion malicious requests targeting APIs across its customer base in a single half-year period, a large share aimed at endpoints that were never documented in the first place. The pattern is consistent: organizations don't get breached because they failed to patch a known API. They get breached because an API existed that nobody remembered to protect.
What Exactly Is a Shadow API?
A shadow API is an API that is live and reachable in production but was never registered, documented, or brought under the organization's security review process. These typically emerge from ordinary engineering velocity: a developer spins up an internal endpoint for a quick integration test, a mobile team ships a new backend-for-frontend service ahead of a security review, or a third-party SDK silently opens its own API surface as a side effect of installation. None of it is malicious — it's just unmanaged. Optus, Australia's second-largest telecom, learned this the hard way in September 2022, when attackers pulled personal data on 9.8 million customers through an API endpoint that required no authentication at all. The endpoint had been set up for internal testing purposes and was left externally accessible, effectively becoming a shadow API that the company's own perimeter scans never flagged because it wasn't in their asset list to begin with.
What Is a Zombie API, and How Is It Different from a Shadow API?
A zombie API is an old, deprecated, or "retired" endpoint that is still technically running and reachable, even though it's no longer part of any current product or officially maintained roadmap. Where a shadow API was never known, a zombie API was known once and then forgotten — often after a migration, a v1-to-v2 upgrade, or an acquisition where legacy systems were never fully decommissioned. The clearest public example is Coinbase's October 2021 bug bounty disclosure: a security researcher found that a deprecated internal migration API, left active after a smart-contract token swap upgrade, could be manipulated to execute unlimited buy and sell trades of unsupported crypto assets without ever holding the underlying funds. Coinbase paid a $250,000 bounty for the find and confirmed no customers were actually harmed, but the mechanics were sobering: an API that engineering believed was retired was still fully armed with production-level trading permissions, invisible to the teams who assumed it had been shut off months earlier.
How Do Shadow and Zombie APIs Actually Lead to Breaches?
They lead to breaches because unmanaged endpoints skip every control that protects known ones — authentication reviews, rate limiting, logging, and vulnerability scanning all assume the security team knows an API exists. In the T-Mobile case, the exploited API's GUID-based structure meant an attacker who guessed or enumerated one valid identifier could pull customer records in bulk, and because the endpoint sat outside routine monitoring, the activity ran undetected for roughly six weeks. In the Optus case, the missing authentication check would have been caught instantly by even a basic API security review — but that review never happened, because the endpoint wasn't on anyone's list to review. This is the throughline across nearly every shadow and zombie API incident: the vulnerability itself is often mundane (no auth, weak object-level access control, an old permission scope). What makes it dangerous is that it sits completely outside the organization's normal detection and remediation lifecycle.
Why Do Traditional Asset Inventories Keep Missing These APIs?
Traditional inventories miss them because most were built around static architecture — annual audits, manually maintained spreadsheets, and API gateways that only see traffic routed intentionally through them. Modern engineering doesn't work that way anymore. A 2023 Gartner analysis on API security noted that enterprises typically run several times more APIs than their security teams have formally catalogued, driven by microservices sprawl, CI/CD pipelines that deploy dozens of times a day, multi-cloud environments, and third-party integrations that each bring their own undocumented endpoints. Gateway-based inventories are blind to any API that bypasses the gateway, which shadow APIs frequently do by design (they were never routed through the "official" path) and which zombie APIs often do by accident (they predate the gateway or were migrated off it). Point-in-time audits, meanwhile, are stale the moment a new service ships. The result is an inventory that reflects what the organization built on purpose, not what is actually running.
How Safeguard Helps
Safeguard closes this gap by treating API discovery as a continuous, evidence-based process rather than a periodic paperwork exercise. Instead of relying on developers to self-report every endpoint, Safeguard analyzes real traffic, deployment artifacts, and code repositories together to build a living inventory of every API actually in production — including the ones nobody remembers documenting and the ones everyone assumed were decommissioned. When Safeguard finds an endpoint that isn't in the sanctioned API catalog, it flags it as shadow inventory and routes it into the same risk review process as every known API, rather than letting it sit invisible until an attacker finds it first. When it finds traffic hitting a deprecated or "retired" version, it surfaces that as a zombie API and ties it back to the team or service that was supposed to have decommissioned it, closing the loop that let Coinbase's migration endpoint and T-Mobile's forgotten GUID-based API stay live long after anyone was watching them.
Because Safeguard maps this inventory against the software supply chain itself — dependencies, build pipelines, and deployment history — security teams get context most gateway tools can't provide: not just that an unknown API exists, but which commit introduced it, which service owns it, and whether it's exposed to sensitive data flows. That context is what turns "we found an undocumented API" into an actionable fix rather than another alert competing for attention. For organizations trying to move past the OWASP API9 problem for good, the goal isn't a cleaner spreadsheet — it's an inventory that updates itself every time the software supply chain changes, so that the next shadow or zombie API is caught in a review cycle instead of a breach disclosure.