Back

API10: Unsafe Consumption of APIs - Overview

Table of Contents

What is Unsafe Consumption of APIs?

Unsafe Consumption of APIs occurs when an application blindly trusts data received from third-party or upstream APIs and processes it without the same validation, sanitization, and transport controls it applies to direct user input. Developers instinctively trust data returned by a partner API, an identity provider, a payment processor, or an internal microservice far more than data typed by an end user — and that misplaced trust is exactly what makes the integration a soft target.

The threat is a shift in perspective. Instead of attacking your API directly, an attacker attacks (or impersonates, or sits in the middle of) a service that your API consumes. If they can compromise that upstream service, tamper with its responses in transit, or trick your API into calling an attacker-controlled endpoint, then their malicious payload arrives pre-trusted — flowing straight into your database, your templates, your deserializers, and your business logic.

Core Concept

Safe Consumption of a Third-Party API
  ✓ Validate and schema-check every field of the response
  ✓ Sanitize/encode upstream data before storage or rendering
  ✓ Treat response codes and flags as untrusted claims
  ✓ Enforce TLS with certificate validation on the integration
  ✓ Set timeouts and response-size limits
  ✓ Do not blindly follow redirects to new hosts

Unsafe Consumption of a Third-Party API
  ✗ Blindly trust the upstream response body
  ✗ No validation because "it came from our partner"
  ✗ Assume a 200 OK or {"status":"success"} is authentic
  ✗ Plain HTTP, or TLS with verification disabled
  ✗ Follow arbitrary redirects to arbitrary hosts
  ✗ Pass the response straight into SQL / HTML / a deserializer
Normal flow:
  Your API  --HTTPS-->  Partner API      returns {"name": "Alice"}
  Your API  stores/renders "Alice"        Result: works fine

Attack flow (partner compromised or MITM):
  Your API  --HTTP-->   Partner API (evil) returns {"name": "'); DROP TABLE users;--"}
  Your API  concatenates into SQL          Result: injection in YOUR database
                                           via data YOUR code trusted

Why It's Critical for APIs

Modern APIs are rarely standalone. They are woven into a mesh of upstream dependencies, and each integration expands the trust boundary:

Why Does This Matter?

The Business Impact

The Technical Impact

Technical Context

API10 is fundamentally about a broken assumption: "the other side of the integration is safe." Four recurring weaknesses turn that assumption into an exploitable vulnerability.

1. Blind Trust in Third-Party Responses

The most common form: response data is consumed with zero validation because of where it came from.

# VULNERABLE - trusts CRM data directly in a query
crm = requests.get('https://crm-partner.com/api/users').json()
for user in crm['users']:
    # If the partner is compromised, name/email carry the payload
    db.execute(f"INSERT INTO users (name, email) "
               f"VALUES ('{user['name']}', '{user['email']}')")

A compromised partner returning "'); DROP TABLE users;--" in a name field now runs SQL inside your database. The same pattern produces stored XSS when the field is later rendered in an admin dashboard.

2. Insecure Integration Transport

Integrations are frequently configured with plain HTTP, or with TLS certificate verification disabled "to make it work" during development — and that setting ships to production. Either mistake lets a network attacker (MITM on a proxy, cloud peering link, or hostile Wi-Fi in a hybrid setup) read and rewrite responses at will.

// VULNERABLE - TLS verification turned off
const agent = new https.Agent({ rejectUnauthorized: false });
const res = await axios.get('https://partner.example/data', { httpsAgent: agent });
// Any MITM can now impersonate the partner and inject a payload

3. Blindly Following Redirects

HTTP clients follow 3xx redirects by default. If the upstream (or an attacker who controls it) returns a redirect, your API happily makes a second request to a destination you never vetted — potentially an internal address (turning API10 into SSRF) or an attacker-controlled host that serves the malicious body.

# Partner responds 302 -> http://169.254.169.254/latest/meta-data/
# Default client follows it and returns cloud metadata to the attacker
requests.get(partner_url)          # allow_redirects=True by default

4. No Input Validation on Upstream Data

Even honest partners send malformed, oversized, or unexpected data. Without a schema, a type check, or a size cap, a single bad response can crash a worker (DoS), overwrite fields, or smuggle unexpected keys into your objects (mass-assignment via upstream data). Identity-provider claims (name, email, picture) are a favorite: they feel authoritative but are attacker-influenceable and must be treated as untrusted.

Common Unsafe-Consumption Scenarios

Payment Confirmation Trust

# VULNERABLE - trusts a client-relayed / interceptable "success" flag
resp = requests.post('https://pay-partner.com/charge', json=req.json)
if resp.json().get('status') == 'success':
    grant_access(req.json['user_id'])   # forgeable without a signature check

Webhook Ingestion

# VULNERABLE - anyone who knows the URL can POST a fake event
@app.post('/webhooks/orders')
def ingest():
    event = request.json          # no signature verification
    fulfill_order(event['order_id'])   # attacker-controlled

