Improper inventory management occurs when an organization fails to maintain an accurate and up-to-date inventory of its API endpoints, versions, and data flows. This vulnerability often leads to security risks, such as exposing deprecated API versions or enabling unauthorized data access.

Modern application architectures, such as microservices and cloud computing, exacerbate the issue by spreading APIs across diverse environments. Without proper visibility, sensitive data might be inadvertently exposed to unauthorized parties or left accessible via outdated or unpatched endpoints. This creates opportunities for attackers to exploit known vulnerabilities, access administrative functionalities, or extract sensitive data.

In this lesson, you will learn how improper inventory management can compromise API security and explore methods to protect your applications. The lesson dives into real-world scenarios where this vulnerability has been exploited and provides strategies to mitigate risks effectively.

Meet Ana, a security consultant tasked with auditing the APIs of a global fitness app, FitSphere. While reviewing their systems, Ana uncovered a significant vulnerability tied to improper inventory management.

She put on her hackhat and started with some reconnasaince. Ana identified that the legacy API and sensitive data flow were indexed by search engines. A simple "Google dorking" query exposed the API documentation online, complete with sample requests and responses.

She wanted to test to see if the deprecated API version (v1.2) was still accessible via an old subdomain. While testing its functionality, she realized this endpoint connected to the production database! FitSphere's developers had forgotten to decommission the API after migrating to a newer version (v2.0).

Ana ran a test query to fetch user data and discovered that the v1.2 endpoint lacked modern security protocols, such as rate limiting and proper authentication. Using basic enumeration techniques, she retrieved the sensitive information of thousands of users. Below is the bash script to enumerate through users:

Ana suspected the API exposes fitness data. She identified that the legacy API and sensitive data flow were indexed by search engines. A simple "Google dorking" query exposed the API documentation online, complete with sample requests and responses. To do this, she did a search for site:fitsphere.xy inurl:api

She then modified her request:

This request results in more JSON but now with sensitive data!

And to add insult to injury, further investigation revealed an unmonitored data flow between FitSphere's API and an external marketing analytics service.

FitSphere’s web app was making API calls from the frontend. Ana used her browser's DevTools to inspect requests (DevTools → Network Tab → Fetch/XHR). She was looking for suspicious requests to third-party domains. Surprise! There was a silent request sending fitness data to marketing-analytics.thirdparty.com.

Let’s break down what happened during Ana's investigation and how each issue contributed to the vulnerability in FitSphere's API environment.

Firstly, the outdated API (v1.2) was still operational and connected to FitSphere's production database. A lack of deprecation and retirement policies allowed this endpoint to remain accessible, exposing sensitive data to unauthorized users. Next, the legacy API version lacked modern security controls such as rate limiting and strong authentication mechanisms. This enabled attackers to retrieve sensitive data using enumeration techniques.

Then there was the hidden integration with the marketing analytics service, which demonstrated how undocumented data flows can result in sensitive information being shared without oversight or encryption.

Vulnerable code example

The code snippet below creates a simple Express-based API to serve user data. The /api/v1.2/users endpoint returns a JSON array of user objects when accessed. The server listens on port 3000 and provides this data to any requester.

The code snippet is vulnerable because it lacks any form of authentication, allowing any requester to access the user data without verifying their identity or permissions. This oversight makes the endpoint an easy target for unauthorized access. Additionally, there is no rate-limiting mechanism implemented, meaning an attacker can send numerous requests to the endpoint to extract data in bulk, such as through enumeration attacks. Lastly, the endpoint exposes full user records, including sensitive information like email addresses, which could have been omitted or minimized to prevent privacy violations.

The code snippet below uses the Flask framework to create an API endpoint /api/v1.2/users that return a list of user objects in JSON format. It runs on port 3000 and is accessible to anyone with the URL.

The vulnerability in the code snippet below arises from the absence of access control measures, which means that any individual with knowledge of the endpoint can retrieve sensitive user data without restriction. The inclusion of sensitive fields such as email addresses in the API response further exacerbates this issue, as this data could be misused or aggregated for malicious purposes. The lack of rate limiting or other request-throttling mechanisms also makes it possible for attackers to programmatically iterate through requests, gathering significant volumes of data in a short amount of time.

The code snippet below defines an array of user objects and serves the data as JSON when the /api/v1.2/users route is accessed. It uses raw PHP without a framework, making it a simple but functional API endpoint.

The PHP code snippet below is vulnerable because it allows any requester to access the user data without verifying their identity. This complete absence of authentication opens the endpoint to abuse and unauthorized access. Although the example data is hardcoded, in real-world scenarios, such a script could expose live data from a database, increasing the severity of the risk. Furthermore, the lack of structured handling mechanisms, such as rate limiting or input validation, makes the API highly susceptible to exploitation by automated tools or attackers attempting to extract bulk data.

