A scan should cover every API version and host that anyone outside your team can reach, not just current production. Old versions, beta hosts and staging copies with public addresses are common places for missing checks. Build the scan list from an inventory, then confirm it against traffic and discovery.
Why current production is not enough
OWASP lists improper inventory management as API9:2023. Its prevention guidance says to keep external protection in place for every exposed API version, not just the current production one. When a newer version adds security improvements, assess whether to backport them or retire the old version.
The practical meaning for testing: if v1 still answers and v2 has the fixes, a scan of v2 gives you a clean report while v1 stays open.
What the inventory should contain
OWASP's guidance names these fields for each API host:
| Field | Examples |
|---|---|
| Environment | Production, staging, test, development |
| Who can reach it | Public, internal, partners |
| API version | v1, v2, beta |
| Integrated services | Role of each, data exchanged, sensitivity |
| Details | Authentication, error handling, redirects, rate limiting, CORS policy, parameters, requests and responses |
It also recommends generating documentation automatically from open standards, and including that build in your CI/CD pipeline, plus limiting access to the docs to authorized people.
Turning the inventory into a scan list
- Export the list of hosts and versions.
- For each one, record whether it is in scope, which accounts exist, and what rate ceiling applies.
- Mark non-production hosts. The guidance warns against using production data there and says to apply production-grade controls if you cannot avoid it.
- Run the same authorization matrix on every version, not a lighter test on old ones.
- Record the scan date per host in the inventory. A host with no date has never been scanned.
Finding what is not on the list
The inventory will be incomplete. The OWASP reconnaissance guidance lists several ways to find more:
- Common documentation paths such as
/swagger.json,/openapi.jsonand/api-docs. - Historical URLs from web archives.
- Client-side HTML and JavaScript that reference API paths.
- Port scans, because API servers often sit on non-standard ports.
- Source code route extraction, when you have the code.
- Wordlist-based discovery against your own hosts.
Run these against your own estate on a schedule, and compare the output with the inventory. Every difference is either a missing record or a forgotten service.
Decide: backport or retire
For each old version still receiving traffic, check who calls it. If nobody does, retire it. If clients still depend on it, either backport the security fixes or set a dated plan to move them. Scanning it without deciding only produces a list of known problems.
Where Safeguard fits
Safeguard's asset discovery can help build and refresh the list of what your organization runs, and its compliance and evidence automation can keep a dated record of reviews. Neither replaces the host and version fields above, which you need to maintain for each API.
Worked example: reconciling an inventory with reality
A logistics company believes it has two public APIs: a tracking API at version 2 and a partner API at version 1. Its inventory sheet lists four hosts. A security engineer runs a short reconciliation.
Inventory as written.
| Host | Environment | Reachable by | Version | Last scanned |
|---|---|---|---|---|
| api.example.test | Production | Public | v2 | Last month |
| partner-api.example.test | Production | Partners | v1 | Last month |
| api-staging.example.test | Staging | Public (for partners) | v2 | Never |
| api-internal.example.test | Production | Internal | v2 | Never |
Discovery pass. The engineer checks four sources.
- Documentation paths. Requests to common spec locations on each host. The production host serves a spec for v2 and, unexpectedly, a second one for v1.
- Historical URLs. An archive search for the company's domain lists
api.example.test/v1/tracking. A live request returns data. The v1 tracking API is still running on the production host. - Front-end code. The mobile web bundle references
api-beta.example.test. That host is not in the sheet, and it resolves. - Port scan of the company's own address range. A host answers on an unusual port with an API response. It is a leftover reporting service.
Reconciled inventory.
| Host | Gap found |
|---|---|
| api.example.test | A live v1 tracking API nobody listed |
| partner-api.example.test | None |
| api-staging.example.test | Never scanned, and publicly reachable |
| api-internal.example.test | Never scanned |
| api-beta.example.test | Not in the inventory at all |
| Reporting service on an unusual port | Not in the inventory at all |
Two hosts and one version were missing. Two listed hosts had never been scanned.
Decisions. For each item the engineer asks who owns it and who calls it.
- v1 tracking: access logs show two customers still calling it. Backport the fixes and set a retirement date.
- Beta host: owned by a team that has moved on. No traffic in 90 days, so shut it down.
- Reporting service: owned by finance. Add it to the inventory, restrict network access, and scan it.
- Staging: reachable by partners, so scan it with the same authorization matrix as production, using synthetic data.
- Internal host: scan it. Internal reachability still matters if an attacker gets a foothold.
Scan plan after reconciliation
Six targets, each with accounts, a rate ceiling and a window, recorded in the inventory with a scan date. The inventory sheet gains a column for next scan due. The discovery pass becomes a monthly calendar item, and any difference between it and the sheet is raised as a ticket.
What this tells you about coverage
Before the exercise, the company could say it scanned two of its APIs. After, it could say it scanned six endpoints it knew about, and it had a process for finding the next unknown one. The second statement is the one a reviewer can trust.
Try it yourself
Open the demo and look at how it presents ongoing checks. Think about how a monthly discovery pass would surface a new host and where you would record it.
Click through it at your own pace, or open it full screen.
Quick check
Do internal-only APIs need to be in the inventory?
Yes. The inventory records who can reach each host, including internal and partner access. Internal reachability still matters if an attacker gets inside.
How often should discovery run?
Often enough that a new host cannot sit unnoticed for long. Monthly is a reasonable start for a small estate, and after any major release or migration.
Should we scan a host that is about to be retired?
Yes if it is reachable and holds data, because it stays exposed until it is gone. Prioritize shutting it down, and scan it meanwhile if shutdown will take more than a few days.
Sources
Last reviewed: 19 October 2026.
