OWASP Top 10 API security risks: Improper inventory management

Number nine on the Open Worldwide Application Security Project® (OWASP) Top 10 API Security Risks for 2023 is improper inventory management.

With the continued growth in microservices and APIs, security must be built into solutions. That includes structured and consistent documentation to ensure that current API versions have proper security protocols in place and remain patched.

Attack vectors

Improper API inventory management is common and, unfortunately, easy for threat actors to exploit. Older versions of APIs or endpoints that haven’t been updated can enable attackers to gain unauthorized access.

In many cases, these exploits are known and documented, but failure to apply patches or fixes leaves APIs open for attacks.

Security weaknesses

A lack of consistent inventory management leads to unpatched systems. Legacy APIs may also still be active in systems even though they are no longer in use. These systems should be retired, but they often go unaddressed as new systems get put in place. Because they remain active, attackers that find them can often use them as attack vectors.

Business impacts

Improper inventory management can leave the door open for attackers to gain access to sensitive data. There have been examples of full server takeovers. Deprecated endpoints in older API versions may allow attackers to access admin functionality and escalate privileges.

How improper inventory management works

Not only are improper inventory management exploits widespread, but they are also fairly easy for malicious actors to uncover. For example, unless you block access to vulnerable APIs by search engines, finding exposed APIs may be as simple as doing a Google search if you know what you are looking for. The practice, known as Google dorking, can uncover servers, routers, and microservice links.

Once threat actors find unprotected or unpatched APIs, they can use various methods to probe and gain access. Once inside a network, they employ masking and encryption techniques to traverse the network and making it difficult for security teams to uncover.

Real-world examples

There have been several high-profile cyberattacks that might have been prevented with better API inventory management practices.

The Equifax beach that led to the exposure of some 143 million consumer records occurred when threat actors exploited a known vulnerability in an open-source development framework. Because the recommended upgrade to Apache Struct software had not been deployed, attackers were able to uncover database credentials and gain wide access to sensitive information, including names, addresses, Social Security numbers, birth dates, and other customer data. Besides reputational damage, Equifax agreed to pay $575 million in a settlement with the Federal Trade Commission (FTC).

Flaws in Facebook’s API allowed third-party apps to access the private data of millions of users without consent. An attack on Twitter allowed malicious third-party apps to match user names and phone numbers. Each of these attacks may have been prevented with full visibility and control over their APIs.

OWASP details one example where a social media network implemented rate-limiting to block brute force attacks but implemented it as a separate component rather than making it part of the code. If the beta API host runs the same API, rate limiting would be bypassed, allowing brute-force attacks.

Detecting improper inventory management vulnerabilities

API scanning tools can help uncover misconfigured and unprotected API endpoints. Developers should also monitor and log API traffic to see what endpoints are being called and set alerts for when unexpected endpoints or non-public APIs are accessed.

Keeping an inventory of all API keys and tokens issued, you can check to make sure that they are assigned properly to limit access to only those with authorization. API keys that are overly privileged can lead to exposure.

Version control and tracking for APIs is crucial. Regular diffing can reveal undocumented changes that impact security. By comparing two versions and identifying differences, developers can make sure API code repositories, configuration files, and documentation match. Noting any differences, developers can then investigate and resolve discrepancies.

Undocumented changes sometimes get introduced over time and can alter API security postures, opening up vulnerabilities. As such, it is crucial to document changes for future comparison.

Preventing improper inventory management vulnerabilities

For any API, you should only make access available to those that are authorized and authenticated to use the API. This should also apply to API documentation. Developers sometimes ensure APIs are protected but leave documentation unprotected on networks. Once attackers gain access to documentation, they can often reverse engineer processes to gain access.

OWASP recommends several specific actions to mitigate and prevent improper inventory management vulnerabilities, including:

• Documenting the purpose, endpoints, parameters, requests, and responses for each API. Note which versions are in production versus development to avoid additional exposure.
• Map out integrated services, including their role, data flows, and sensitivity levels.
• Describe authentication methods, error handling, rate limiting, CORS policies, and any other relevant details about API functionality.
• Automate documentation generation using open standards and incorporate docs into CI/CD pipelines.
• Implement layered API security for all versions, not just production.
• Avoid using real data with non-production APIs. If unavoidable, secure them equivalently.

When newer versions of APIs include improvements to security, a risk analysis can help assess the impact on other versions. For example, can you backport security enhancements to older versions without breaking compatibility? If not, you will want to migrate clients to the newer version and retire the older API version as soon as possible.