The code snippet below uses Spark, a lightweight web framework, to expose the /api/v1.2/users endpoint. The server provides a JSON response containing user data, including names and email addresses.

The Java code snippet below demonstrates vulnerabilities stemming from the absence of authentication and authorization mechanisms. Without these safeguards, anyone can access sensitive user data by simply knowing the endpoint. The exposed data includes personally identifiable information, such as names and email addresses, which should ideally be encrypted or minimized. Furthermore, without proper documentation control or visibility measures, this endpoint could inadvertently be indexed by search engines, making it discoverable to unauthorized parties using simple web queries.

The code snippet below uses the standard net/http package to create an API endpoint /api/v1.2/users. When accessed, the endpoint encodes a list of user objects as JSON and sends it in the response.

The vulnerability in the Go code snippet below lies in its lack of access control mechanisms, which allow anyone to retrieve sensitive user data without authentication. Additionally, the implementation fails to use encryption or secure tokens to prevent unauthorized access to the API. This results in sensitive user information being openly exposed, leaving it vulnerable to malicious actors who could exploit this data for nefarious purposes. The absence of rate limiting further compounds the issue by allowing attackers to programmatically extract data on a large scale.

The following C# snippet demonstrates an API endpoint that exposes user data without proper authentication or access control. This C# API endpoint lacks authentication and authorization, allowing anyone to access the list of users simply by making a GET request. Additionally, it exposes sensitive user information, such as email addresses, which could be exploited in phishing attacks or other malicious activities. Furthermore, there is no rate-limiting, making it susceptible to enumeration attacks where an attacker could repeatedly request data to extract large amounts of information.

As you may have noticed in the section above, the way to mitigate improper inventory management is not a code issue but rather a process and procedure issue. The inventory is there to keep a close eye on what endpoints are available to the public. When the inventory is reviewed, and unnecessary API endpoints are found to be online, they should be removed from the code base.

To systemically address improper inventory management, organizations must adopt a proactive approach to API lifecycle management and enforce robust security controls. This includes creating and maintaining an accurate inventory of all API endpoints, documenting their purposes, and ensuring their secure operation. Deprecating old versions is not enough; they must be fully decommissioned and retired from production to prevent unauthorized access. Additionally, sensitive data flows between APIs and third parties should be carefully monitored and encrypted.

The mitigated code examples below demonstrate how the specific code example above might be mitigated.

The mitigated JavaScript snippet incorporates JWT-based authentication to verify the identity of users accessing the API. It also introduces rate limiting using the express-rate-limit package to prevent abuse from repeated requests. Sensitive fields, such as email addresses, are excluded from the response to ensure data minimization.

However, this does not address improper inventory management. The old API endpoint should be removed from the codebase entirely or properly documented in the API inventory.

The mitigated Python snippet uses Flask extensions for JWT authentication and rate limiting. It adds a login endpoint to generate tokens and requires a valid token for accessing the /api/v1.2/users endpoint. The response data is also sanitized to exclude sensitive fields.

It's important to note that while this mitigates the immediate vulnerability - it does not mitigate the improper inventory management. The API endpoint should also be added to the organization's asset inventory.

The mitigated PHP snippet adds JWT-based authentication to validate users before granting access to the API. It also removes sensitive information, such as email addresses, from the response.

It's important to note that while this mitigates the immediate vulnerability, it does not mitigate the improper inventory management. The API endpoint should also be added to the organization's asset inventory.

The mitigated Java snippet uses middleware to enforce authentication for the /api/v1.2/users endpoint. While it simulates token validation for simplicity, a production-ready implementation would use a JWT library. It also limits the data returned to users, excluding unnecessary fields.

It's important to note that while this mitigates the immediate vulnerability, it does not mitigate the improper inventory management. The API endpoint should also be added to the organization's asset inventory.

The mitigated Go snippet introduces middleware for JWT-based authentication, ensuring that only authorized users can access the /api/v1.2/users endpoint. It also employs rate limiting to prevent abuse and removes sensitive fields from the response.

It's important to note that while this mitigates the immediate vulnerability, it does not mitigate the improper inventory management. The API endpoint should also be added to the organization's asset inventory.

This code adds a few features to the API to mitigate the immediate vulnerabilities. First, it adds authentication and authorization by requiring a valid JWT token using ASP.NET Core's authentication middleware. Secondly, it minimizes the returned data by removing email addresses from the response.

By implementing these fixes, the API is more secure and protects user data from unauthorized access. However, the best practice to fully mitigate Improper Inventory Management is to document, deprecate and remove old API versions from the codebase, rather than fixing them. Maintaining old API versions by fixing them only leads to technical debt.

To expand your knowledge about API security and related topics, check out the following resources:

• OWASP API Security Project: https://owasp.org/API-Security/editions/2023/en/0xa9-improper-inventory-management/
• Improper Inventory Management - 2023 OWASP Top 10 API Security Risks