Consume third-party APIs safely (OWASP API10:2023)

OWASP API Security Top 10 2023 added API10:2023, Unsafe Consumption of APIs, because developers trust data from the APIs they integrate with more than data from users, and so apply weaker validation, transport security and resource limits to it. The data is still attacker-reachable: a provider can be compromised, can be malicious, or can simply pass through content an attacker planted earlier. OWASP's first example is an enrichment service that stores a SQL injection payload, which runs when the consuming API pulls it into its own database.

A call to another service is therefore two trust problems: the response body is untrusted input, and the connection itself needs the same transport and resource controls you would put on any network boundary. The OWASP page lists five conditions that make an API vulnerable: talking over an unencrypted channel, not validating or sanitizing third-party data, blindly following redirects, not limiting resources used to process responses, and having no timeouts.

Decide what a well-formed response looks like and reject everything else: known fields, exact types, ranges and lengths. A strict schema turns a surprising or malicious payload into a clean rejection instead of a value that flows into a query or a page. In a test with Pydantic 2.14.0, the model below rejected a lowercase symbol, a negative price and an extra field; an accepted value is safe to use because its shape is now known. Apply the same discipline in any language: pydantic in Python, zod in TypeScript, a JSON Schema validator elsewhere.

Validation is not encoding. After the value passes the schema it is still just data; parameterize it into SQL, escape it for HTML and never pass it to a shell. The injection guides at /domains/appsec/secure-coding/injection-parser-boundaries/ cover the sinks.

from pydantic import BaseModel, ConfigDict, Field, ValidationError


class Quote(BaseModel):
    model_config = ConfigDict(extra="forbid")  # unknown fields are rejected
    symbol: str = Field(pattern=r"^[A-Z]{1,5}$")
    price_cents: int = Field(ge=0, le=100_000_000)


def parse_quote(payload: dict) -> Quote:
    # Raises ValidationError on a wrong type, a bad range or an unexpected field.
    return Quote.model_validate(payload)

A missing timeout is the easiest way to turn one slow provider into an outage: requests pile up and workers block. The defaults vary and several are dangerous. Python's requests does not time out at all unless you pass a value: its docs say "By default, requests do not time out unless a timeout value is set explicitly." Go's http.Client has a zero Timeout by default, meaning no limit. httpx defaults to 5 seconds, which is sane but worth setting deliberately. Node's fetch has no total-request timeout of its own; pass an AbortSignal.

Set a connect timeout and a read timeout, and a total budget if the client supports one. Treat a timeout as a failed call: fail the operation, don't silently use partial data.

OWASP's second example is a compromised storage provider that answers with a 308 redirect to an attacker server; an API that follows it resends sensitive data there. The fix from the How To Prevent list is blunt: "Maintain an allowlist of well-known locations integrated APIs may redirect yours to: do not blindly follow redirects." Turn automatic redirects off, inspect the Location, and only follow it when the target host is one you expect. httpx already defaults follow_redirects to False; fetch takes redirect: "manual"; set CheckRedirect in Go.

Redirects are also where client libraries have leaked credentials. Python requests sent the Authorization header to an http URL on a same-host https-to-http redirect (CVE-2018-18074, fixed in 2.20.0) and forwarded the Proxy-Authorization header to the destination on a redirect to HTTPS (CVE-2023-32681, fixed in 2.31.0). Deno's fetch kept the Authorization header when a response redirected to a different domain (CVE-2025-21620, fixed in 2.1.2). The WHATWG Fetch standard requires dropping Authorization and other sensitive headers on a cross-origin redirect, and Go's net/http drops Authorization, Cookie and WWW-Authenticate when a redirect leaves the initial domain. Keep clients patched and prefer handling redirects yourself so you control which headers are resent.

This wrapper, tested on Node.js 26.3.0, sets a timeout with AbortSignal.timeout, refuses to follow a redirect to a host that is not on the allowlist, and streams the body with a byte cap so a huge response can't exhaust memory. In the test it fetched an allowed endpoint and blocked a 302 to attacker.example.

const MAX_BYTES = 1 << 20; // 1 MiB
const ALLOWED_HOSTS = new Set(["api.example.com"]);

