Ask a product team how many APIs they run and you will usually get the number in the Swagger file. Ask the servers and the answer is often longer: a v1 API still serving an old app version, an endpoint built for one partner, a staging API on a public subdomain, a debug route nobody removed. Attackers look for exactly these, because they tend to miss the fixes applied to the current version.
The OWASP API Security Top 10 (2023) lists improper inventory management as a risk in its own right. This guide explains how to build an API inventory before a security test, what to record for each API, what to retire first and how to turn the list into a test scope.
Quick answer: An API inventory is a list of every API host, version and endpoint that can be reached, with its owner, its callers, its authentication and the data it handles. Build it from gateway and server logs, code routes, API documentation, mobile app traffic and DNS records. Retire what you no longer need, then give the rest to the testers as the scope.
What shadow and zombie APIs look like
The terms are informal, but the problems are real and common in fast-growing products:
- Shadow APIs: live endpoints that are not documented anywhere, often built quickly for a feature launch, an internal tool or a single customer integration.
- Zombie APIs: old versions kept running for backward compatibility. When you add an ownership check to /api/v2/orders, the same check may never reach /api/v1/orders, which still answers requests.
- Exposed non-production APIs: staging, UAT and developer environments on public DNS, sometimes with a copy of real data and weaker login rules.
- Partner and webhook endpoints: routes that receive callbacks from payment gateways, SMS providers or partners, and are easy to forget because no user ever sees them.
Broken object level authorisation (BOLA), the first item in the same OWASP list, is far more likely on an endpoint nobody is maintaining. That is why inventory comes before testing.
Seven places to find the APIs you actually run
- Gateway and proxy configuration: Nginx or Apache virtual hosts, load balancer rules, AWS API Gateway stages or Kong routes.
- Access logs: group several weeks of requests by path pattern. Paths that appear in logs but not in your documentation are your first shadow APIs.
- Code routes: route files and controllers in each service. In Laravel, for example, php artisan route:list prints every registered route.
- Documentation: OpenAPI or Swagger files and Postman collections. Also check whether a Swagger UI page is publicly reachable in production.
- App traffic: run your Android, iOS and web apps through an intercepting proxy, or decompile the APK, to see every base URL the apps call, including old ones.
- DNS and certificates: list subdomains such as api, api-staging and uat. Public certificate transparency logs often reveal hostnames you had forgotten.
- Cloud consoles: API Gateway stages, serverless function URLs, container services and load balancers that are open to the internet.
Finally, ask people. Sales and support teams often know about a partner integration that engineering has forgotten.
What to record for each API
A spreadsheet is enough to begin with. The aim is to know, for every entry, who owns it and how risky it is.
| Field | Why it matters for testing |
|---|---|
| Host and base path | Defines exactly what is in scope |
| Version and status | Current, deprecated or due for retirement, with a date |
| Owner | Someone must answer tester questions and fix findings |
| Callers | Web app, Android or iOS app versions, partners or internal tools |
| Authentication | JWT, OAuth 2.0, API key, session cookie or none |
| Data handled | Personal data, KYC documents, payments or internal-only data |
| Environment and exposure | Production, staging or development, and whether it is open to the internet |
| Rate limits | Shows where brute force and OTP abuse checks are needed |
Retire before you test
Testing an API you do not need is wasted money. Retiring it removes the risk for good. For every deprecated or unknown entry, make one of three decisions: retire it, block it at the gateway, or bring it up to the same controls as the current version.
- Watch before switching off: check logs to see who still calls the old version, then warn those callers and set a date.
- Force app updates: if old mobile app versions are the only reason a v1 API exists, set a minimum supported version so users must update.
- Close developer tools: remove public Swagger UI pages, debug endpoints and test routes from production, or put them behind a login.
- Fence off staging: restrict non-production APIs to a VPN or an IP allowlist and never load unmasked customer data into them.
Turn the inventory into a test scope
Once the list is clean, most of the scoping work is done. Mark each API as in or out of scope, then hand the testers:
- The inventory itself, so they can test coverage against it.
- OpenAPI files or Postman collections for the in-scope APIs, even if they are incomplete.
- Test accounts for each role and tenant, because BOLA and function-level authorisation can only be tested by comparing what different users can reach.
- A list of webhooks and partner endpoints, with a note on how each one verifies the caller.
- The third-party APIs you call, so testers can review how your system trusts their responses, which the OWASP list covers as unsafe consumption of APIs.
For token-level hardening after the test, our guide to API security and OAuth hardening goes into JWT and OAuth settings. The API security testing service page describes how a full test is run.
Keep the inventory alive
An inventory built once goes stale within a few releases. Keep it current with small habits:
- Release checklist: no new endpoint goes live without an inventory entry and a named owner.
- Spec checks in CI: compare the OpenAPI file with the registered routes and fail the build when they drift apart.
- Periodic log review: look for paths that are not in the inventory, for example every quarter.
- Alerts on old versions: get notified when traffic reaches a deprecated version you thought was unused.
You can read the current OWASP API risk list on the OWASP API Security Project page.
How EthicsComputer can help
Our API security testing works from your API documentation, Postman collections or traffic captured from your apps, so endpoints missing from the documentation are still found and tested. You receive an endpoint coverage matrix alongside the findings, and most assessments typically take 5 to 15 working days. If the APIs mainly serve a mobile app, we can combine the work with mobile app security testing, and our API development team can help retire or rebuild old versions.
Do you know how many API versions are still answering requests?
Tell us about your apps, partners and API documentation, and we will help you scope a test that covers what is actually live.
About the author
Vinay Grover founded EthicsComputer in Rohtak, Haryana in 2018 and leads its cybersecurity, software and AI work for clients across India and abroad. EthicsComputer is ISO 9001, ISO/IEC 27001 and ISO 20000-1 certified.
