OWASP API Top 10 API10 Unsafe Consumption of APIs Guide: Trusting Third-Party APIs Safely

Most API security effort points inwards at callers, yet the data your own services pull from partners, enrichment providers and SaaS platforms is often trusted more than user input and checked far less. OWASP API10:2023 Unsafe Consumption of APIs names that blind spot. This guide treats API10 as a requirement set: what the OWASP text asks for, how to implement each requirement in common HTTP clients, what identity controls the outbound side needs, what evidence an assessor should collect, and how it maps to OWASP ASVS 5.0, NIST SP 800-53, NIST CSF 2.0, ISO/IEC 27001:2022 and CIS Controls. It is for API developers, platform engineers and third-party risk and AppSec assessors. For the whole list see Top 10 API Security Risks.

Key takeaways

• Third-party responses are untrusted input. OWASP's core observation is that developers trust data from other APIs, especially well-known ones, more than user input and so validate it less.
• Five conditions define the weakness. Unencrypted channels, missing validation and sanitisation, blindly followed redirects, no resource limits on responses and no timeouts are each testable.
• HTTP client defaults work against you. Python Requests follows redirects for every method except HEAD and applies no timeout unless one is set; the Fetch API follows redirects by default.
• Every integration is a non-human identity. The keys and tokens your services use to call partners need their own scope, vaulting, rotation and owner, because a compromised provider or a leaked credential turns the integration against you.
• The provider's posture is part of your attack surface. OWASP asks you to assess a provider's API security before you depend on it, which ties API10 to supplier risk management, not only to code review.

What it is and who it applies to

API10:2023 Unsafe Consumption of APIs is the tenth entry in the OWASP API Security Top 10 2023. OWASP rates exploitability Easy, prevalence Common, detectability Average and technical impact Severe, with business impact specific to each organisation. To exploit it, an attacker has to identify services the target integrates with and, eventually, compromise them or plant data in them. The impact depends on what the consuming API does with the data it pulls: OWASP lists sensitive information exposure, many kinds of injection and denial of service. The entry cites CWE-20 Improper Input Validation, CWE-200 Exposure of Sensitive Information to an Unauthorized Actor and CWE-319 Cleartext Transmission of Sensitive Information.

API10 applies wherever your code is the client of someone else's API:

• Enrichment and lookup services: address, company, credit, geolocation or threat intelligence APIs whose results are stored or displayed.
• Payment, identity and messaging providers: responses and callbacks that drive business decisions.
• SaaS and source control integrations: repository names, CRM fields, ticket text and file metadata pulled into your systems. OWASP's third scenario is a git repository named with a SQL injection string.
• Inbound webhooks: a partner pushes data to you rather than you pulling it; the payload deserves the same distrust. See the Webhook Secrets Security Guide.
• AI agents and LLM tools: an agent that calls APIs or MCP servers and passes results into its context is consuming APIs too, and results can carry instructions as well as data. See the AI Agent Tool and Plugin Security Guide.

API10 is distinct from API7 Server Side Request Forgery: in SSRF the attacker controls which URL your server fetches; in API10 the destination is legitimate but its response, or its redirect, is hostile. Both are mitigated partly by outbound allowlists. See the SSRF Prevention Guide. If your own API issues redirects rather than following them, see the Open Redirect Guide.

Structure and key requirements

The OWASP entry lists five conditions under "Is the API Vulnerable?", three attack scenarios and four prevention items. The table converts each condition into a requirement, a concrete implementation and the matching ASVS 5.0 verification requirement.

The three scenarios as test cases

• Stored injection via an enrichment provider: an attacker registers a business at a third-party service with an SQL injection payload in its record, then makes your API look it up. Test by seeding a sandbox provider with injection strings and confirming they are stored as inert data.
• Redirect of sensitive data: a compromised provider answers a POST of genome data with 308 Permanent Redirect to an attacker host, and the client repeats the request, body included, to the new location. A 308, like a 307, tells the client to keep the method and body. Test with a stub provider returning 307 and 308 to a canary host.
• Injection through metadata: a repository named '; drop db;-- reaches a query built by string concatenation. Test with hostile names, descriptions and filenames from every integration.

Choosing where to enforce

Small teams get most of the value from one hardened client wrapper (timeouts, redirects off, TLS verification on, size cap) and schema validation on the two or three integrations whose data is persisted. Large organisations should add an egress gateway so that the allowlist, logs and credentials are managed centrally, and require every new integration to register a destination, owner and data classification before traffic is allowed.

Identity and NHI requirements

Every outbound integration authenticates with something: an API key, an OAuth client credential, a certificate or a signed request. Those are non-human identities, and API10 controls fail quietly when they are unmanaged.

