Shadow APIs and Zombie APIs: API Discovery, Inventory, and Hidden Attack Surface Security

Shadow API Discovery and Zombie API Security

If you are trying to reduce hidden API risk, the starting point is API discovery and API inventory hygiene. Teams searching for answers on shadow APIs and zombie APIs usually do not have a detection problem alone. They have an ownership, documentation, and decommissioning problem.

Your API attack surface is larger than you think. Much larger.

Critical Finding: Salt Security's 2025 State of API Security Report found that 76% of organizations have shadow APIs — APIs that exist in production but are not documented, monitored, or managed by security teams. Additionally, 43% of organizations have zombie APIs — deprecated endpoints that were never decommissioned.

Definitions

Why Shadow APIs Are Dangerous

Real-World Shadow API Breaches

Why They Persist

1. Microservices explosion — One application becomes 200 microservices, each with multiple endpoints
2. Developer velocity — Teams ship APIs faster than security can inventory them
3. No decommissioning process — Replacing an API version doesn't mean removing the old one
4. Infrastructure-as-Code drift — IaC templates define APIs, but manual changes create untracked endpoints
5. Acquisitions — Acquiring a company means inheriting their entire undocumented API landscape

API Discovery Methods

Method 1: Traffic Analysis (Most Effective)

Deploy an API security platform or WAF in learning mode to analyze actual traffic patterns:

What traffic analysis reveals:
─────────────────────────────
✓ Every endpoint that receives traffic (including undocumented ones)
✓ HTTP methods used per endpoint
✓ Authentication patterns (or lack thereof)
✓ Data types in requests and responses (detect PII)
✓ Traffic volume and patterns per endpoint
✓ Client diversity (how many apps consume each API)

Method 2: Code Scanning

Analyze source code repositories for API route definitions:

# Find Express.js route definitions
grep -r "app\.\(get\|post\|put\|delete\|patch\)" --include="*.js" --include="*.ts" .

# Find Next.js API routes
find ./app/api -name "route.ts" -o -name "route.js" | sort

# Find FastAPI endpoints (Python)
grep -r "@app\.\(get\|post\|put\|delete\)" --include="*.py" .

# Find Spring endpoints (Java)
grep -r "@\(GetMapping\|PostMapping\|RequestMapping\)" --include="*.java" .

Method 3: Infrastructure Scanning

# Scan API gateways for registered routes
# AWS API Gateway
aws apigateway get-rest-apis --query 'items[*].{name:name,id:id}'

# Kubernetes ingress rules
kubectl get ingress --all-namespaces -o json | jq '.items[].spec.rules[].http.paths'

# Nginx configuration analysis
grep -r "location" /etc/nginx/ --include="*.conf" | grep "proxy_pass"

Method 4: DNS and Certificate Enumeration

# Find API subdomains
# Certificate Transparency logs
curl -s "https://crt.sh/?q=%25.example.com&output=json" | jq '.[].name_value' | sort -u | grep api

# DNS brute force (with common API prefixes)
# api., api-v1., api-v2., gateway., internal-api., staging-api., dev-api.

Building an API Inventory

Every discovered API should be documented in a central inventory:

Eliminating Zombie APIs

The Zombie API Decommissioning Process

Step 1: Identify
├── Compare API inventory with documentation
├── Flag endpoints on deprecated versions (v1 when v3 exists)
└── Check traffic — does anyone still call it?

Step 2: Assess
├── Who/what is still calling the zombie API?
├── What data does it expose?
├── Is it authenticated?
└── Risk rating (critical/high/medium/low)

Step 3: Notify
├── Contact consuming applications
├── Provide migration path to current version
├── Set decommission date (30-90 days)
└── Add deprecation headers to responses

Step 4: Decommission
├── Return 410 Gone with migration instructions
├── Monitor for continued traffic
├── After 30 days of zero traffic: remove
└── Update API inventory

Deprecation Response Headers

// Add deprecation headers to zombie APIs
app.use("/api/v1/*", (req, res, next) => {
  res.setHeader("Deprecation", "true");
  res.setHeader("Sunset", "Sat, 01 Jun 2026 00:00:00 GMT");
  res.setHeader("Link", '</api/v3>; rel="successor-version"');

  // Log usage for migration tracking
  logger.warn({
    message: "Deprecated API v1 called",
    path: req.path,
    clientIP: req.ip,
    userAgent: req.headers["user-agent"],
  });

  next();
});

Continuous API Security Monitoring

Shadow API FAQ

What is a shadow API?

A shadow API is an endpoint that exists in production but is undocumented, unmanaged, or unknown to the security team. It may still receive traffic even though it is outside normal governance and monitoring.

What is a zombie API?

A zombie API is an older or deprecated endpoint that was replaced but never fully removed. These endpoints often remain exploitable because they miss the newer authentication, authorization, or validation logic added to current API versions.

How do you find shadow APIs in practice?

The most effective approach combines traffic analysis, source code discovery, API gateway inspection, OpenAPI spec comparison, and certificate or DNS enumeration. A single source of truth is usually not enough.

Further Reading

• API Security Trends 2026 — Comprehensive API threat landscape
• OWASP API Security Top 10 — API-specific vulnerability framework
• Salt Security (2025), "State of API Security Report" — Shadow API statistics
• Secure API Design Patterns — Building APIs securely from the start