Identity Provider Claims Used Unsanitized

# VULNERABLE - IdP-provided display name rendered into HTML
profile = oidc_userinfo(token)    # third-party claims
return f"<h1>Welcome {profile['name']}</h1>"   # stored/reflected XSS

Real-World Impact

The most damaging real-world cases of unsafely consuming a third party are the Magecart supply-chain attacks of 2018, where victims trusted content and services delivered by a compromised third party. These are well-documented and publicly reported.

Case Study 1: British Airways (2018)

What happened: Impact:

Case Study 2: Ticketmaster UK (2018)

What happened: Impact:

Case Study 3: Newegg (2018)

What happened: Impact:

Note on attribution: These are client-side supply-chain compromises, but they illustrate the exact API10 failure mode — a system trusting a third party it does not control. The same trust failure applies server-to-server when your API consumes a partner API, IdP, or webhook. Where a specific CVE or precise figure could not be verified, this lesson deliberately avoids inventing one.

Prevalence and Statistics

API10:2023 was introduced in the OWASP API Security Top 10 specifically because integrations were a fast-growing and under-defended attack surface. Unlike older categories, it has comparatively few "named" CVEs of its own — the risk usually manifests through another vulnerability class (injection, XSS, SSRF, deserialization) that the upstream data triggers. Rather than cite invented percentages, here is what is well-supported:

Accuracy note: The API07 reference page cites specific vulnerability percentages. For API10 no equally authoritative, verifiable dataset exists, so this page intentionally describes prevalence qualitatively instead of fabricating precise figures.

Common Misunderstandings

Myth 1: "It's our partner's API, so the data is safe"

Reality: You do not control the partner's security. A breached partner, a rogue insider, or an attacker who can MITM the connection all produce a "trusted" response containing hostile data. Validate upstream data with the same rigor as user input.

Myth 2: "We use HTTPS, so responses can't be tampered with"

Reality: HTTPS only helps if certificate verification is enabled and enforced. Many integrations disable verification or fall back to HTTP. And HTTPS does nothing about a genuinely compromised upstream — the malicious data is authentically TLS-protected on its way to you.

Myth 3: "A 200 OK / status:success response means it really succeeded"

Reality: Status codes and JSON flags are unauthenticated claims. Without a cryptographic signature (e.g., a webhook HMAC) or a server-to-server verification call, they are trivially forgeable by anyone who can influence the response.

Myth 4: "We only read the data, we don't execute it"

Reality: "Reading" data into a SQL query, an HTML template, an XML parser, or a deserializer is execution in disguise. Passive consumption still leads to injection, XSS, XXE, and RCE.

Myth 5: "Following redirects is convenient and harmless"

Reality: An upstream redirect can point at internal infrastructure (SSRF), cloud metadata, or an attacker host serving a poisoned body. Disable automatic redirects on integration clients, or re-validate every hop.

Myth 6: "Schema validation is only for user-facing endpoints"

Reality: Upstream responses are exactly where a strict schema pays off — it rejects malformed, oversized, and unexpected data before it reaches your logic, and it neutralizes many DoS and mass-assignment tricks.

How API10 Relates to Other Risks

| Aspect | API10 Unsafe Consumption | API07 SSRF | Injection (A03) |

|--------|--------------------------|------------|-----------------|

| Trigger source | Data from a trusted third party | User-supplied URL fetched by server | User-supplied data in a sink |

| Root cause | Misplaced trust in upstream | Missing URL validation | Missing input sanitization |

| Typical outcome | Injection/XSS/RCE via partner | Internal access, metadata theft | Data theft, tampering |

| Fix | Validate upstream like user input | Allowlist + block internal ranges | Parameterize + encode |

Unsafe-Consumption Attack Chain

1. Identify an Integration
   ↓
   Find where the app consumes a third-party API, webhook, or IdP

2. Gain Influence Over the Response
   ↓
   Compromise the partner, MITM a weak TLS/HTTP link,
   or forge a webhook / redirect

3. Inject a Trusted Payload
   ↓
   Return data that the app consumes without validation
   (SQL, HTML, XML, serialized object, internal URL)

4. Trigger the Sink
   ↓
   App stores, renders, parses, deserializes, or re-requests it
   → injection / XSS / XXE / RCE / SSRF / DoS

5. Expand Impact
   ↓
   Poison every customer of the compromised partner at once

Key Takeaways

  1. Trust boundaries include your integrations — upstream data is untrusted input.
  2. Validate and schema-check every third-party response before using it.
  3. Enforce TLS with certificate verification on every integration call.
  4. Do not blindly follow redirects from upstream services.
  5. Verify success claims cryptographically (signatures, HMAC, server-side checks).
  6. Set timeouts and response-size limits to blunt DoS from bad responses.
  7. Assume any partner can be compromised and design so the blast radius is contained.

How to Identify if You're Vulnerable

Ask these questions about your API:

If you consume third-party data and answered "no" to the validation questions, you are likely vulnerable to API10.

Next Steps