Shadow APIs & Zombie APIs: How to Find and Secure Your Hidden Attack Surface
The Hidden API 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
| Type | Definition | Example |
|---|---|---|
| Shadow API | API endpoint that exists but is not documented or known to security teams | Developer built /debug/dump-env during development; it shipped to production |
| Zombie API | Deprecated API that was replaced but never decommissioned | /api/v1/users (no auth) still works alongside /api/v3/users (with auth) |
| Orphan API | API whose owning team no longer exists or maintains it | Post-acquisition, acquired company's APIs run unmanaged |
| Rogue API | API created outside organizational processes, often by shadow IT | Marketing team built a quick API for a campaign — never reviewed |
Why Shadow APIs Are Dangerous
Real-World Shadow API Breaches
| Organization | Year | What Happened | Impact |
|---|---|---|---|
| Optus (Australia) | 2022 | Unauthenticated test API in production exposed customer data | 9.8M customer records (passports, license numbers) |
| T-Mobile | 2023 | Undocumented API endpoint leaked account data | 37M customers affected |
| Uber | 2022 | Attacker accessed internal API documentation via compromised credentials | Full internal system access |
Why They Persist
- Microservices explosion — One application becomes 200 microservices, each with multiple endpoints
- Developer velocity — Teams ship APIs faster than security can inventory them
- No decommissioning process — Replacing an API version doesn't mean removing the old one
- Infrastructure-as-Code drift — IaC templates define APIs, but manual changes create untracked endpoints
- 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:
| Field | Description | Example |
|---|---|---|
| Endpoint | Full URL path | /api/v2/users/:id |
| Methods | HTTP methods | GET, PUT, DELETE |
| Authentication | Auth mechanism | OAuth 2.0 Bearer |
| Owner | Responsible team | User Service Team |
| Version | API version | v2 (current), v1 (deprecated) |
| Documentation | OpenAPI spec exists? | Yes — specs/users-v2.yaml |
| Data sensitivity | Data classification | Contains PII (email, phone) |
| Traffic volume | Requests per day | ~50,000 |
| Last modified | Code last changed | 2026-01-15 |
| Status | Lifecycle state | Active / Deprecated / Zombie |
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
| Metric | Alert Threshold | Why It Matters |
|---|---|---|
| New undocumented endpoints | Any new detection | Shadow API creation |
| Traffic to deprecated APIs | > 0 requests after sunset date | Zombie APIs still in use |
| Unauthenticated API calls | Any to auth-required endpoint | Missing auth enforcement |
| PII in API responses | Any detection in non-PII endpoints | Data leakage |
| API error spike | > 5% error rate | Possible attack or misconfiguration |
| Schema deviation | Response differs from OpenAPI spec | API drift |
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
Advertisement
Free Security Tools
Try our tools now
Expert Services
Get professional help
OWASP Top 10
Learn the top risks
Related Articles
Secure API Design Patterns: A Developer's Guide
Learn the essential security patterns every API developer should implement, from authentication to rate limiting.
JWT Security: Vulnerabilities, Best Practices & Implementation Guide
Comprehensive JWT security guide covering token anatomy, common vulnerabilities, RS256 vs HS256, refresh tokens, and secure implementation patterns.
Securing Generative AI APIs: MCP Security & Shadow AI Risks in 2026
Model Context Protocol (MCP) is the emerging standard for connecting AI to tools and data. But MCP servers, shadow AI usage, and AI supply chain attacks introduce critical risks. Learn how to secure generative AI APIs.