• One credential per integration and environment: do not share a provider key across services or across production and test. It keeps blast radius and revocation small. See the API Key Management Guide.
• Prefer short-lived tokens: where the provider supports OAuth client credentials or workload identity federation, use them instead of static keys. See the Machine-to-Machine OAuth (Client Credentials) Guide.
• Vault and inject: keep provider secrets in a secrets manager (ASVS V13.3.1) or let the egress gateway inject them, so application code and logs never hold them. See the Secrets Management Guide.
• Do not send credentials to redirect targets: with redirects disabled by default, an outbound credential cannot be replayed to an attacker-chosen host by a compromised provider.
• Least scope on both sides: request only the scopes you need from the provider, and limit what the integration identity can do inside your own systems with the data it receives.
• Plan for provider compromise: integration credentials concentrated at a vendor are a target. In the Salesloft Drift Breach 2025, tokens held for one chatbot integration let an attacker act as an application hundreds of customers had already authorised, so MFA and SSO never came into play. Keep a revocation and rotation runbook per integration. See the OAuth Token Theft Incident Playbook.
• Agents consuming business records: in SalesBleed Salesforce Agentforce 2026, records created through a public web form reached an agent as trusted context and carried instructions. Data pulled from any API into an agent's context needs the same validation and isolation as user input.

Implementation steps

1. Inventory integrations. For each service, list the third-party APIs it calls or receives webhooks from, the credential used, the owner, the data classification, and what happens to the response (stored, queried, rendered, passed to an LLM). ASVS V13.1.1 asks for exactly this documentation.
2. Assess providers. Add API security questions to supplier due diligence: TLS posture, authentication options, token lifetimes, breach notification, how they protect credentials they hold for you. See the Vendor Security Assessment Template.
3. Ship a hardened client. Publish an internal HTTP client wrapper with connect and read timeouts, an overall deadline, redirects disabled, certificate verification enforced, a maximum response size and structured logging. Make linters or code review flag direct use of raw clients.
4. Add schemas per integration. Define the expected response for each provider and validate before use. Start in log-only mode for two weeks to learn real variation, then reject or quarantine non-conforming responses.
5. Allowlist egress. Route outbound traffic through a proxy or gateway with a destination allowlist per service. Begin in monitor mode, review unregistered destinations, then block.
6. Move credentials. Migrate provider keys into the vault or gateway, issue one per integration, set rotation dates and owners.
7. Test hostile providers. Run the three OWASP scenarios against a stub provider in CI: injection strings, 307 and 308 redirects to a canary host, oversized and slow responses.
8. Roll back safely. Put schema enforcement and egress blocking behind per-integration flags so a false positive can be reverted to log-only without a redeploy, and keep a circuit breaker that fails gracefully when a provider misbehaves.

Evidence and assessment

Detection signals and metrics

• Signals to alert on: schema validation failures from a provider that normally conforms; 3xx responses from providers that never redirect; egress to destinations not registered to any integration; response size or latency far outside the provider's baseline; an integration credential used from an unexpected service or network.
• Hardened client adoption: percentage of outbound calls made through the approved client or gateway; target above 95 percent.
• Schema coverage: share of integrations whose responses are validated in enforce mode.
• Timeout coverage: share of outbound call sites with explicit timeouts; target 100 percent.
• Credential hygiene: share of integration credentials vaulted, owned and within their rotation date.
• Supplier coverage: share of critical API providers with a completed security assessment in the last 12 months.

Mapping to other frameworks

See the OWASP ASVS Guide and the Third-Party Risk Management Guide.

Common pitfalls

• Trusting big names: OWASP notes the bias is strongest for APIs from well-known companies. A reputable provider can still be compromised or can relay attacker-supplied data, as in the enrichment scenario.
• Library defaults left in place: a call without a timeout can hang a worker indefinitely, and a call that follows redirects can resend a sensitive request body to a new host.
• Validating shape but not meaning: a schema that checks types but allows any string still lets injection payloads through; the downstream query and rendering code must treat the data as untrusted.
• Prefix matching in allowlists: the OWASP redirects cheat sheet warns against raw prefix or suffix matching, which misleading hostnames can bypass. Parse the URL and compare scheme, host and port.
• Webhooks verified but not validated: a valid signature proves who sent the payload, not that its contents are safe.
• Shared, unowned integration keys: one provider key used by several services cannot be rotated without an outage, so it is never rotated.

Practitioner checklist

• Inventory every outbound API and webhook integration with owner, credential and data use.
• Add API security questions to provider due diligence and review critical providers yearly.
• Enforce TLS with certificate validation on all outbound calls and ban disabled verification.
• Disable automatic redirects, or allowlist redirect targets by parsed scheme, host and port.
• Set connect, read and overall timeouts and cap response size on every call.
• Validate each provider's responses against a schema and use parameterised queries downstream.
• Route egress through an allowlisting proxy or gateway with per-integration logs.
• Issue one vaulted, scoped, rotated credential per integration and environment.
• Test injection, 307 and 308 redirects, oversized and slow responses against a stub provider in CI.
• Keep per-integration flags and revocation runbooks for fast rollback and provider compromise.

Standards and references

• OWASP: API10:2023 Unsafe Consumption of APIs
• OWASP: API Security Top 10 2023
• OWASP: Application Security Verification Standard 5.0
• OWASP Cheat Sheet Series: Input Validation Cheat Sheet
• OWASP Cheat Sheet Series: Transport Layer Security Cheat Sheet
• OWASP Cheat Sheet Series: Unvalidated Redirects and Forwards Cheat Sheet
• NIST: SP 800-53 Rev. 5
• Requests: Quickstart (redirection, history and timeouts)

Related NHI Mgmt Group resources: Top 10 API Security Risks · API Security Guide · SSRF Prevention Guide · Third-Party Access Guide · API Key Management Guide