Shadow APIs are real API endpoints that exist in production but are unknown to your security team. They accumulate over years: a developer added an internal endpoint that was never documented, an old version of the API was partially decommissioned but a few routes remain live, a microservice exposes management endpoints that were never meant to be accessible externally.
How Shadow APIs Form
- ▸Legacy endpoints from API v1 that were never removed when v2 shipped
- ▸Debug and management endpoints (/_debug, /admin/status) exposed by frameworks
- ▸Undocumented internal endpoints used by mobile apps or third-party integrations
- ▸Acquired company APIs merged into the main infrastructure without security review
- ▸Auto-generated endpoints from ORM frameworks (e.g., Laravel, Django REST, Rails)
Discovery Methods
Traffic analysis
The most reliable discovery method: collect all API paths observed in actual traffic logs over a 30-90 day period and compare against your documented API spec. Any path in traffic but not in the spec is a shadow API candidate.
JavaScript bundle analysis
Extract API endpoints from your frontend JavaScript bundles. Builders, mobile apps, and internal tools often contain API client code that references endpoints not in your public spec.
Crawling and fuzzing
Active discovery by crawling common path patterns (/v1/, /v2/, /api/, /internal/, /admin/, /health, /metrics) and common framework management endpoints. This catches endpoints that have never appeared in traffic logs because they are not yet known to be accessible.
G8KEPR's API Discovery module continuously compares observed traffic against your registered API spec and flags paths that receive traffic but have no matching route definition. Shadow APIs are surfaced in the Discovery dashboard with request volume and first-seen timestamps.