OWASP API Top 10 API9 Improper Inventory Management Guide: Finding Shadow and Zombie APIs

You cannot secure an API you do not know is running, and attackers are often better at finding your forgotten beta hosts and old versions than your own teams are. OWASP API9:2023 Improper Inventory Management covers two blind spots: API hosts and versions nobody documents or retires, and sensitive data flows to third parties nobody approved or tracks. This guide treats API9 as a requirement set: what the OWASP text asks for, how to build and maintain an API inventory that finds shadow APIs (running but undocumented) and zombie APIs (deprecated but still live), the machine identities each API depends on, the evidence an assessor should collect and how API9 maps to NIST SP 800-53, NIST CSF 2.0, ISO/IEC 27001:2022, CIS Controls and OWASP ASVS 5.0. It is for API platform owners, architects, security engineers and assessors. For the whole list see Top 10 API Security Risks.

Key takeaways

• Two blind spots, not one. OWASP defines a documentation blind spot (unknown purpose, environment, audience or version, no retirement plan) and a data flow blind spot (sensitive data shared with third parties without justification, inventory or visibility).
• Old and non-production hosts are the soft target. OWASP's first scenario is a beta host running the same password reset API without the rate limiting that protected production.
• Inventory has to be built from observation, not declaration. Specifications, gateway configuration, traffic, DNS and cloud resources each reveal APIs the others miss; the gap between them is the shadow API list.
• Every version needs a retirement date. The Deprecation (RFC 9745) and Sunset (RFC 8594) headers let you announce retirement to callers in a machine-readable way.
• Each API runs as, and is called by, non-human identities. An inventory entry that records the API's credentials and its consumers' credentials is what makes safe decommissioning possible.

What it is and who it applies to

API9:2023 Improper Inventory Management is the ninth entry in the OWASP API Security Top 10 2023. OWASP rates exploitability Easy, prevalence Widespread, detectability Average and technical impact Moderate, with business impact specific to each organisation. Threat agents typically gain access through old API versions or endpoints left running unpatched with weaker security requirements, or reach sensitive data through a third party that has no reason to hold it. OWASP notes that microservices, cloud computing and Kubernetes make APIs easy to deploy and therefore easy to expose by accident, and that search engine dorking, DNS enumeration and internet-wide device search engines are enough to find targets. Different versions or deployments are sometimes connected to the same production database. The entry cites CWE-1059 Incomplete Documentation.

The documentation blind spot exists when, for any API host, nobody can answer three questions: which environment it runs in, who should have network access to it, and which version it runs; or when documentation is missing or stale, there is no retirement plan per version, or the host inventory is missing or outdated. The data flow blind spot exists when an API shares sensitive data with a third party without a business justification or approval, without inventory or visibility of the flow, or without knowing which types of sensitive data are shared.

API9 applies to anyone who can create an API endpoint, which in most organisations means every delivery team, plus the platform, cloud and third-party risk teams. Common sources of unmanaged APIs:

• Old versions: /v1 left running after /v2 shipped, often without later security fixes.
• Non-production hosts: beta, staging, preview and test deployments reachable from the internet, sometimes with production data.
• Bypass paths: services reachable directly by function URL, pod ingress or cloud load balancer, skipping the gateway and its controls.
• Partner and mobile back ends: APIs built for one client and never added to the central catalogue.
• Third-party integrations: outbound flows to analytics, enrichment and SaaS platforms, the subject of the data flow blind spot. See the OWASP API Top 10 API10 Unsafe Consumption of APIs Guide.
• AI-generated and agent-facing endpoints: internal tools and MCP servers stood up quickly for agents, often outside normal review. See the Shadow AI Discovery Guide.

Structure and key requirements

The OWASP entry gives eight prevention items. The table turns each into a requirement and a concrete implementation.

Discovery sources compared

No single source finds everything. Combine them and treat the difference between declared and observed as the work queue. See the Attack Surface Management Guide for the external view.

Small organisations can usually get to a reliable inventory from gateway configuration, cloud accounts and an external scan, reconciled monthly. Large organisations need traffic-based discovery feeding a catalogue automatically, because the rate of change outpaces manual reconciliation, and a policy that a deployment without an inventory entry cannot receive public ingress.

Retiring versions with standard headers

• Deprecation header (RFC 9745, Standards Track, March 2025): signals that a resource will be or has been deprecated, as a structured date such as Deprecation: @1688169599. It is a hint and does not change behaviour. The deprecation link relation points callers to migration information.
• Sunset header (RFC 8594, Informational, May 2019): gives the HTTP-date when the resource is expected to become unresponsive. RFC 9745 says Sunset must not be earlier than the Deprecation date.
• OpenAPI deprecated flag: marks operations that consumers should stop using, so portals and generated clients warn developers.

Identity and NHI requirements

Inventory is where API security and non-human identity governance meet. Each API holds credentials of its own and is called by machine identities belonging to consumers, and neither can be cleaned up safely without the other.

• Record the API's own identities: the service account, workload identity and secrets each API uses to reach databases and other services. A zombie API usually still holds live database credentials, which is why OWASP warns that old versions are sometimes connected to the production database. See the Service Account Inventory Template.
• Record who calls it: the API keys, OAuth clients and certificates issued to consumers, with owners. Traffic by credential is the fastest way to find who must migrate before a version is switched off. See the API Key Management Guide.
• Same authentication on every version: older versions often accept static keys or weaker token validation that newer versions removed. Enforce the current authentication standard at the gateway for all versions. See the OWASP API Top 10 API2 Broken Authentication Guide.
• Decommission identities with the API: retiring an API must revoke its credentials, delete its service accounts and remove consumer keys scoped only to it. Otherwise the credentials outlive the service. See the NHI Offboarding and Decommissioning Guide.
• Third-party flows run on tokens: OWASP's second scenario, in which an app consented to by 270,000 users reached data on 50,000,000, is a data flow failure carried out with legitimately issued access. Inventory each partner's OAuth scopes and review what data they actually retrieve. See the Third-Party Access Guide.

