API9:2023 Improper Inventory Management
Maintaining a complete, up-to-date API inventory with accurate documentation is critical to understanding potential exposure and risk. An outdated or incomplete inventory results in unknown gaps in the API attack surface and makes it difficult to identify older versions of APIs that should be decommissioned. Similarly, inaccurate documentation results in risks such as unknown exposure of sensitive data and makes it difficult to identify vulnerabilities that need to be remediated.
Unknown APIs, referred to as shadow APIs, and forgotten APIs, referred to as zombie APIs, are typically not monitored or protected by security tools. Even known API endpoints may have unknown or undocumented functionality, referred to as shadow parameters. As a result, these APIs and the infrastructure that serves them are often unpatched and vulnerable to attacks.
Capturing the business value of API security
Get the eBookPotential Impact of Improper Inventory Management
Improper Inventory Management is the ninth security threat listed in the OWASP API Security Top 10. By exploiting this vulnerability, attackers can gain unauthorized access to sensitive data, or even gain full server access through old, unpatched or vulnerable versions of APIs.
What Does Improper Inventory Management Look Like?
Research conducted by Salt Security shows a common gap of up to 40% between manually created API documentation (or schema definitions) in the form of Open API Specification (OAS) vs. what is deployed in production APIs. These gaps fall into the following three categories:
1. Shadow API Endpoints — API endpoints that are missing from the OAS or have no OAS at all. In the following example, Salt Security research found an additional 54 endpoints that were not included in the Swager or OAS documentation, and 12 of those undocumented endpoints were exposing sensitive PII data. This sensitive data sharing may be intentional as part of the design or necessary for functionality. As a result, organizations augment with additional security controls such as stronger authentication or encrypted transport to ensure the data is sufficiently protected. In the example, you can see additional HTTP security headers to help protect the data, such as x-frame-options for mitigating cross-frame scripting attacks and x-xss-protection for mitigating cross-site scripting attacks. Some organizations may also mask data being returned to a client to avoid cases where someone intercepts traffic or views data outside of the intended client application. Relying on the client-side code to filter or obscure such sensitive data is typically not appropriate since attackers regularly bypass client-side web application and mobile application code and call APIs directly.
2. Shadow Parameters — API endpoints known to exist but whose API documentation is missing many parameters. As a result, the API documentation does not cover most of the attack surface — in this research, API schema definitions listed just three parameters, but the Salt Security platform identified 102 parameters for the single API endpoint.
3. Parameter Definition Discrepancies — in addition to many missing parameters, data types that lack needed details such as “String” instead of “UUID” or “DateTime” will leave APIs vulnerable. Message filters used by traditional security controls will allow any input through the API to be processed by the backend. These controls rely on a positive security approach and explicitly written rules and policies when enforcing requests against API schema definitions.
Real-world Example: The Optus Breach
In September 2022, media reports indicated that the second largest telecommunications company in Australia, Optus, had suffered a data breach caused by a security vulnerability in one of the company's APIs and resulting in the exposure of 11.2 million customer records, including personal identifiable information. The API targeted by the attackers was used to manage customer accounts, and the vulnerability allowed unauthorized access to sensitive information, including names, addresses, and phone numbers.
The Optus breach highlights the importance of proper API inventory management, specifically the need for regular auditing and risk assessments. When APIs are not properly managed, vulnerabilities can go undetected, and unauthorized access can occur. In this case, the vulnerability was not discovered until it had already been exploited, putting thousands of customers' personal information at risk.
Adding to the severe reputational damage caused by the high-profile breach, Optus has reportedly put aside A$140 million to cover the costs of the incident.
Why Existing Tools Can’t Protect You Against Improper Inventory Management
Traditional security controls like WAFs and API gateways lack capabilities to continuously discover APIs at a granular level and monitor them for changes. These security controls only know what they are configured for, requiring API schema definitions to be imported to gain a view of the API environment. If documentation is missing or inaccurate, as is often the case for many security teams, these traditional security controls will have an inaccurate view of the API environment.
How to Protect Your APIs Against Improper Inventory Management
API security solutions must be able to analyze all API traffic and continuously discover APIs. Discovery must include the ability to identify all host addresses, API endpoints, HTTP methods, API parameters, and their data types including the identification and classification of sensitive data. These solutions must provide discovery on an ongoing basis to maintain an up-to-date catalog of the API environment and accurate API documentation even as new APIs are introduced and updates are made to existing APIs.
To learn more about how Salt can help defend your organization from API risks, you can connect with a rep or schedule a personalized demo.
