Home / Knowledge hub / Unsafe consumption of APIs
Knowledge hub
Unsafe consumption of APIs
Trusting data from a partner's API without checking it like any other input.
What it means
Unsafe consumption of APIs happens when your application takes data from another service, such as a payment provider, a partner feed or an enrichment tool, and treats it as safe. The data arrives from a system you chose, so it feels trusted, and it skips the checks you give user input. The trust is usually unspoken, and it is rarely written into any code review checklist.
OWASP lists it as a top API risk. The point is that a partner's API can be wrong, compromised or tricked into returning something hostile, and your application then does what the response says. Treat the supplier as one more source of untrusted data, however reliable it has been.
Why it matters
If an attacker controls a record on the other side, such as a name field, a redirect address or a file link, the poisoned value travels into your system through a channel you trust. It can end as injection in your database, a script in your pages, or a request your server makes to an address of the attacker's choosing. The result is that someone else's weakness becomes your problem.
A breach at a supplier can therefore become your incident. You may also follow redirects blindly or accept oversized responses, which brings cost and downtime even without any malicious intent from the supplier. Reviewing the responses you accept is part of managing that supplier risk.
How it shows up
You meet it in webhooks, import tools, sign-in with another provider, shipping and tax lookups, and any feature that stores or shows data fetched from outside. Common mistakes are skipping validation of the response, following redirects without limits, using no timeouts, and passing the data straight to a query or a template.
Treat every response like untrusted input. Check its shape and values against a schema, encode on output, set timeouts and size limits, restrict where redirects may lead, and use TLS to the supplier. Review what happens when the supplier returns something unexpected, not only what it should return.
Questions people ask
Unsafe consumption of APIs, answered
Why shouldn't we trust a partner's API?
Not because the partner is dishonest, but because their systems can be breached, buggy, or carrying data that came from their own users.
Whatever reaches you may have been shaped by someone you never met.
What checks should we apply to API responses?
Validate structure and types against a schema, check values are within expected ranges, encode data when it is displayed or placed into a query, and cap the size.
These are the checks you already use on user input.
Is this the same as SSRF?
No, but they can combine. Unsafe consumption is about trusting the data that comes back. SSRF is about making your server fetch an address chosen by someone else.
A redirect or link in a partner response can lead to SSRF if you follow it blindly.
Do contracts with suppliers solve this?
They help with accountability, but they do not protect your code from a hostile value.
Technical checks on every response are still needed. Ask for a security summary from key suppliers too.
How do we test for it?
Replace the supplier with a test service that returns unexpected values: long strings, script fragments, odd redirects and slow replies. See whether your app copes.
Check that nothing returned is used directly in a query or a page.
Related
Terms that sit next to this one
Untrusted input
Anything that arrived from outside your own code, and is therefore suspect.
Input validation
Checking that what arrives is the shape and range you expected.
API schema validation
Rejecting requests that do not match the format the API says it accepts.
Vendor risk management
Judging and monitoring the security of the suppliers your business relies on.
Supply chain attack
Reaching you through a library, a build tool or a vendor you trust.
What do you do with a partner's reply?
Data from a partner can carry a payload. We test how your app handles unexpected responses and report only what we proved, with the request, the response and, in white-box mode, the line of code. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.