export async function getJson(url, { token } = {}) {
  let current = new URL(url);
  for (let hop = 0; hop < 5; hop++) {
    if (!ALLOWED_HOSTS.has(current.hostname)) {
      throw new Error(`host not allowed: ${current.hostname}`);
    }
    const res = await fetch(current, {
      redirect: "manual", // inspect redirects instead of following them
      signal: AbortSignal.timeout(5000),
      headers: token ? { authorization: `Bearer ${token}` } : {},
    });
    if (res.status >= 300 && res.status < 400) {
      const location = res.headers.get("location");
      if (!location) throw new Error("redirect without Location");
      current = new URL(location, current); // re-checked against the allowlist
      continue;
    }
    if (!res.ok) throw new Error(`upstream ${res.status}`);
    return await readCapped(res, MAX_BYTES);
  }
  throw new Error("too many redirects");
}

async function readCapped(res, max) {
  const reader = res.body.getReader();
  const chunks = [];
  let total = 0;
  for (;;) {
    const { done, value } = await reader.read();
    if (done) break;
    total += value.length;
    if (total > max) {
      await reader.cancel();
      throw new Error("response too large");
    }
    chunks.push(value);
  }
  return JSON.parse(Buffer.concat(chunks).toString("utf8"));
}

Pass the parsed JSON through a schema before any code reads a field. With zod's strictObject, an unexpected field fails, a wrong type fails, and the result is typed so downstream code can't read a field that isn't there.

import { z } from "zod";

const Quote = z
  .strictObject({
    symbol: z.string().regex(/^[A-Z]{1,5}$/),
    priceCents: z.number().int().min(0).max(100_000_000),
  });

export function parseQuote(data: unknown) {
  return Quote.parse(data); // throws on unknown fields, wrong types or bad ranges
}

Configure the client once: a real timeout, follow_redirects left off, connection limits, and TLS verification left on (its default). Read the body with a size cap, then validate it with the schema from earlier. In a test on httpx 0.28.1, the client reported a 3-second connect and 5-second read timeout with redirects disabled.

import httpx

from quotes import Quote  # the strict Pydantic model

client = httpx.Client(
    timeout=httpx.Timeout(5.0, connect=3.0),  # never None in production
    follow_redirects=False,                   # inspect redirects yourself
    limits=httpx.Limits(max_connections=20),
    # verify defaults to True; do not set verify=False to "make it work"
)

MAX_BYTES = 1 << 20


def get_quote(url: str, token: str) -> Quote:
    with client.stream("GET", url, headers={"Authorization": f"Bearer {token}"}) as r:
        if r.is_redirect:
            raise RuntimeError(f"unexpected redirect to {r.headers.get('location')}")
        r.raise_for_status()
        body = bytearray()
        for chunk in r.iter_bytes():
            body += chunk
            if len(body) > MAX_BYTES:
                raise RuntimeError("response too large")
    return Quote.model_validate_json(bytes(body))

A regression test against a local server proves the policy holds: a redirect raises instead of being followed, and an oversized body is rejected. Keep it in the suite so a later refactor can't quietly re-enable redirects or drop the cap.

import threading
from http.server import BaseHTTPRequestHandler, HTTPServer

import pytest

from upstream import get_quote


class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        if self.path == "/evil":
            self.send_response(302)
            self.send_header("Location", "https://attacker.example/")
            self.end_headers()
        else:
            self.send_response(404)
            self.end_headers()

    def log_message(self, *args):
        pass


def test_rejects_redirect():
    server = HTTPServer(("127.0.0.1", 0), Handler)
    threading.Thread(target=server.serve_forever, daemon=True).start()
    port = server.server_address[1]
    with pytest.raises(RuntimeError, match="redirect"):
        get_quote(f"http://127.0.0.1:{port}/evil", token="t")
    server.shutdown()

