CMU/SEI-2024-SR-004 | SOFTWARE ENGINEERING INSTITUTE | CARNEGIE MELLON UNIVERSITY 14
[DISTRIBUTION STATEMENT A] Approved for public release and unlimited distribution.
Recommendations. The following recommendations apply to this vulnerability.
1. Review old API documentation and repository version histories to discover lost APIs.
2. If there is a versioning scheme to a specific API (e.g., /v1/, /v2/, /v3/, /api?v=1, /api?v=2,
api.company.org), check older versions to ensure they are properly patched or disabled if
they are no longer in use.
3. Document and implement a secure development environment with secure configurations to
prevent pre-production APIs from being exploited.
4. Use automated API discovery scanners or fuzz testing to discover unsupported API paths.
Looking through old API documentation to identify the common API path naming conven-
tions that were used can help in the guess/fuzzing process.
5. Maintain an inventory of all APIs and their associated versions with auto-generated docu-
mentation. This documentation should include, but should not be limited to, all endpoints,
security configurations, third-party software or integrations being used; authentication and
authorization information; and error handling.
6. Ensure that all client-facing APIs communicate through the network API gateway or firewall
to ensure proper security, visibility, and logging.
7. Conduct a risk assessment during the API design process and when new versions of an API
are being deployed. These assessments help determine if older versions should be disabled,
phased out, or maintained for compatibility.
8. Implement detailed digital asset management. Often, APIs are used to retrieve digital assets,
and if those digital assets are not inventoried correctly, then it is more likely that the APIs
used to retrieve these unaccounted assets will also be lost.
2.10 Unsafe Consumption of APIs
Description. Unsafe Consumption of APIs focuses on the consumption of data from third-party
API providers. Security measures on the communication between APIs are often more relaxed
than communication between the API and a client. However, trusting the communication between
an API and another third-party API more than an API to a client can lead to API exploitation if
the third-party API is compromised.
Exploitation of this vulnerability requires the user to have information about the third-party inte-
grations for the specific API. If a third-party API integrated with the API is compromised, it could
lead to sensitive data leaks, denial of service (DoS), data injections, or other attacks.
OWASP’s Security Risk Ranking. Unsafe Consumption of APIs is number 10 on OWASP’s
Top 10 API Security Risks—023 [OWASP 2023, API10:2023].
Example. As illustrated in Figure 5, assume an API gateway accepts all incoming requests for an
API. When it gets a request from a user, the request goes through a sanitization process to ensure
it does not have any malicious attributes like Structured Query Language (SQL) or cross-site
scripting (XSS) injections. However, when the API gateway gets a request from a third-party API,
it does not do the same sanitation checks and instead simply forwards the request to the backend