Slide 17 · The Pattern
Three scenarios, one root cause: security was applied to a subset of the attack surface.
The common thread across every API9 incident.
The API9 pattern
Every API9 attack follows the same structure: the organization’s security investment (patching, auth, rate limiting, monitoring) was applied to the known attack surface — the documented, current-version, production API. The attacker found a surface that was not in inventory, and therefore received none of those controls.
🧩
Security investments are scoped to the inventory
Authentication, rate limiting, WAF rules, penetration tests, and SAST scans are all applied to what the team knows about. If an endpoint isn’t in the inventory, it isn’t in scope for any of these controls. The protection boundary is exactly the inventory boundary.
🔎
Attackers enumerate what the team forgot
Path fuzzing with common wordlists, subdomain enumeration via certificate transparency, JavaScript file analysis for old API paths — these are standard recon techniques. Forgotten surfaces are not obscure; they’re predictable (/api/v1/, staging-api., /api/test/).
⚠️
The fix for other vulnerabilities doesn’t help
A BOLA patch in v2 doesn’t fix BOLA in v1. An auth requirement on api.company.com doesn’t protect staging-api.company.com. An endpoint that’s not in the inventory will never receive the patch, the auth check, or the monitoring alert.
The inverse: fixing API9 makes everything else more effective
If the inventory is complete and accurate, every security control applied to documented endpoints is also applied to all active surfaces. A BOLA patch reaches v1 (or v1 is decommissioned). Auth applies to staging (or staging is taken off the internet). The undocumented endpoint gets a security review (or gets deleted). Inventory management is infrastructure for all other security work.