Disabling certificate verification to get past a self-signed or mismatched certificate turns the integration into an open man-in-the-middle. The requests documentation says plainly that with verify=False it "will accept any TLS certificate presented by the server, and will ignore hostname mismatches and/or expired certificates, which will make your application vulnerable to man-in-the-middle (MitM) attacks." The same applies to Node's rejectUnauthorized: false and Go's tls.Config{InsecureSkipVerify: true}. If a provider uses a private CA, add that CA to the trust store (REQUESTS_CA_BUNDLE, NODE_EXTRA_CA_CERTS, a RootCAs pool) rather than turning verification off; /fix/tls-certificate-validation/ shows the fix for each common stack. ASVS 5.0.0 and OWASP API10 both require all API traffic over TLS.

A provider you have a contract with is still outside your trust boundary. Its systems, its other customers and anyone who compromises it can shape the data you receive and the connections it makes back to you. Design so that a bad provider is contained: validate and bound everything it sends, give it only the narrowest credential and scope it needs, and don't let its data drive privileged actions without your own checks.

Keep an inventory of the third-party APIs you call, the credential each uses and the data classification involved, which also answers API9:2023 Improper Inventory Management. When a provider is breached, that inventory tells you which integrations and credentials to rotate.

• One distinct, least-privilege credential per integration, stored in a secrets manager and rotated on a schedule (see /domains/identity-crypto/secrets/leaked-secret-response/).
• Egress controls so a provider URL you call can't be pointed at internal addresses; this is the SSRF overlap, covered in /domains/appsec/secure-features/ssrf-egress-boundaries/.
• Circuit breakers and bulkheads so a failing provider sheds load instead of taking the whole service down.
• Alerting on upstream error rates and latency, which is often the first sign a provider has changed or been compromised.

Retries smooth over transient failures but amplify load if they are naive. Retry only idempotent operations or operations you have made idempotent with an idempotency key, retry only on connection errors and 429 or 5xx responses, use exponential backoff with jitter, and cap the attempts. Honor a Retry-After header when the provider sends one. A retry storm against a struggling provider makes the outage worse for everyone, so pair retries with a circuit breaker. The queue and backpressure guide at /domains/runtime/availability/bounded-background-work/ covers running these calls off the request path.

Consumption runs both ways: providers also call you, through webhooks and callbacks. Treat an inbound webhook as untrusted until proven otherwise. Verify the signature with the provider's shared secret or public key over the raw body, check a timestamp inside the signed payload against a short window to stop replay, and for high-value events fetch the object back from the provider's API by ID rather than trusting the body. The webhook guide at /domains/appsec/secure-features/verify-webhook-deliveries/ has signature-verification code; don't reinvent it here.

Log enough to diagnose a flaky integration (the provider, endpoint, status, latency and a correlation id) but never the Authorization header, the API key, or a response body that may carry personal data. Redact credentials from any request dump, and make sure a client's debug logging is off in production. Monitoring these logs for error-rate and latency changes is often how you first notice a provider problem, which is why the inventory and alerting in the trust-boundary section matter.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. OWASP API Security Top 10 2023: API10:2023 Unsafe Consumption of APIs
2. Requests advanced usage: Timeouts and SSL cert verification. Requests 2.34.2.
3. HTTPX: timeout configuration and defaults
4. Pydantic: strict mode and model validation
5. WHATWG Fetch Standard: HTTP-redirect fetch
6. MDN: AbortSignal.timeout()
7. Go net/http: Client and CheckRedirect
8. NVD: CVE-2018-18074, requests sends Authorization to http URL on redirect
9. NVD: CVE-2023-32681, requests leaks Proxy-Authorization on redirect
10. GitHub Security Advisory GHSA-f27p-cmv8-xhm6: Deno fetch keeps Authorization across domains (CVE-2025-21620)
11. OWASP ASVS 5.0.0, V13 Configuration. Version 5.0.0.
12. OWASP Web Service Security Cheat Sheet

Reference information

Tags

Server-side request forgery (SSRF)Input validation and parsingDenial of service and resource limitsTLSAPI securityThreat modeling

SDLC phase

DesignDevelopment

Role

DevelopersAppSec engineers

ASVS 5.0.0 requirements

v5.0.0-1.3.6 · v5.0.0-13.1.1 · v5.0.0-5.4.1

CAPEC attack patterns

• CAPEC-141 at MITRE
• CAPEC-275 at MITRE

Download this guide as Markdown

Continue exploring