Unsafe Consumption of APIs
OWASP API Security Top 10 · API10:2023
Developers apply scepticism to user input and then extend implicit trust to responses from partner and third-party APIs. That trust is misplaced: an upstream service can be compromised, can be redirected, or can simply return something unexpected. Data arriving from another API deserves the same validation as data arriving from a browser.
How it shows up in the real world
- Rendering or storing a third-party response without validation, carrying an injection payload into your system.
- Following redirects from an upstream integration to an attacker-controlled host.
- Trusting an upstream service's authorization decision instead of making your own.
- A malformed or oversized upstream response exhausting memory or crashing a parser.
How to mitigate it
- Validate upstream responses against a strict schema and treat them as untrusted input.
- Require TLS with certificate validation for integrations, and do not blindly follow redirects.
- Apply timeouts, size limits, and circuit breakers to outbound calls.
- Make your own authorization decisions rather than inheriting an upstream verdict.
- Isolate and monitor integration processing so an upstream compromise is contained.
Practice this topic
Test your knowledge of Unsafe Consumption of APIs with exam-style practice questions.
Rest of the API 2023 list
API1:2023Broken Object Level Authorization
The most common and most damaging API flaw. Endpoints take an object identifier from the caller and act on that object without confirming the caller is entitled to it. Because APIs expose identifiers as a matter of design, the entire dataset is often reachable by iterating a value, and the requests look completely legitimate in logs.
API2:2023Broken Authentication
Authentication mechanisms in APIs are often implemented per service and per endpoint, which is exactly the condition in which inconsistencies appear. Token validation may be incomplete, credential endpoints may be unthrottled, and machine-to-machine keys tend to be long-lived, broadly scoped, and rarely rotated.
API3:2023Broken Object Property Level Authorization
Even when access to an object is correct, access to individual fields may not be. This covers both directions: returning properties the caller should not see, and accepting properties the caller should not be able to set. It merges what earlier editions treated separately as excessive data exposure and mass assignment.
API4:2023Unrestricted Resource Consumption
Every API request consumes CPU, memory, storage, bandwidth, and often paid third-party calls. Without limits, a caller can degrade availability or run up costs simply by asking for a great deal, and the requests need not be malformed. Expensive operations such as search, export, report generation, and anything that fans out to other services are the usual pressure points.
API5:2023Broken Function Level Authorization
Where API1 is about which records a caller may touch, this is about which operations they may invoke. Administrative and privileged functions are frequently protected only by being undocumented or absent from the client, so a caller who guesses or observes the route reaches them. Changing an HTTP method on a known path is often enough.
API6:2023Unrestricted Access to Sensitive Business Flows
Some abuse involves no technical vulnerability at all: the API works exactly as designed, but automation lets one actor use a business flow at a scale the business never anticipated. Ticket purchasing, inventory reservation, promotional codes, and account creation are all technically valid operations that cause real harm when performed thousands of times by a script.
API7:2023Server Side Request Forgery
When an API accepts a URL and fetches it, the caller gains partial use of the server's network position. That position is usually far more privileged than the caller's own: internal services, cloud metadata endpoints, and administrative interfaces are reachable from inside. Features like webhooks, link previews, file import from URL, and PDF rendering are the usual entry points.
API8:2023Security Misconfiguration
APIs inherit misconfiguration risk from the whole stack they run on — gateway, framework, container, orchestrator, and cloud platform — and add some of their own, such as permissive cross-origin policies, verbose error output, and unnecessary HTTP methods left enabled. The gateway is a particular concern because a single permissive rule there applies to every service behind it.
API9:2023Improper Inventory Management
You cannot protect what you do not know you are running. Organisations accumulate old API versions, staging deployments, forgotten integrations, and undocumented internal services, all of which stay reachable and stop receiving patches and review. Old versions are especially dangerous because they often predate the fixes and controls applied to the current one.