Every modern application is really a network of applications: your checkout flow calls a payments API, your onboarding flow calls an identity-verification API, your support bot calls an LLM API that in turn calls three more APIs to fetch order status. OWASP formalized the risk this creates in its June 2023 API Security Top 10 update, adding a brand-new, tenth category: API10:2023 – Unsafe Consumption of APIs. The core finding was blunt — teams spend enormous effort validating and sanitizing inbound requests from users, then turn around and blindly trust every byte that comes back from a partner, vendor, or internal microservice API. A malicious or compromised third-party response can carry injection payloads, malicious redirects, or oversized data just as easily as a malicious user request can. This post breaks down what unsafe API consumption actually looks like, how attackers exploit it, and how to catch it before a partner integration becomes your breach vector.
What Is Unsafe Consumption of APIs?
Unsafe consumption of APIs is the practice of processing data returned by another API — a partner, vendor, or even an internal microservice — without applying the same validation, sanitization, and trust boundaries you'd apply to direct user input. OWASP codified this as API10:2023 in its 2023 API Security Top 10, explicitly calling out that developers "tend to trust data received from third-party APIs more than user input," even though that data crosses the exact same trust boundary. In practice this shows up as: deserializing a partner API's JSON response straight into an internal object (mass assignment), following a redirect URL returned by a shipping-rate or currency-conversion API without validating the destination (SSRF), or rendering a vendor's webhook payload into a UI or log without escaping it (injection). The common thread is that the "API" in the name is doing a lot of work to obscure a plain old input-validation failure — one that happens to originate from a system you don't control and often can't see the internals of.
Why Did OWASP Add This as a New Top 10 Category in 2023?
OWASP added it because API sprawl outpaced the validation discipline teams apply to that sprawl. Akamai's State of the Internet research has repeatedly found that API calls make up the large majority of dynamic web traffic — a figure widely cited at 83% — and Gartner has forecast that API abuses would become the most frequent attack vector for enterprise web application data breaches by 2025, up from a minority vector just a few years earlier. Postman's 2023 State of the API Report found that the overwhelming majority of developers now consume APIs built by other teams or outside vendors as a routine part of shipping features, not an exception. Every one of those integrations is a place where a response schema can change, a partner can get compromised, or a DNS hijack can redirect legitimate traffic to an attacker-controlled endpoint — and OWASP's working group concluded that most application security programs had zero controls covering that specific path.
How Do Attackers Exploit Blind Trust in Third-Party API Responses?
Attackers exploit it by compromising, spoofing, or manipulating the upstream API so that your application does the damage to itself. The most common technique is redirect-based Server-Side Request Forgery: an attacker compromises or impersonates a partner API (say, a shipping-rate or currency-exchange service) and returns a 30x redirect or an embedded URL pointing at internal infrastructure — your cloud metadata endpoint, an internal admin panel, or a database management port — and your service, trusting the "API" as a first-class citizen, follows it. This is the same SSRF attack class that was central to the 2019 Capital One breach, which exposed data belonging to more than 100 million customers, and it works just as well when the SSRF trigger comes from a partner API response instead of a crafted user request. Other common paths include mass assignment (a partner's JSON payload is deserialized directly into an internal model, silently overwriting fields like role or isAdmin), stored injection (a vendor webhook payload is logged or rendered without escaping and executes later in an internal dashboard), and denial-of-wallet (a compromised or misbehaving upstream API returns unbounded pagination data that your service dutifully keeps fetching and storing until a cloud bill or database spikes).
What Does an Unsafe Consumption Attack Look Like in Practice?
It looks like an ordinary integration that quietly becomes an attacker's proxy into your network. OWASP's own reference scenario describes a financial application that integrates with a third-party currency-exchange partner: the partner API is compromised, and instead of returning exchange-rate data it returns a redirect to an internal-only endpoint; because the financial app trusts the partner and follows the response without validating the destination, it ends up making a request to internal infrastructure on the attacker's behalf and leaking the response back through the original API call chain. A closely related 2023 pattern played out with LLM-integrated applications: security researchers publicly demonstrated indirect prompt injection, where an AI assistant that fetches content from a third-party API (a webpage summarizer, a search API, a document API) treats attacker-planted instructions embedded in that response as legitimate commands — exfiltrating chat history or triggering unintended actions in connected tools. Both cases share the same root cause: the integration point had no schema enforcement, no destination allowlist, and no separation between "data" and "instructions" coming back from a system outside the application's control.
How Can Security Teams Detect and Prevent Unsafe API Consumption?
Security teams prevent it by treating every inbound API response as untrusted input, full stop. Concretely, that means enforcing strict schema validation (OpenAPI or JSON Schema) on every response before it touches business logic, so an unexpected field or type can't silently flow into a database query or an internal object; allowlisting redirect destinations and disabling automatic redirect-following for any client that calls partner or webhook APIs; setting timeouts and response-size caps to shut down denial-of-wallet loops from a misbehaving upstream; and encoding or escaping any vendor-supplied text before it's logged, rendered, or passed to another system. Just as important is visibility: most organizations can list the APIs they expose but can't produce a complete inventory of the third-party and internal APIs their own services consume, which is exactly the blind spot API10:2023 targets. A 2023 Salt Security report on API security found that the large majority of organizations surveyed had experienced an API security incident in the prior twelve months, and a recurring root cause was integrations nobody on the security team had cataloged, let alone reviewed for trust boundaries.
How Safeguard Helps
Safeguard closes the API10:2023 blind spot by mapping which of your services actually consume which internal and third-party APIs, then tracing whether tainted data returned from those calls is reachable by sensitive sinks — a database write, a redirect follow, an admin-privileged code path — using reachability analysis instead of flat dependency lists. Griffin AI, Safeguard's detection engine, prioritizes the integrations most likely to be exploitable by correlating API response-handling patterns with known SSRF, mass-assignment, and injection techniques, so teams aren't triaging every partner integration equally. SBOM generation and ingestion give you the missing inventory: every SDK, client library, and API dependency your services call out to, cataloged and kept current as code changes. And where a fix is mechanical — adding schema validation, disabling auto-redirect-follow, capping response size — Safeguard opens an auto-fix pull request so the team ships the control instead of writing it from scratch.