In September 2022, Optus — Australia's second-largest telecom — disclosed that roughly 10 million customer records had been exposed through a single internet-facing API endpoint that required no authentication and served sequential, predictable customer IDs. The endpoint had been reachable for months after an internal coding change silently removed an authorization check nobody was watching for, because nobody on the security team had it catalogued as a live, sensitive API in the first place. Four months later, T-Mobile disclosed a near-identical pattern: an attacker abused one API starting around November 25, 2022, pulling account data — names, billing addresses, phone numbers, dates of birth — for approximately 37 million customers before the activity was detected on January 5, 2023, and cut off the next day. Neither breach required a zero-day. Both required only that an API existed, worked, and was invisible to the people responsible for defending it. This is the "shadow API" problem: endpoints that are live in production but absent from your inventory, your gateway policy, and your security review process. This post covers how shadow and undocumented APIs accumulate, the concrete techniques teams use to find them, and how to score what you find so triage doesn't just become another spreadsheet nobody reads.
What makes an API "shadow" or "undocumented" instead of just unmanaged?
A shadow API is one that exists and receives traffic in production without appearing in any system your security or platform team uses to track APIs — no entry in the API gateway, no OpenAPI spec, no ticket. It typically gets created one of three ways: a developer stands up a quick internal endpoint that later gets exposed by a load balancer or ingress change; an old API version stays live ("zombie API") after a new version ships because nobody decommissioned it; or a third-party integration calls out to, or is called by, a vendor API that was never registered with procurement or security. OWASP's API Security Top 10 (2023 edition) codifies this directly as API9:2023, "Improper Inventory Management," describing outdated API versions and undocumented endpoints as a distinct, named risk category — not a hypothetical, but one of ten categories the working group considered common enough to rank explicitly.
How did shadow APIs actually cause real breaches?
The Optus and T-Mobile incidents both involved a working, functional API that fell outside routine security review — not a novel exploitation technique. In Optus's case, the endpoint (reported publicly as an internet-facing /users/{userId} -style API) accepted no authentication token and returned full customer records for any sequential ID an attacker cared to request, a pattern OWASP categorizes as Broken Object Level Authorization (API1:2023) compounded by the inventory gap that let it go unnoticed. T-Mobile's incident, disclosed via an SEC filing on January 19, 2023, involved a single API being hit continuously for over a month before anyone on the security side saw the traffic pattern as abnormal. In both cases, the underlying vulnerability class (missing authorization, excessive data exposure) was well understood; what let it run undetected for months, not minutes, was that the API wasn't on anyone's list of things to watch.
What discovery techniques actually surface shadow APIs?
Effective discovery layers several independent signal sources, because no single one sees the whole picture. Passive traffic analysis at the API gateway, load balancer, or WAF captures every request path actually being hit, then diffs that list against your documented OpenAPI/Swagger specs — anything receiving traffic but absent from the spec is a candidate zombie or shadow endpoint. Source-code and CI/CD scanning walks route definitions (Express routers, Flask blueprints, Spring @RequestMapping annotations) at build time, catching endpoints before they ever reach production traffic. DNS enumeration and certificate-transparency log review surface forgotten subdomains (api-v1., staging-api., internal-api.) that were never decommissioned. Runtime agents on hosts or in Kubernetes can observe outbound calls your own services make to third-party APIs that were never registered anywhere — the vendor-API blind spot that shows up in both breaches above. None of these alone is sufficient; a spec-vs-traffic diff misses vendor calls, and a code scan misses infrastructure drift that happens after deployment.
How should a team score exposure once a shadow API is found?
Finding an API is the easy part; the next question is which of the dozens you'll find deserve immediate attention. Useful scoring dimensions include: whether the endpoint is internet-reachable versus internal-only; whether it requires authentication at all, and if so, whether that authentication enforces per-object authorization (the BOLA pattern behind Optus) rather than just verifying a valid token exists; what data class it returns — PII, payment data, or internal metadata; and whether it has any rate limiting, since API4:2023 ("Unrestricted Resource Consumption") covers the abuse pattern of an API with no cost controls being hammered for scraping or account enumeration. A shadow API that's internal-only, requires auth, and returns non-sensitive data is a hygiene ticket. One that's internet-facing, unauthenticated, and returns customer PII is the Optus pattern precisely, and should be treated with page-someone urgency rather than backlog priority.
Why does inventory reconciliation need to be continuous rather than one-time?
A one-time API audit produces a snapshot that starts decaying the moment the next deploy ships. Modern services routinely add or version endpoints multiple times a week, and the T-Mobile incident's own timeline illustrates the gap: the abused API had reportedly been in place well before the November 2022 abuse began, meaning a single audit months earlier would have already missed the window in which the exposure mattered. Continuous reconciliation — re-running the traffic-vs-spec diff, the code-vs-gateway diff, and the vendor-call inventory on every deploy or on a tight recurring cadence — is what turns "we did an API inventory last year" into "we know what's live right now." This mirrors the same lesson software supply chain security learned about SBOMs: an inventory is only as useful as its freshness.
How Safeguard Helps
Safeguard's asset discovery treats "a vendor API being called from production but not listed in TPRM" as a first-class shadow-asset class, not an afterthought — it's one of the specific patterns the platform's continuous discovery is built to catch, alongside unconnected repositories and images with no SBOM. Discovery runs across agentless integrations, lightweight runtime agents on Kubernetes and VM hosts, and CI/CD log cross-referencing, so an API that shows up in production traffic without a matching entry anywhere else in your estate surfaces as UNGOVERNED status in the Asset Discovery dashboard rather than staying invisible until an incident. Once an API is identified and confirmed as a legitimate, in-scope target, Safeguard's application security testing can assess it directly against verified endpoints within an allowlisted scope, so the same platform that finds the shadow endpoint can also help establish whether it's exposed the way Optus's and T-Mobile's were before an attacker gets there first.