Improper Inventory Management

What Is Improper Inventory Management?

A security control only covers the endpoints you know are running. Old API versions, undocumented endpoints and forgotten hosts stay deployed outside that picture, still serving the unguarded code they always did. You'll get a 401 from the current version, change one URL segment from v2 to v1, and get 200 with a customer's name, email and home address, then walk the account ids into a bulk list. The fix retires the old version so every path under it returns 410 Gone. Deprecating in the docs is not retirement.

What You'll Learn in Improper Inventory Management

• Recognize improper inventory management: old, undocumented, or non-production API versions and hosts left running and reachable, outside the controls the current version enforces
• Understand that a new control (an auth gateway, a check) only covers the versions mounted behind it, so an older version left in production serves the pre-control code to anyone
• See how changing one URL segment from the current version to a deprecated one reaches a forgotten build, and how an unauthenticated endpoint turns into bulk data exposure through simple enumeration
• Distinguish it from broken object level authorization (a missing per-record ownership check inside an authenticated endpoint) and from excessive data exposure (over-returning fields); here the whole version runs unauthenticated because it was never retired
• Apply the fix: retire unsupported versions so they return 410 Gone and come out of production, and maintain an inventory of every deployed version, environment, and host so nothing runs unwatched

Improper Inventory Management — Training Steps

1. An old version, still listed

   Emberline is a home solar and energy app: customers link their panels and battery, and the app reads their account from Emberline's API. Today Bob is targeting Emberline. He has no account and no token; he just wants a list of customers and where they live, to sell on. He starts on Emberline's public developer docs to learn the API.

2. Deprecated, not gone

   The docs describe two API versions. Bob reads how each one is labelled, and one label catches his eye.

3. Ask the current version

   First Bob calls the current version the way the docs describe: he asks for one account by its id, using the example id from the reference. He has no token, so this is the unauthenticated case. If the gateway is doing its job, it should refuse him.

4. The gateway refuses

   The current version did exactly what it should.

5. Change one segment

   Bob sends the same request, still with no token, and changes only one thing: the version in the URL, from v2 to v1 , the deprecated build. Everything else is identical. If the old version is truly gone, this should reach nothing.

6. The forgotten version answers

   The same request the gateway just refused came back with data.

7. Walk the accounts

   One record is a warning. Because v1 asks for no token at all, nothing stops Bob from walking account ids. He keeps the version on v1 and changes the id to the next customer.

8. Every customer, at scale

   Another id, another real customer.

9. Knowledge check

   You just watched an attacker with no account read customer records by switching the version in the URL. Lock in why.

10. The alert lands

    You own Emberline's API gateway and the lifecycle of every API version behind it. Overnight, monitoring flagged thousands of unauthenticated reads on the old /v1 accounts endpoint, from a single address, walking account ids in sequence. Security operations has emailed you.