OWASP classification (API9:2023)

OWASP classification: API Specific. Exploitability: Easy (2). Prevalence: Widespread (3). Detectability: Average (2). Technical Impact: Moderate (2). Business Impact: Specific (organization-/application-specific). (All values confirmed 1:1 from the official OWASP page.)

How the attack works

Modern architectures such as microservices, cloud, and Kubernetes make it easy to roll out many API hosts and multiple API versions in parallel. This creates two blind spots.

  • Documentation blind spot: it's unclear which environment an API host runs in (production, staging, test, development), who should have network access (public, internal, partner), and which version is active. This is usually because documentation is missing or outdated, there's no retirement plan, and the host inventory is incomplete.
  • Data flow blind spot: sensitive data flows to third parties without business justification, approval, or visibility.

Attackers find forgotten or old endpoints using simple means such as Google dorking, DNS enumeration, and specialized search engines for internet-connected devices or servers. These endpoints are often unpatched and have weaker security requirements than the current production version.

Multiple API versions or deployments frequently hang off the same database with real data. As a result, a flaw in an old version exposes real production data.

1. Starting pointOld or undocumented API keeps running (v1, staging)
→
2. AttackAttacker finds the forgotten endpoint
→
3. ResultAccess via the unpatched shadow API

Forgotten and undocumented APIs are an entry point.

Example

OWASP scenario #1 (beta host without rate limiting):

  1. A social network protects password reset against brute force via rate limiting. This limit is NOT implemented in the API code itself, but in a separate, upstream component between the client and the official API (api.socialnetwork.owasp.org).
  2. A researcher discovers a beta API host: beta.api.socialnetwork.owasp.org.
  3. This beta host runs the same API code, including the password reset mechanism, but WITHOUT the upstream rate-limiting component.
  4. Since no rate limiting applies, the researcher can brute-force the 6-digit reset token and thereby reset any user's password and take over the account.

Note: the OWASP text describes only this sequence; specific endpoint paths or JSON payloads aren't given there.

Impact

Attackers gain access to sensitive data or even take over the server. Since different API versions or deployments often hang off the same database with real data, a flaw in a forgotten version can lead directly to real data.

Via deprecated endpoints, attackers can reach administrative functions or exploit known vulnerabilities.

In the data flow blind spot (OWASP scenario #2), a consulting firm gained access to the private data of 50,000,000 users via an overly open third-party integration, with the consent of 270,000 users, and later sold that data for malicious purposes.

Business consequences: data breaches, account takeovers, as well as compliance and reputational damage.

How to protect yourself

  • Inventory all API hosts and document key aspects for each host: environment (production, staging, test, development), who should have network access (public, internal, partner), and the API version.
  • Inventory integrated services/third parties and document key aspects: their role in the system, the data exchanged (data flow), and its sensitivity.
  • Document all aspects of the API: authentication, errors, redirects, rate limiting, CORS policy, and endpoints including parameters, requests, and responses.
  • Generate documentation automatically via open standards and integrate the documentation build into the CI/CD pipeline.
  • Make API documentation accessible only to authorized API users.
  • Deploy external protective measures (API-specific security solutions) for ALL exposed API versions, not just the current production version.
  • Don't use production data in non-production deployments; if that's unavoidable, these endpoints must receive the same security treatment as production.
  • If newer API versions contain security improvements, perform a risk analysis for the old versions (e.g. is a backport possible without breaking compatibility? Or retire the old version quickly and force all clients to the latest version).

Phantom and AI-generated APIs

Alongside shadow and zombie APIs, a new source is intensifying the inventory problem: phantom APIs, meaning routes, handlers, and parameters that run in production but never showed up in a specification, a ticket, or a review. Increasingly, they arise as a byproduct of AI code generators and scaffolding tools that generate plausible-looking endpoints along the way, such as an admin or debug path, because this pattern looked normal in the training data.

This intensifies the silent drift between code and documentation, because code is created faster than governance can track it. According to Salt Security, 99 percent of organizations reported API security problems in the past year, and for a significant share, the API inventory grew substantially. The answer is the same as for shadow and zombie APIs, only more urgent: don't blindly trust the documentation, but continuously reconcile real traffic against the approved specification and treat every unspecified path as a finding.

The terms at a glance

These terms overlap and are used inconsistently across vendors. They can be cleanly separated along a few questions: Does the endpoint actually run in production? Is it captured in a specification? Does governance know about it? Does it still have an owner? And how did it come to exist?

TermWhat it isHow it differs
ShadowRuns in production but isn't in any inventory and is unknown to governance.Built outside the process. The builder knows about it, only security doesn't.
UndocumentedEndpoint without a current specification.Not a category of its own, but the defining trait of a shadow API.
PhantomNever appeared in a spec, ticket, or review, increasingly built alongside by AI code generators.Was never consciously planned, existed in no one's awareness. Distinct from shadow, which someone built deliberately.
OrphanKeeps running, but the responsible team is gone.Not a visibility problem but an ownership problem. May well still be documented.
ZombieOld, superseded version that was never shut down and keeps receiving traffic.A deprecated endpoint that was never decommissioned. Decommissioning failure rather than a lost owner.
DeprecatedOfficially marked-outdated, documented version, ideally with a sunset plan.The only intentional lifecycle status. Becomes a zombie API if the shutdown never happens.
RogueOperated unauthorized or deliberately outside governance.The only term with a connotation of malicious intent. Some vendors use it as an umbrella term for shadow and zombie.

The industry defines these terms inconsistently. "Phantom," for example, stands, depending on the source, for real, unknown production routes or for hallucinated interfaces in AI code that don't exist at all. What matters isn't the label, but reconciling real traffic against the approved specification.

Sources

Keep reading
OverviewOWASP API Security Top 10 API10Unsafe Consumption of APIs