What is API10 unsafe consumption of APIs, and how do you fix it?

API10:2023, Unsafe Consumption of APIs, is the OWASP risk where your API trusts data and behavior from third party APIs more than it trusts user input. The fix is to treat every upstream response as untrusted: validate it, use TLS, restrict redirects and limit resources.

Why do developers trust upstream APIs?

OWASP says developers tend to trust data received from third party APIs more than user input, especially when the provider is well known. That trust leads to weaker standards for transport security, authentication and authorization, and input validation and sanitization. An attacker who cannot reach your API directly may be able to reach something your API calls.

How do you know if your API is vulnerable?

OWASP lists signs. The API might be vulnerable if it:

• talks to other APIs over an unencrypted channel
• does not validate and sanitize data gathered from other APIs before processing it or passing it downstream
• blindly follows redirections
• does not limit the resources available to process third party responses
• does not implement timeouts for interactions with third party services

OWASP rates exploitability as easy, prevalence as common and detectability as average, with severe technical impact. It adds that exploiting this issue requires identifying and compromising the other services your API integrates with, which is usually not trivial.

What do the attacks look like?

OWASP gives three scenarios, which are worth reading in the original. In the first, an enrichment service returns stored data containing a database payload, and the API writes that data into its own database without cleaning it. In the second, a compromised third party responds to a request with a 308 redirect, and the API follows it, replaying the same request, with sensitive data in the body, to the attacker's server. In the third, a repository name containing a database payload is processed by an integration that builds a query from it.

The common thread: the dangerous input arrived through a channel the developer thought was safe.

A constructed example

A delivery app calls a mapping service to turn addresses into coordinates, and stores the service's formatted address text. The mapping vendor has a bug that lets a business owner insert arbitrary text into their listing, which flows into the response. The delivery app prints that text into an email template without escaping. The vendor is reputable, yet the app is now rendering attacker controlled text. Escaping output and validating field formats on arrival would have contained it.

How to fix it

OWASP's prevention advice is short. Assess the security posture of providers when you evaluate them. Make sure all interactions use TLS. Validate and sanitize data from integrated APIs before use. Keep an allowlist of well known locations your API may be redirected to, and do not follow redirects blindly.

Add two practical measures. Set connect and read timeouts and a maximum response size, so a slow or huge reply cannot starve your service. And log which third party each piece of stored data came from, so that when a vendor reports a breach you can find affected records.

How to check or apply this

1. List every outbound API call your service makes, from code and from configuration.
2. Confirm each uses TLS and verifies certificates.
3. Define a schema for each response and reject what does not match.
4. Treat strings from upstream as untrusted when writing to databases, templates and logs.
5. Disable automatic redirects or restrict them to an allowlist.
6. Set timeouts and size limits.
7. Record the source of third party data stored in your systems.

Quick check

Sources

• OWASP API Security Top 10 2023, API10 Unsafe Consumption of APIs

Last reviewed: 18 October 2026.