API9:2023 — Improper Inventory Management

Slide 8 · Context

“We fixed it” means nothing if the old version still answers.

API9 is the risk that security investments are undermined by the attack surface they didn’t cover.

Why it’s #9

API9 scores lower than the other risks in individual exploitability — finding an old API version requires discovery work. But its prevalence is high: in large organizations, undocumented endpoints and forgotten versions are nearly universal. And its impact compounds other risks: an old version with SQL injection that was patched in v2 creates a permanent critical vulnerability until v1 is shut down.

Without inventory management

Security team patches BOLA in v2

v1 (same BOLA) still runs, unknown to security team

Attacker finds v1 through path enumeration

Exploits BOLA on v1 — the “patched” vulnerability

Post-incident: team discovers v1 was never decommissioned

With inventory management

Complete API inventory shows all active versions

BOLA patch applied to all versions simultaneously

v1 has a deprecation date; traffic monitored

v1 decommissioned once traffic reaches zero

Security team knows exactly what attack surface exists

API9 amplifies every other risk

API9 doesn’t create vulnerabilities on its own — it preserves them. Every vulnerability that was patched in v2 but exists in a still-running v1 is an API9 problem. This makes inventory management a force multiplier for all other API security work: patching v2 is only effective if v1 is also patched or decommissioned.

← Back How do attacks work? →