Implementation steps

1. Define the inventory record. Mandatory fields: API name, owner team, hostnames and routes, environment, audience, version and lifecycle state (planned, active, deprecated, retired), specification location, authentication method, credentials used and issued, data classification, third-party flows, retirement date.
2. Seed from what you have. Import gateway routes, specification repositories, cloud resource listings and DNS zones. Assign owners; anything without an owner after two weeks goes to an escalation list.
3. Discover from outside and from traffic. Run external attack surface scanning against your domains and certificate transparency logs, and enable traffic-based endpoint discovery on gateways and load balancers. Reconcile observed against declared.
4. Triage the gap. For each shadow or zombie API decide: document and bring under the gateway, or retire. Non-production hosts reachable from the internet with production data are the first priority.
5. Gate new APIs. Require an inventory entry and a specification in the pipeline before an API can receive public or partner ingress; fail builds where code routes diverge from the specification.
6. Set version policy. Publish how many versions may run at once and the minimum deprecation notice. Send Deprecation and Sunset headers, notify consumers identified by credential, and track remaining traffic.
7. Retire in stages. Brownout first (scheduled short outages or error responses to flush out remaining callers), then block at the gateway while keeping the deployment, then remove the deployment, DNS record and credentials. Rollback during brownout or block is a gateway route change.
8. Register data flows. Add each third-party flow to the register with approval and data types, and review partner scopes yearly with the third-party risk process. See the Third-Party Risk Management Guide.

Evidence and assessment

Two incidents show why discovery and monitoring belong together. In the McKinsey AI Platform Hack 2026, publicly exposed API documentation listed more than 200 endpoints, 22 of which accepted requests without authentication. In the T-Mobile API Breach 2023, data on about 37 million accounts was retrieved through a single API over roughly six weeks before detection; T-Mobile has not disclosed how the API was abused, but the length of the window shows the value of knowing which APIs return customer data and watching their volumes.

Detection signals and metrics

• Signals to alert on: traffic to routes or hosts not in the inventory; calls to deprecated versions after their sunset date; enumeration of version paths such as /v1, /beta or /internal; new DNS records or certificates for API hostnames; documentation endpoints answering from outside.
• Inventory coverage: observed API endpoints with an inventory entry and owner, as a share of all observed; target above 95 percent.
• Shadow API count: observed but undeclared APIs, trended monthly; should fall steadily.
• Zombie exposure: versions past their sunset date still reachable; target zero.
• Specification accuracy: share of APIs whose live routes match their specification.
• Retirement hygiene: share of retired APIs whose credentials, DNS records and deployments were all removed within 30 days.

Mapping to other frameworks

In OWASP ASVS 5.0, V13.1.1 asks that all communication needs, including external services, are documented, V13.4.5 that internal documentation and monitoring endpoints are not exposed unless intended, and V15.1.2 that a component inventory such as an SBOM is maintained. See the OWASP ASVS Guide and the Asset Inventory and CMDB Security Guide.

Common pitfalls

• Inventory as a one-off project: a catalogue built once and maintained by hand is stale within a quarter. Discovery has to run continuously and feed the catalogue.
• Controls tied to a hostname: OWASP's beta host scenario shows rate limiting placed in a component in front of one hostname. Apply controls to the API, wherever it is deployed, or block the other deployments.
• Deprecation without enforcement: announcing a sunset date and leaving the version running indefinitely because one large customer has not migrated. Set a date, brown out, then block.
• Retiring the code but not the credentials: removing a deployment while its database account, API keys and DNS record remain. The next team to reuse the name or credential inherits the risk.
• Public developer portals for internal APIs: published specifications and introspection hand attackers a complete map of routes and parameters.
• Ignoring outbound flows: inventories that list only inbound APIs miss the data flow blind spot entirely, which is where OWASP places third-party data exposure.

Practitioner checklist

• Keep one API inventory with environment, audience, version, owner, data class and credentials per host.
• Reconcile declared APIs against gateway, traffic, cloud, DNS and external scan findings at least monthly.
• Require an inventory entry and a validated specification before any API gets public or partner ingress.
• Restrict API documentation, Swagger UI and GraphQL introspection to authorised users.
• Apply the same gateway, authentication and rate limiting policies to every live version.
• Use masked or synthetic data in non-production, or give those hosts production controls.
• Publish a version policy and send Deprecation and Sunset headers with migration links.
• Retire in stages and revoke credentials, service accounts and DNS records with the API.
• Maintain a register of third-party data flows with approvals, data types and scopes.
• Alert on traffic to undeclared routes and to versions past their sunset date.

Standards and references

• OWASP: API9:2023 Improper Inventory Management
• OWASP: API Security Top 10 2023
• OWASP: Application Security Verification Standard 5.0
• IETF: RFC 9745 The Deprecation HTTP Response Header Field
• IETF: RFC 8594 The Sunset HTTP Header Field
• OpenAPI Initiative: OpenAPI Specification 3.1.0
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Top 10 API Security Risks · API Security Guide · Attack Surface Management Guide · NHI Offboarding and Decommissioning Guide · OWASP API Top 10 API8 Security Misconfiguration Guide