>myctrl.tools
Preferences
Under active development — Content is continuously updated and improved

API9—Improper Inventory Management

>Control Description

APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. A proper inventory of hosts and deployed API versions also play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints. The API is vulnerable when the purpose of an API host is unclear, there is no documentation or the documentation is not updated, there is no retirement plan for each API version, and the hosts inventory is missing. Additionally, there is risk when there is no visibility on how data is shared with third parties, including what sensitive data is shared, there is no business justification for the data flow, and there is no inventory or visibility of the data flows.

>Prevention & Mitigation Strategies

  1. 1.Inventory all API hosts and document the API environment (e.g. production, staging, test, development), who should have network access to the host (e.g. public, internal, partners), and the API version.
  2. 2.Inventory integrated services and document their role in the system, what data is exchanged (data flow), and its sensitivity.
  3. 3.Document all aspects of your API including authentication, errors, redirects, rate limiting, CORS policy, and endpoints with their parameters, requests, and responses.
  4. 4.Generate documentation automatically by adopting open standards. Include the documentation build in your CI/CD pipeline.
  5. 5.Make API documentation available only to those authorized to use the API.
  6. 6.Use external protection measures such as API security specific solutions for all exposed versions of your APIs, not just for the current production version.
  7. 7.Avoid using production data with non-production API deployments. If this is unavoidable, these endpoints should get the same security treatment as the production ones.
  8. 8.When newer versions of APIs include security improvements, perform a risk analysis to inform the mitigation actions required for the older versions.

>Attack Scenarios

#1Beta API missing rate limiting

A social network implemented a rate-limiting mechanism that blocks attackers from using brute force to guess reset password tokens. This mechanism was not implemented as part of the API code itself, but in a separate component between the client and the official API (api.socialnetwork.owasp.org). A researcher found a beta API host (beta.api.socialnetwork.owasp.org) that runs the same API but without the rate limiting mechanism. The researcher was able to reset the password of any user by using a simple brute force to guess the 6-digit token.

#2Third-party data sharing abuse

A social network allowed a third-party developer application to access user data. However, there were no proper controls limiting the scope of data accessible through the API. The malicious app gained access to sensitive information of 50 million users beyond the 270,000 who explicitly consented. The company behind the app sold the data for malicious purposes.

>Related CWEs

CWE-1059

>References

Ask AI

Configure your API key to use AI features.