Security Review Requirements for Third-Party API Integrations

The average company runs on 131 third-party APIs, according to Traceable AI's 2025 State of API Security Report. That's not a vendor list. That's a mesh, and most of it stays invisible until something breaks.

APIs make up over 70% of web traffic now, so the integration layer isn't some side door into your application. Every time you plug in a third-party API, you inherit that vendor's entire security posture: their misconfigurations, their weak auth flows, the undocumented endpoint they forgot they ever built. You don't get to cherry-pick the good parts and leave the rest.

Shadow APIs make this worse. Undocumented or deprecated endpoints account for more than 20% of the total API inventory sitting inside enterprises, and third-party integrations are a major contributor to that clutter. Only 16% of organizations say they're actually equipped to manage risk coming through external APIs. That gap between 131 dependencies and 16% capability is a structural problem, and it's the kind that doesn't announce itself until significant damage is already done.

The trend line isn't friendly either. API-related breaches hit 37% of organizations in 2024, up from 17% the year before, and 57% reported a breach within the prior two years, per Traceable's survey of over 1,500 IT and security professionals. Verizon's 2026 Data Breach Investigations Report puts third-party involvement at 48% of all breaches analyzed, up from 30% the year prior. What holds up against numbers like that is a review process you run the same way every time, whether it's integration number one or number one hundred and thirty-one.

What Pre-Integration Reviews Are Preventing

Nobody has to invent this from scratch. OWASP's API Security Top 10 (2023 edition) is the reference every reviewer checks their work against, and each item on a decent pre-integration checklist traces back to one or more of these categories.

Two threats dominate. Broken Object Level Authorization (BOLA) has held the top spot on OWASP's list since 2019 and shows up in roughly 40% of all API attacks. It's the failure where the vendor confirms you're authenticated but never checks whether you're authorized to access that specific object. A pre-integration review has to confirm object-level authorization checks actually exist, not just that authentication is present.

Broken authentication is the other heavyweight, implicated in 52% of the 60 API breaches Wallarm analyzed in its 2026 research. This is about how credentials get issued, rotated, and revoked. If a vendor can't answer basic questions about token lifecycle, that's not a documentation gap. That's a missing control.

