API inventories rarely fail because nobody created a spreadsheet. They fail because the deployed environment keeps changing: teams release new services, temporary routes become permanent, partners retain old integrations, and retired versions continue receiving traffic. The result is a growing gap between the APIs an organization believes it operates and the APIs that are actually reachable.
Why unknown and outdated APIs matter
An API cannot be governed well when its owner, purpose, consumers, data, environment, or lifecycle state is unclear. Missing context affects more than security. It slows incident response, complicates audits, increases cloud and support costs, and makes even a simple retirement decision risky.
OWASP addresses this problem under API9:2023 Improper Inventory Management. OWASP highlights documentation blind spots, missing host inventories, unknown environments, deprecated versions, and absent retirement plans. It also emphasizes visibility into sensitive data flows and third-party integrations.
Shadow APIs vs zombie APIs vs ghost APIs
These phrases are commonly used in API security, but they are not separate OWASP categories and their definitions vary between vendors. The distinctions below are useful when they lead to different operational actions.
| Term | Practical definition | Typical cause | First action |
|---|---|---|---|
| Shadow API | Active API exposure missing from the approved inventory or governance process. | Fast delivery, alternate routing, direct service exposure, acquisitions, or undocumented partner work. | Confirm exposure, purpose, owner, consumers, and required controls. |
| Zombie API | Deprecated, obsolete, or superseded API version that still responds to requests. | Incomplete migration, compatibility promises, forgotten deployments, or weak retirement governance. | Measure consumers, compare security controls, reduce exposure, and establish a sunset plan. |
| Ghost API | Informal term used here for an endpoint visible in traffic or infrastructure but not confidently tied to an owner, service, document, or approved purpose. | Orphaned workloads, unclear service boundaries, stale DNS, ownership changes, or incomplete telemetry. | Trace the route to workload and team, then classify it as approved, shadow, zombie, or unauthorized. |
A single endpoint can fit more than one label. For example, an old partner API may be both a zombie version and a shadow asset if it is missing from the approved inventory.
How API sprawl develops
Delivery moves faster than governance
A team creates a temporary endpoint for a launch, migration, mobile release, or customer integration. The route succeeds, but inventory and ownership records are never updated.
Infrastructure exposes alternate paths
Traffic may bypass the expected gateway through direct load-balancer addresses, legacy proxies, secondary domains, service-mesh ingress, cloud functions, or public Kubernetes services.
Versions outlive migration plans
Consumers continue using an older version, the replacement lacks feature parity, or the owner cannot confidently identify every dependency. The old route remains online indefinitely.
Ownership changes
Reorganizations, acquisitions, outsourcing, and staff turnover can separate an API from the people who understand its business purpose, data, and operational dependencies.
Documentation describes intent, not reality
OpenAPI documents, gateway catalogs, and service registries are valuable, but they can become stale or omit operations created dynamically at runtime.
Third-party data flows are incomplete
An organization may inventory its public API but miss outbound API calls, partner callbacks, webhooks, and data shared with external services.
The security and business risks
The label is less important than the control gap. Unknown and outdated APIs can remain connected to current databases, identities, queues, and business workflows while receiving weaker protection than the current production path.
Security risks
- Older authentication and authorization: superseded versions may not include current object, property, tenant, or function-level checks.
- Missing edge protections: alternate hosts may bypass rate limits, bot controls, schema validation, or threat detection applied to the primary gateway.
- Known vulnerabilities and outdated dependencies: forgotten deployments are less likely to receive patches and secure configuration updates.
- Sensitive data exposure: old response schemas, debug routes, test environments, or partner integrations may reveal fields no longer intended for use.
- Weak incident evidence: endpoints outside normal logging and monitoring make it harder to confirm affected identities, objects, and data flows.
Operational and commercial risks
- Support teams cannot explain who depends on the endpoint.
- Compliance evidence does not match the production environment.
- Cloud resources and licenses remain active without a clear business owner.
- Teams are afraid to remove old routes because consumer impact is unknown.
- Security incidents take longer to scope because inventory and data-flow records are incomplete.
NIST SP 800-228 recommends identifying API risks and controls across pre-runtime and runtime lifecycle stages. Its March 2026 update added appendices that organize API risks by category and controls by lifecycle stage, reinforcing the need to connect inventory work with development, deployment, operation, and retirement.
How to discover shadow, zombie, and ghost APIs
Discovery works best as reconciliation, not as a one-time scan. Build an expected view from design and governance records, build an observed view from infrastructure and traffic, then investigate every meaningful difference.
1. Collect the expected inventory
- API catalogs, developer portals, OpenAPI documents, GraphQL schemas, and gRPC descriptors.
- Source repositories, infrastructure-as-code, deployment manifests, and CI/CD records.
- Gateway routes, ingress rules, service catalogs, CMDB entries, DNS zones, certificates, and cloud asset inventories.
- Ownership, data-classification, third-party, and architecture records.
2. Collect the observed inventory
- API gateways, reverse proxies, load balancers, ingress controllers, and web application firewalls.
- Service meshes, distributed traces, application logs, network metadata, and cloud flow logs.
- Browser and mobile clients, SDK telemetry, partner traffic, webhooks, and outbound API calls.
- Passive traffic analysis that identifies hosts, routes, methods, operations, response shapes, and usage patterns.
3. Normalize API identity
Use a consistent identity model so the same API is not counted several times. For REST, this usually includes environment, host, base path, normalized route template, method, and version. For GraphQL, include endpoint, operation name or document hash, and operation type. For gRPC, include authority, service, and method.
API record example
Environment: production
Host: api.example.com
Protocol: REST
Route template: /customers/{customerId}/exports
Method: POST
Version: v2
Exposure: partner
Owner: Data Platform
Data class: confidential
Lifecycle: active
Last observed: 2026-08-04
Retirement date: not set4. Reconcile expected and observed views
| Finding | Meaning | Likely classification |
|---|---|---|
| Observed but not documented | A live route is missing from the approved records. | Potential shadow API |
| Documented but not observed | The API may be dormant, internal, seasonal, incorrectly monitored, or ready for retirement. | Needs validation |
| Deprecated but still used | The migration is incomplete or an unknown consumer remains. | Zombie API |
| Observed with no owner | The route cannot be connected to a responsible service team. | Ghost or orphan API |
| Unexpected environment or host | A test, beta, regional, or direct-service deployment is reachable beyond its intended audience. | Exposure misconfiguration |
| Unexpected data flow | Sensitive fields are being shared with an unapproved or poorly documented third party. | Data-flow blind spot |
Prioritize findings by risk, not by name
A forgotten health endpoint and an undocumented bulk export should not receive the same response. Use a repeatable scoring model that combines impact, exploitability, and operational uncertainty.
| Factor | Questions | Higher-risk signals |
|---|---|---|
| Exposure | Who can reach it? | Public internet, broad partner access, or unintended cross-network reachability |
| Data | What does it receive or return? | Credentials, tokens, personal data, payment data, confidential records, or bulk exports |
| Action | What can it change? | Account recovery, money movement, administration, deletion, provisioning, or privilege changes |
| Controls | Does it match current security policy? | Weak authentication, missing authorization, absent rate limits, poor validation, or no runtime monitoring |
| Lifecycle | Is the version supported? | Deprecated, unpatched, unsupported runtime, or no retirement plan |
| Ownership | Can a team make decisions? | No confirmed owner, unclear consumers, or conflicting records |
| Behavior | How is it being used? | Enumeration, unusual identity diversity, sudden volume, repeated errors, or access from unexpected locations |
Use the score to decide whether to monitor, restrict, patch, migrate, quarantine, or retire the API. A high-risk endpoint without an owner should trigger immediate containment and executive escalation, not an open-ended inventory ticket.
Safe validation and authorized testing
Discovery does not grant permission to probe a system. Validate only assets your organization owns or has explicit authorization to test. Begin with passive evidence and configuration records before sending active requests.
- Confirm scope: document approved domains, environments, test windows, identities, rate limits, and stop conditions.
- Use non-sensitive identities and objects: avoid real customer records when confirming behavior.
- Start with low-impact checks: validate host reachability, authentication requirements, documented methods, and expected response status without attempting bypasses.
- Compare security controls: confirm whether old and alternate versions enforce the same authentication, authorization, throttling, validation, and logging as the current version.
- Protect evidence: mask tokens, credentials, personal data, and response bodies before sending findings to tickets or SIEM systems.
- Stop on unexpected impact: do not continue when testing affects availability, real data, or production workflows.
The OWASP API Security Testing Framework maps deprecated versions, shadow endpoints, and exposed documentation to API9 testing. The OWASP Web Security Testing Guide also explains why old and unreferenced resources can expose sensitive information or vulnerable functionality.
Remediation: contain, classify, and govern
Unknown but probably legitimate
Limit exposure if needed, identify the workload and consumers, assign an interim owner, add monitoring, document data and access requirements, and set a deadline for approval or retirement.
Deprecated but still required
Apply the same protection as the current API, patch dependencies, restrict consumers, publish migration guidance, measure remaining usage, and create an approved sunset date.
Unauthorized or unnecessary
Contain access, preserve evidence, confirm dependencies, revoke credentials or routes, remove the deployment, and review how it bypassed normal controls.
Third-party data-flow blind spot
Identify the contract and business purpose, validate the minimum data required, review authentication and retention, monitor the exchange, and remove unapproved fields or integrations.
For every finding, the remediation record should answer: who owns the decision, what consumers are affected, what data is involved, which controls are missing, what temporary safeguards are active, and when the final state will be reached.
How to retire zombie APIs without breaking consumers
Immediate blocking can be appropriate for an unauthorized or actively exploited endpoint, but normal deprecation needs a controlled process.
- Declare the lifecycle state: mark the version as deprecated in the catalog, documentation, and owner records.
- Identify consumers: use authentication identities, client IDs, tokens, network origin, user agents, traces, and partner records rather than relying only on traffic totals.
- Publish the replacement: document feature differences, migration steps, test environments, and support contacts.
- Communicate dates: send direct notices to internal teams, customers, and partners with meaningful lead time.
- Signal deprecation programmatically: where appropriate, use the HTTP Deprecation response header and the Sunset header to communicate lifecycle information to clients.
- Reduce exposure: restrict new consumers, narrow network access, enforce current controls, and disable unused methods or routes.
- Track migration: measure remaining requests by consumer and escalate accounts that miss agreed milestones.
- Remove and verify: disable routing, deployment, credentials, DNS, certificates, documentation, and monitoring exceptions, then confirm that the endpoint no longer responds.
Ownership model and useful metrics
Minimum ownership model
- Business owner: approves purpose, data use, consumer access, and retirement impact.
- Technical owner: maintains the service, schema, dependencies, capacity, and migration.
- Security owner: defines required controls, risk acceptance, monitoring, and incident evidence.
- Platform or API governance: maintains inventory standards, lifecycle states, automation, and escalation rules.
Metrics that support decisions
- Percentage of observed APIs matched to an approved inventory record.
- Percentage of APIs with confirmed business and technical owners.
- Median time to classify a newly observed endpoint.
- Number and age of high-risk unknown APIs.
- Traffic volume and consumer count on deprecated versions.
- Percentage of deprecated APIs with an approved sunset date and migration owner.
- Coverage of sensitive APIs by runtime monitoring and incident logging.
- Time from final consumer migration to verified technical removal.
Avoid celebrating raw endpoint growth or discovery counts. A mature program reduces uncertainty, shortens classification time, increases ownership coverage, and safely removes unnecessary exposure.
Common mistakes to avoid
Assuming one gateway sees every API. Direct service paths, internal traffic, regional endpoints, legacy proxies, and alternate hosts may bypass it.
Treating documentation as proof of deployment. Documentation describes intended behavior. Infrastructure and traffic reveal what is actually reachable.
Scanning once and calling it an inventory. New routes appear continuously. Reconciliation should run after deployments and at a regular cadence.
Counting paths without context. Route templates, methods, environments, versions, protocols, and operations need normalization before totals are meaningful.
Blocking old APIs before finding consumers. Unplanned removal can disrupt customers, payments, mobile applications, and internal operations.
Keeping zombie APIs indefinitely because removal feels risky. Temporary compatibility must have an owner, compensating controls, migration evidence, and a sunset date.
Sending raw secrets or payloads to security tools. Discovery evidence should be minimized and masked so the inventory process does not create a second data-leakage problem.
Authoritative references
- OWASP API9:2023 — Improper Inventory Management
- OWASP API Security Testing Framework
- OWASP WSTG — Old, Backup, and Unreferenced Files
- NIST SP 800-228 — Guidelines for API Protection for Cloud-Native Systems
- RFC 9745 — The Deprecation HTTP Response Header Field
- RFC 8594 — The Sunset HTTP Header Field
Conclusion
Shadow APIs, zombie APIs, and ghost APIs are different expressions of the same operating problem: deployed reality has moved beyond the organization’s inventory, ownership, and lifecycle controls.
The durable solution is continuous reconciliation. Compare expected records with observed infrastructure and traffic, normalize API identity, prioritize by data and business impact, assign accountable owners, protect necessary legacy versions, and retire unnecessary exposure through measured consumer migration.
FAQs About Shadow APIs, Zombie APIs, and Ghost APIs
What is a shadow API?
A shadow API is an active API host, route, method, or operation that is missing from the approved inventory or operating outside the normal ownership, review, and monitoring process.
What is a zombie API?
A zombie API is an obsolete, deprecated, or superseded API version that still accepts traffic. It may remain reachable because of an incomplete migration, an old deployment, or a forgotten route.
What is a ghost API?
Ghost API is an informal term with no single industry definition. In this guide, it means an endpoint observed in traffic or infrastructure that cannot be confidently linked to an owner, service, document, environment, or approved business purpose.
Are shadow, zombie, and ghost APIs separate OWASP risks?
No. They are useful operating terms rather than separate OWASP categories. They commonly indicate OWASP API9:2023 Improper Inventory Management, which covers outdated documentation, unknown hosts, deprecated versions, and missing retirement plans.
How can organizations discover unmanaged APIs?
Combine runtime observations from gateways, load balancers, ingress, service meshes, logs, traces, and cloud networking with design-time records such as OpenAPI files, repositories, service catalogs, DNS, certificates, and ownership systems. Reconcile the two views continuously.
Why is an API gateway inventory not enough?
A gateway only inventories traffic that passes through it. Direct service exposure, alternate domains, legacy proxies, partner routes, internal east-west traffic, and forgotten cloud endpoints may sit outside that view.
How should an unknown API be prioritized?
Prioritize by exposure, data sensitivity, privilege, business action, authentication strength, traffic behavior, known vulnerabilities, environment, owner confidence, and whether the endpoint has an approved retirement plan.
Should a zombie API be blocked immediately?
Not automatically. First identify consumers, confirm business impact, compare the old and current security controls, reduce exposure, notify owners, publish migration dates, and remove access through a controlled retirement process.
What should every API inventory record contain?
At minimum, record the host, environment, protocol, base path or service, version, operations, owner, consumers, authentication method, data classification, exposure, dependencies, last-seen traffic, lifecycle state, and retirement date.
How can teams test for hidden or forgotten APIs safely?
Test only systems you own or are explicitly authorized to assess. Start with passive inventory reconciliation, then validate approved candidate endpoints with rate-limited requests, non-sensitive test identities, and documented stop conditions.
How do Deprecation and Sunset headers help?
The HTTP Deprecation header can signal that a resource has been deprecated, while the Sunset header can communicate when it is expected to become unavailable. They support migration but do not replace consumer outreach and runtime usage tracking.
Which metrics show API inventory improvement?
Useful measures include inventory coverage, percentage of APIs with confirmed owners, unknown-endpoint age, deprecated-version traffic, time to classify new endpoints, retirement-plan compliance, and the share of sensitive APIs covered by runtime monitoring.
Need a live view of unknown and deprecated APIs?
Ammune helps teams discover active APIs, compare runtime behavior with expected inventory, identify risky exposure, and give security and platform teams evidence they can act on.