Testing API9:2023 Improper Inventory Management means mapping every API host, version, and environment an organization actually runs — production, staging, deprecated, and third-party-integrated — then proving which of those gaps an attacker can reach and exploit. The workflow pairs automated attack-surface discovery with manual verification of forgotten API versions, undocumented endpoints, and unsanctioned data flows, because scanners find hostnames but miss the business-logic exposure an inventory gap creates. A finding is only confirmed when a tester demonstrates that an undocumented or deprecated endpoint still accepts requests and returns production data. In 2026, most organizations still learn about their unmanaged endpoints from a red team or an external researcher rather than from their own asset register.
TL;DR
- Testing API9:2023 Improper Inventory Management requires full host, version, and environment discovery before any exploitation work.
- Deprecated v1 endpoints and undocumented shadow APIs remain the dominant finding pattern in 2026 assessments.
- Manual verification beats automated discovery because inventory gaps hide in business context, not signatures.
- Evidence for auditors means a diff: documented API surface versus live, reachable API surface.
- Best for organizations running microservices, multi-version APIs, or inherited platforms from acquisitions.
Why This Matters
API9 is not a single technical defect. It is a governance failure that surfaces as unauthenticated access, stale authorization logic, or leaked internal data. An attacker does not need a zero-day when a /api/v1/users endpoint retired from documentation in 2022 is still live, still unmonitored, and still backed by the production database.
The business consequence is direct. Every undocumented endpoint is an untested endpoint, and every untested endpoint sits outside the security team's reporting, monitoring, and patch coverage. Board-level security metrics built on a partial inventory overstate coverage by whatever percentage of the API surface nobody has counted.
The audit consequence is equally concrete. PCI DSS 4.0, SOC 2, and ISO 27001 assessors expect evidence that an organization knows which APIs exist before accepting claims that those APIs are controlled. A 2026 audit cycle that cannot produce a current, owner-attributed API inventory generates findings no matter how strong the controls on documented endpoints are.
How to Test API9:2023 Improper Inventory Management
API9 testing follows a discovery-then-exploitation sequence. Each step produces evidence of exploitability, not merely the presence of an unmanaged asset. A report that lists twelve forgotten subdomains without demonstrating what an attacker gains from them is an asset list, not a penetration test.
- Build a complete host inventory. Pull DNS records, certificate transparency logs, API gateway route tables, load balancer configurations, and cloud provider asset APIs to enumerate every host serving API traffic.
- Enumerate API versions in use. Probe
/v1/,/v2/,/beta/,/internal/, and version-selecting headers across every discovered host, in every environment reachable from the tester's position. - Diff documented endpoints against live behavior. Compare the OpenAPI or Swagger specification against traffic captured through an intercepting proxy during authorized application use. Anything live but undocumented becomes a candidate finding.
- Test deprecated endpoints for weaker controls. Older versions routinely retain authentication schemes and authorization logic that were hardened only in the current version.
- Validate environment segregation. Confirm staging, QA, and development APIs are not internet-reachable and do not share credentials or data stores with production.
- Trace third-party and partner data flows. Identify APIs exposed to vendors, integration partners, or acquired subsidiaries that never entered the primary inventory or monitoring scope.
- Confirm decommissioned endpoints are functionally dead. A 404 at the documented path is not proof of decommissioning. Test whether the backend service still processes requests through an alternate route, host header, or gateway rule.
- Assign ownership to every finding. An unmanaged endpoint without a named owner will still be unmanaged at the next assessment.
This is the same manual sequence that precedes authorization and injection work in an API penetration test run by AppSecure Security. Inventory mapping comes first for a simple reason: you cannot test what you have not found, and scope defined from documentation alone inherits every gap the documentation already has.
Scope and Prerequisites
Before any probing begins, the engagement needs written authorization covering every host the tester may discover — not only the hosts named in the statement of work. API9 testing is definitionally a discovery exercise, so a rigid asset list defeats the purpose. Negotiate scope as a domain and cloud-account boundary rather than an IP list.
Required inputs from the client side: current OpenAPI specifications, API gateway configuration exports, DNS zone access or a recent zone transfer, cloud asset inventory read access, and a point of contact who can confirm whether a discovered host is sanctioned. Without that last item, the tester cannot distinguish a legitimate undocumented service from a genuine shadow API.
Set a traffic-capture window with the application team. Passive capture of real application usage during that window produces the highest-fidelity picture of what the frontend actually calls, which is almost never identical to what the specification lists.
Host and Environment Discovery
Start outside-in, from the position of an unauthenticated internet attacker. Certificate transparency logs surface hostnames issued for internal tools, one-off demos, and partner integrations that nobody added to the CMDB. DNS records and cloud asset APIs fill the remaining gaps.
Cross-reference every discovered host against the organization's own asset inventory. The delta between what you find and what they track is where API9 findings live, and the size of that delta is itself a reportable metric for executive audiences.
Then repeat the exercise from inside the network perimeter or from an authenticated cloud role. Internal-only APIs routinely lack authentication entirely on the assumption that network segmentation protects them — an assumption that fails the moment any single application server is compromised.
Version and Deprecated Endpoint Testing
Versioned APIs accumulate security debt on a predictable curve. A v1 endpoint pulled from documentation three years ago often still runs on a container image nobody has rebuilt since, which means it also carries every unpatched dependency from that build.
Test each discovered version independently against the same test cases. Authorization checks added to v3 after an incident are rarely backported to v1, and rate limiting configured at the gateway for current paths frequently omits legacy routes. Where the current version enforces object-level checks and the legacy version does not, you have both an API9 finding and an API1 broken object level authorization finding chained together — which is the combination that turns a low-severity inventory note into a critical data-exposure report.
Documentation Drift Validation
OpenAPI specifications drift from reality within weeks of a sprint cycle. Developers add a query parameter, ship it, and update the spec later or never. Passive traffic capture reveals the parameters, headers, and endpoints the specification never listed, and each one needs its own authorization and input-validation test.
Pay specific attention to parameters that appear in traffic but not in the spec. Undocumented parameters are undocumented precisely because nobody reviewed them, which makes them the highest-yield targets for mass assignment and property-level authorization abuse.
Third-Party and Partner API Exposure
Inventory gaps compound after mergers, acquisitions, and partner integrations. An acquired company's API footprint rarely gets fully absorbed into the parent organization's monitoring within the first year, which leaves live access paths with no owner, no logging pipeline, and no patch schedule.
Review integration contracts alongside the technical testing. Contracts name the endpoints a partner is entitled to call; traffic shows which endpoints the partner's credentials can actually reach. That gap is an API9 finding with contractual as well as technical consequences.
Host discovery
- Coverage Method: Certificate transparency, DNS, cloud asset APIs
- Common 2026 Finding: Forgotten subdomains still serving production traffic
Version enumeration
- Coverage Method: Manual probing of versioned paths and headers
- Common 2026 Finding: Deprecated versions with unpatched authorization logic
Documentation diff
- Coverage Method: Proxy traffic capture vs. OpenAPI spec
- Common 2026 Finding: Undocumented parameters and internal-only endpoints
Environment segregation
- Coverage Method: External and authenticated network testing
- Common 2026 Finding: Staging APIs internet-reachable with production data
Third-party exposure
- Coverage Method: Contract review plus credentialed endpoint testing
- Common 2026 Finding: Partner tokens reaching endpoints outside contract scope
Decommission verification
- Coverage Method: Alternate-route and gateway-rule testing
- Common 2026 Finding: Retired services still resolving via legacy routes
Evidence to Capture
For each finding, capture the full request and response, the discovery method, the timestamp, and the environment identifier. Auditors and engineering teams need to reproduce the result; a screenshot of a hostname list satisfies neither.
Capture proof of data sensitivity where it exists. An undocumented endpoint returning a health-check payload is a hygiene issue. The same endpoint returning customer records is a reportable exposure with regulatory implications, and only the response body distinguishes the two.
False-Positive Checks
Three false positives dominate API9 reporting. First, wildcard DNS entries that make every arbitrary subdomain appear live — verify the response is a real service, not a catch-all. Second, intentionally public endpoints such as OAuth discovery documents and status pages, which are undocumented by convention rather than by error. Third, staging hosts that respond but hold only synthetic data, which changes severity substantially.
Confirm each candidate with the client contact before it enters the report. A finding the engineering team can dismiss in one sentence damages the credibility of the findings that matter.
Remediation Verification and Retesting
Retesting API9 remediation is not a repeat of the original scan. When a team decommissions an endpoint, verify the service is gone rather than the route: test alternate host headers, direct container or service IPs, and any gateway rule that previously fronted the path.
Where the remediation is process rather than technical — an added decommission workflow, enforced OpenAPI coverage in CI — verify by re-running the documentation diff. If the diff shrinks between assessments, the process is working. If it holds steady while the endpoint list changes, the organization fixed instances and not the cause.
Why Inventory Management Risk Varies
The volume and severity of API9 findings track organizational factors far more closely than they track the maturity of any single security tool.
- Concurrent API versions maintained — organizations running three or more live versions see proportionally more drift and more unbackported controls.
- Microservices sprawl with decentralized ownership — when no team owns the full catalog, gaps accumulate silently between service boundaries.
- Merger and acquisition history — acquired platforms arrive with legacy APIs that rarely retire on the planned schedule.
- Deployment velocity without a decommission workflow — fast pipelines lacking a retirement process leave dead code paths live indefinitely.
- Third-party integration count — every external contract adds surface the internal team does not fully control or monitor.
- Documentation enforcement in CI — organizations that do not fail builds on missing spec coverage cannot audit what was never written down.
Is API9 the Same as Shadow API Risk?
API9 is broader than shadow API risk. Shadow APIs — unknown, unmonitored endpoints — are one subset of improper inventory management, alongside deprecated versions, non-segregated environments, and unmanaged third-party exposure. Testing API9 properly covers all four categories, and a report that only lists shadow endpoints has covered roughly a quarter of the category.
How Does API9 Differ from API1 Broken Object Level Authorization?
API9 concerns whether an endpoint is known and monitored at all; API1 concerns whether a known endpoint enforces correct access controls on the objects it serves. Unmanaged inventory is frequently the condition that lets an attacker reach the endpoint where an authorization flaw then gets exploited, which is why the two categories appear together in chained findings.
Can Automated Discovery Tools Fully Solve Inventory Management?
Automated discovery tools cannot fully solve inventory management, because they identify hosts and endpoints but cannot determine business context, ownership, or whether an endpoint should still exist. Manual review decides which discovered assets are sanctioned, which are forgotten, and which represent exploitable exposure — and that judgment is the deliverable clients actually need in 2026.
API9 Testing Checklist
- Full host inventory built from DNS, certificate transparency, gateway routes, and cloud asset APIs
- Every API version enumerated, including deprecated, beta, and internal-only paths
- Live proxy traffic diffed against the current OpenAPI specification
- Deprecated endpoints tested against the same authentication and authorization cases as current versions
- Staging, QA, and development environments confirmed non-internet-facing and free of production data
- Third-party and partner exposure mapped against integration contracts
- Decommissioned endpoints verified functionally dead via alternate routes and host headers
- False positives cleared with the client contact before reporting
- Every finding assigned a named owner and a retirement or hardening deadline
FAQ
What is API9:2023 Improper Inventory Management?
API9:2023 Improper Inventory Management is an OWASP API Security Top 10 category covering unmanaged, undocumented, or forgotten API hosts, versions, and environments. It results in attackers finding and exploiting endpoints the security team never knew existed.
How do you test for improper inventory management in an API?
Start by building a full host and version inventory from DNS, certificate transparency, gateway routes, and cloud asset data, then diff live proxy traffic against the documented OpenAPI specification. Each gap is manually verified for reachability and data exposure before it is reported as a finding.
What tools detect shadow APIs?
Attack-surface management platforms and API gateway analytics surface candidate shadow APIs by comparing observed traffic against documented inventories. None replace manual verification, since no tool can determine whether a discovered endpoint is authorized to exist.
Is API9 covered in a standard API penetration test?
API9 should be covered in any API penetration test following the current OWASP API Security Top 10, but scope documents vary. Confirm that host discovery and version enumeration are explicitly in scope before the engagement starts.
How often should API inventory be tested?
Test API inventory at least annually and after any major architecture change, acquisition, or new third-party integration. Inventory drift accumulates continuously between assessments under 2026 release cadences.
Does maintaining multiple API versions increase risk?
Yes. Security patches and authorization changes applied to the current version are rarely backported to older live versions, so each additional concurrent version widens the gap between tested and reachable surface.
What is the difference between API9 and general IT asset management?
API9 focuses on API-layer assets: hosts, versions, environments, and specification accuracy. It requires API-specific techniques such as diffing traffic against OpenAPI documents, which generic asset scans do not perform.
Can improper inventory management cause compliance failures?
Yes. PCI DSS, SOC 2, and ISO 27001 assessors require evidence of a current, accurate asset inventory before validating controls on those assets, so an incomplete API inventory produces findings on its own.
How do you find deprecated API endpoints still running in production?
Probe versioned paths directly, review load balancer and API gateway routing rules, and test whether retired code paths still resolve on the backend despite removal from documentation. A 404 on the documented path does not prove the service is gone.
Who owns API inventory in most organizations?
Ownership is usually split between platform engineering, which controls gateways, and individual product teams, which ship endpoints. That split is the structural cause of most API9 findings, and remediation requires naming a single accountable owner.
Get your API inventory tested
Manual discovery and exploitation testing for API9:2023 inventory gaps.
One Last Thing
The highest-severity API9 findings rarely come from obscure experimental endpoints. They come from the first version a company ever shipped, still running in 2026 because nobody wanted to risk breaking a legacy customer integration by turning it off. Before the next release cycle, pull every API version older than eighteen months and get a written answer on who owns the decision to retire it.
Teams that pair inventory validation with API8 security misconfiguration testing close both gaps in one engagement, because misconfigured headers, verbose errors, and default credentials cluster on exactly the forgotten hosts an inventory review uncovers.
Related Guides
Tejas K. Dhokane is a marketing associate at AppSecure Security, driving initiatives across strategy, communication, and brand positioning. He works closely with security and engineering teams to translate technical depth into clear value propositions, build campaigns that resonate with CISOs and risk leaders, and strengthen AppSecure’s presence across digital channels. His work spans content, GTM, messaging architecture, and narrative development supporting AppSecure’s mission to bring disciplined, expert-led security testing to global enterprises.
.webp)
