OWASP API9:2023, Improper Inventory Management, says teams need visibility not only of their own API hosts and versions but also of how their APIs store or share data with external third parties. It names a "data flow blindspot" for sensitive data shared with third parties without approval, inventory or visibility.
The two blind spots
OWASP defines two conditions under which an API is vulnerable to this risk.
Documentation blindspot. The purpose of an API host is unclear, and there are no answers to which environment it runs in (production, staging, test, development), who should have network access (public, internal, partners) and which version is running. Documentation is missing or outdated, there is no retirement plan for each version, or the host inventory is missing or outdated.
Data flow blindspot. There is a sensitive data flow where the API shares data with a third party, and there is no business justification or approval of the flow, no inventory or visibility of it, or no deep visibility of which type of sensitive data is shared.
Most coverage of API9 focuses on the first. Product teams that integrate vendors should read the second at least as carefully.
What OWASP recommends
From its prevention guidance, the parts that matter for third-party SDKs and APIs:
- Inventory integrated services and document their role in the system, what data is exchanged (the data flow) and its sensitivity.
- Inventory all API hosts, with environment, audience and version.
- Generate documentation automatically using open standards and include the documentation build in CI/CD.
- Avoid using production data with non-production API deployments, or give those deployments the same security treatment.
- Make documentation available only to those authorized to use the API.
Mapping the text to a record
| OWASP wording | Inventory field |
|---|---|
| Role in the system | Purpose |
| What data is exchanged | Data classes and direction |
| Sensitivity | Highest data class |
| Business justification or approval | Approver and date |
| Environment | Production, staging, test |
| Who should have network access | Audience |
| Version | API and SDK version |
| Retirement plan | Exit plan and end date |
An example from the document
OWASP gives a scenario in which a social network let developers of independent apps integrate with it. A consent was requested from the end user, but the data flow between the network and the apps was not restrictive or monitored enough. A consulting firm built a malicious app, gained consent from 270,000 users and, through the flaw, accessed private information of 50,000,000 users. It is an illustration from the OWASP document, and the lesson for you is the same: know which partners receive what, and limit it.
How to use this in your program
Read API9 with your product teams, then check your own inventory against the table above. Any field you cannot fill in is a finding.
Try it yourself
Open the API security scan demo and look at which host and operation details a scan records. Compare them with the host fields OWASP asks you to document.
Click through it at your own pace, or open it full screen.
Quick check
Does API9 only apply to API providers?
No. It also covers how your API shares data with outside parties, so teams that call vendors are in scope.
Is the OWASP list a standard I must follow?
It is an awareness document, not a regulation. Many teams use it as a baseline for reviews.
Safeguard offers SBOM and dependency scanning and asset discovery that can feed this kind of inventory. You can run a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