Behavioral attacks against sensitive business flows (OWASP's API6 category) jumped to 61% of API attacks in 2025, up from 30% in 2024, according to Akamai SOTI 2026. These attacks skip authentication entirely and abuse a legitimate flow at scale, such as a bot purchasing every available item using a completely valid account. A review that only asks whether authentication is working will not catch this category of attack.

Unsafe Consumption of APIs (API10) applies most directly to integrations, since it's the category specifically about trusting an upstream vendor's API surface. Wallarm's 2026 analysis attributed 27% of breaches to exactly this. Security misconfiguration is a persistent driver of API security incidents, and it usually sits on the vendor's side where it isn't visible until a breach notification arrives. Improper Inventory Management (API9) is the related question: does the vendor even know what their own API surface looks like, including deprecated endpoints nobody shut off?

One number that should reframe how teams think about perimeter defense: 95% of API attacks in 2025 came from authenticated sessions, per CybelAngel's API Threat Report. The attacker already holds valid credentials. Lateral movement through a trusted, already-approved integration is the realistic attack path, and firewalls are not designed to detect that kind of traffic.

AI widens all of this further. Traceable's 2025 data found 60% of organizations saying the additional API integrations required for AI applications increased their attack surface, and 65% call generative AI a serious to extreme API security risk. Webhooks also require dedicated checklist coverage: signing verification, replay protection, and timestamp tolerance windows are controls that frequently get skipped because webhook receivers aren't treated as real API surface. Every inbound payload is an attack vector that needs the same scrutiny as any other endpoint.

Verifying Vendor Security Posture Before Signing

Before a contract is signed, ask for documentation. Not a sales deck with a security badge on a slide, but actual evidence.

Start with certifications. ISO 27001 confirms the vendor has a formal information security management system. A SOC 2 Type II report matters more than a Type I, because Type II covers a period of actual operation rather than a point-in-time assessment. Get the full report, not the executive summary. If the integration touches payment data, PCI DSS attestation is required. Ask for penetration test reports and check the date (within the last 12 months), the scope (whether it covered the specific API surface you're integrating with), and whether identified findings were remediated.

Ask about vulnerability disclosure. Does the vendor run a responsible disclosure program or a bug bounty? Can they walk you through a past security incident and how they handled it? Cross-reference with public breach records and CVE history as well.

Sub-processors are the part organizations most commonly overlook. Your vendor almost certainly has vendors of their own, and those fourth parties touch your data even though you never signed anything with them directly. A significant share of all recorded breaches in 2024 traced back to third-party vulnerabilities, and each sub-processor is another link in a dependency chain you didn't choose but remain attached to. Get the list, and confirm contractually that sub-processors meet the same security requirements as your primary vendor.

Security questionnaires (SIG Lite, CAIQ, or whatever standardized format your organization uses) are useful as a baseline because they let you compare vendors consistently rather than chasing different documentation formats. Treat the answers as claims to verify, not verdicts to trust. The SOC 2 report is evidence; a questionnaire response is an assertion.

Vendors get acquired, migrate cloud providers, and restructure their security teams over time, and your inherited risk changes with them. Build reassessment into the contract on a defined cadence so it happens on schedule rather than only after an incident prompts the question.

Authentication and Authorization the Integration Must Satisfy

Auth is where good intentions fail quietly, usually because someone hardcoded an API key into a config file years ago and nobody has touched it since.

OAuth 2.0 with short-lived access tokens should be the default assumption. Check the token expiry window and how refresh actually works, not just whether the vendor's documentation mentions OAuth somewhere. Where user identity has to travel with the request, OpenID Connect sits on top of OAuth for that purpose. For server-to-server integrations, mutual TLS is the standard, where both sides verify each other rather than just the client checking the server's certificate. It is required under UK Open Banking rules and increasingly expected across financial and healthcare integrations generally.

API keys still have a place, but a narrow one: low-sensitivity, server-side-only integrations. If an API key is sitting in client-side JavaScript, or committed to a version control repository, that is a material exposure, not a minor configuration issue.

Four questions need documented answers before launch. How are credentials issued? How do they rotate? How are they scoped to only what the integration requires? How are they revoked when something goes wrong? Secrets belong in a secrets manager, not in environment files sitting in version control. Production credentials should never match staging credentials; if they do, a breach of the test environment becomes a breach of production.

On authorization scope, request the minimum the integration actually requires and document why each scope is necessary. This is what makes BOLA and Broken Function Level Authorization checks possible later. Test it directly: can this integration, with the scopes it was granted, reach an admin endpoint it has no business accessing? If yes, that is a finding that requires remediation before go-live.

Token lifecycle matters on your side too. Do not store sensitive tokens in localStorage, since anything stored there is accessible to cross-site scripting attacks. Confirm the vendor's revocation endpoint works and propagates quickly. A revocation that takes hours to take effect provides only the appearance of access control, not the reality of it.

Data Handling, Classification, and Transfer Controls

Before designing the integration, establish what is actually flowing through it. PII, financial records, health data, credentials, and internal business content all carry different regulatory weight, and that weight determines which compliance requirements apply and what must be locked down contractually before the first API call fires.

Encryption in transit means TLS 1.2 as a minimum floor, TLS 1.3 as the actual target, and the cipher suite configuration itself should be reviewed rather than just confirming that a connection is encrypted. Data the vendor stores on your behalf requires encryption at rest. For genuinely sensitive fields such as Social Security numbers, payment card numbers, and health identifiers, field-level encryption is worth the additional engineering investment if the vendor will persist that data at all.

Data minimization is easy to understand and frequently ignored in practice. Review the actual request payload. Is the integration sending the vendor the five fields it needs, or forty fields because someone reused an existing object rather than building a minimal one? Over-sharing in request bodies is one of the most common exposures found during integration reviews and one of the easiest to fix. Pair that with a review of the vendor's retention policy, since data retained past its useful life is stored risk with no corresponding benefit.

Cross-border transfers carry specific legal requirements. Under GDPR Articles 44 through 50, personal data cannot leave the EEA without a recognized transfer mechanism in place, whether that is an adequacy decision, Standard Contractual Clauses, or Binding Corporate Rules. Confirm what data residency options the vendor actually offers, and whether they will commit in writing to keeping data within the required jurisdiction.

The financial stakes are concrete. Research has found the average breach cost climbs 12.6%, to $5.05 million, when an organization is rated highly noncompliant. Data handling gaps are frequently the specific form of noncompliance that drives that cost increase.

Compliance Frameworks and What They Require

Frameworks are not interchangeable, and treating them as a single compliance category is how gaps slip through unnoticed.

PCI DSS v4.0 explicitly puts APIs touching cardholder data in scope as custom or bespoke software. Requirement 6.3.2 calls for a maintained inventory of that bespoke and third-party code, meaning your integration needs to appear on that list before launch, not get added retroactively when an auditor asks where it is. Verify whether the vendor's own environment has been validated by a Qualified Security Assessor.

GDPR requires a Data Processing Agreement before personal data moves to a third-party processor. That is a legal precondition, not a post-launch task to address when legal has bandwidth. Cross-border transfer mechanics belong in that same document.

DORA, now in effect, applies to financial entities operating in the EU and requires documented ICT third-party risk management covering API integrations with critical function providers. Incident notification timelines, audit rights, and exit strategies need to be written into the vendor contract before go-live, not negotiated after an incident occurs.

SOC 2 and ISO 27001 come back into play here as well, not as additional hoops but as confirmation that the integration you're building doesn't quietly undercut controls those certifications are supposed to guarantee.

Healthcare integrations carry their own requirements. HL7 FHIR APIs exchanging patient data fall under the 21st Century Cures Act and ONC regulations at 45 CFR Part 171, and that requires a dedicated review pass, not a generic compliance checklist stretched to fit.

Platforms like Salesforce AppExchange, AWS Marketplace, and Stripe run their own security review processes before allowing an integration to list publicly, sometimes taking two to ten weeks and using tools like Checkmarx, OWASP ZAP, Burp Suite, and Qualys. Clearing one of those reviews is a useful signal, but it is not a substitute for your own checklist. A marketplace review protects the marketplace's users broadly, not your specific data flows.

Rate Limiting, Resource Controls, and Operational Resilience

Rate limiting is a security control, not just an operational concern. OWASP's API4 category, Unrestricted Resource Consumption, exists because an attacker who cannot break authentication can instead overwhelm an endpoint until something fails. Confirm the vendor enforces limits per API key or client, not a global ceiling that a single actor could exhaust. Review your own outbound rate limits as well to avoid accidentally triggering the vendor's abuse detection or amplifying a downstream outage.

Document what happens when a quota is hit. Does the vendor degrade gracefully, or does it return a hard failure? On the retry side, exponential backoff with jitter is the standard approach. A fixed retry interval, when many clients hit it simultaneously, can turn a minor outage into a prolonged one.

Error handling deserves specific attention. Some vendors return stack traces or internal identifiers in their 4xx and 5xx responses, which provides useful reconnaissance data to anyone probing the API. Make sure your integration does not pass those raw error messages through to your own users.

Review the vendor's uptime commitments and plan for what happens operationally if the API is unavailable. DORA-regulated entities have an additional requirement here: contractual confirmation that ICT providers meet defined resilience standards.

Webhooks require a dedicated checklist pass: verify the signing secret on every inbound payload, enforce a timestamp tolerance window to block replay attacks, and keep the receiver endpoint out of public documentation.

Logging, Monitoring, and Ongoing Integration Visibility

None of the work above matters much if nobody can see what the integration is doing after launch. A review that ends at go-live covers only the easier half of the problem.

Logging needs to capture the events that matter: authentication attempts, scope changes, data access patterns, and anomalies in request volume. That data needs to land somewhere your security team can query it alongside other signals, not buried in a vendor dashboard that goes unreviewed after the first week. If the vendor cannot explain what they log or how long they retain it, that is the same category of problem as a missing SOC 2 report.

Monitoring has to stay ongoing, matched to the reassessment cadence built into the vendor relationship from the start. A vendor's security posture on day one of the contract is not a guarantee about day 400. Given that 95% of API attacks arrive via authenticated sessions, the visibility that actually catches malicious activity is behavioral monitoring that identifies requests not fitting expected patterns, not just confirmation that a login succeeded.

The structured review is not a gate you pass through once. It is the standard the integration gets held to for as long as it runs in production, which for most vendor relationships is considerably longer than anyone expects at signing.