Unsafe Consumption of APIs (Third-party API Security)
A Guide to Unsafe Consumption of APIs (Third-party API Security)
Unsafe consumption of APIs occurs when developers implicitly trust data returned by third-party APIs, applying weaker validation standards to it than they would to direct user input. This creates a gap in third-party API security that attackers can exploit directly.
This gap gives attackers an alternative to attacking a company’s APIs head-on. Instead, an attacker can compromise or manipulate a third-party service that the API depends on, then ride that trusted connection into the target system.
The redirect-following behavior common in HTTP clients makes this risk worse. If a trusted third-party service is breached and starts issuing redirects to an attacker-controlled server, an API that blindly follows redirects will send sensitive data straight to the attacker without any indication something changed.
Key Takeaways
- Unsafe consumption of APIs is ranked #10 in the OWASP API Security Top 10 2023 and occurs when developers implicitly trust data returned by third-party APIs without applying the same validation standards used for direct user input
- APIs become vulnerable when they interact with third parties over unencrypted channels, blindly follow redirects, skip input sanitization on received data, or fail to enforce timeouts and resource limits on third-party responses
- A compromised third-party API can be weaponized as a delivery vector, attackers can inject malicious payloads into third-party data sources that are then executed by the consuming an API’s downstream components, including databases
- Blindly following HTTP redirects from third-party services is a high-risk pattern; if a third-party API is compromised and starts issuing redirects to an attacker-controlled server, sensitive data can be silently exfiltrated
- Prevention requires validating and sanitizing all third-party API responses as rigorously as user input, enforcing TLS on all integrations, maintaining an allowlist of permitted redirect destinations, and assessing the security posture of service providers before integration
Why is it Dangerous
A compromised third-party source becomes a direct injection point into whatever system consumes its data. The resulting harm takes several forms:
- Injection of malicious payloads through compromised third-party data, executed by the consuming an API’s own downstream components, including databases
- Silent data exfiltration through blindly followed redirects to attacker-controlled destinations
- Compromise of the target system without any direct attack on its own API surface
- Weakened validation standards on third-party data creating an easier path into the target than the primary API itself
Typical Manifestations
Unsafe consumption can happen when APIs:
- Communicate with third-party services over unencrypted channels
- Follow HTTP redirects from integrated services without restriction
- Skip input sanitization on data received from third-party sources
- Apply no timeout or resource limit to third-party responses
- Trust third-party data structurally, assuming it isn’t malicious because it didn’t come from a user
Data from a trusted source is still just data, and it needs the same scrutiny as anything else entering the system.
Third-party API Safeguards
Third-party trust must be earned and verified.
- Assess the security posture of service providers before integrating with them
- Enforce TLS on every third-party API interaction
- Validate and sanitize all third-party responses as rigorously as user input
- Maintain an allowlist of permitted redirect destinations rather than following redirects blindly
A third-party API you didn’t build is still part of your attack surface.
