Security Review Criteria for Third-Party API Integrations

Third-party vulnerabilities were linked to 35.5% of all recorded breaches in 2024 The Hidden Risk of Integrations: A Checklist for Vetting Third-Party Apps. More than a third of every breach traced back to some vendor connection, some API call, some integration that got approved without rigorous review. And the trend line is heading in one direction.

The Indusface State of Application Security H1 2025 Report found a 104% rise in API-targeted attacks, a 13X jump in API vulnerability exploits, and 388% more DDoS attacks aimed at API hosts than at regular websites obsidiansecurity.com. SaaS and tech platforms took the worst of it: 74X higher API attack volumes and 121X more API-layer DDoS attacks compared to traditional enterprises Indusface State of Application Security H1 2025 Report.

The Wallarm 2026 API ThreatStats Report found broken authentication caused 52% of API-related incidents. More than half of the incidents in that dataset trace back to a single failure category, and it's the same category that sits at the front of the review framework this piece lays out below. Attackers have also made a deliberate pivot away from traditional web app exploits toward APIs specifically, and the price tag on vulnerable APIs and bot attacks now runs past $186 billion a year getastra.com.

Each number in that dataset points at a specific failure mode: broken authentication, unsafe consumption of vendor data, resource abuse with no cap enforced. Each failure mode maps to one of the review domains that follows. The rest of this piece is organized domain by domain, in the order the risk data indicates they should be addressed.

How Integration Sprawl Creates Systemic Exposure

The average enterprise SaaS platform connects to more than 42 third-party applications through OAuth tokens, API keys, webhooks, and automation platforms obsidiansecurity.com. Most security teams cannot enumerate all 42 on demand, and that gap between actual and visible integrations is where systemic risk accumulates obsidiansecurity.com.

Every one of those connections is its own trust boundary, its own credential lifecycle, its own data path, its own failure mode, and its own potential route into whatever sits downstream. The integration inventory is the attack surface, and it changes in real time.

JPMorgan Chase CISO Patrick Opet said in an April 2025 open letter that the modern SaaS ecosystem creates inherent risks, since it lets third-party providers reach into a business through a maze of SaaS-to-SaaS integrations. That description applies to the default architecture of a modern company, not an edge case.

The core mistake is treating a trusted partner, a SaaS vendor, an internal service, or an AI agent as inherently safe based on that label alone. A domain-organized checklist matters because the blast radius of one missed criterion rarely stays contained to the integration that failed. The biggest SaaS breach of 2025 began with a compromised third-party app, as attackers exploited Salesloft-Drift OAuth tokens to reach hundreds of downstream environments, a blast radius 10x greater than prior incidents where attackers infiltrated Salesforce directly, according to Obsidian researchers obsidiansecurity.com.

Which Frameworks Should Govern Every Review

Start with the OWASP API Security Top 10, the 2023 edition, since it is the closest thing this space has to a shared vocabulary. That edition kept authorization risks at the top of the list, renamed several categories, merged two together, dropped two standalone entries, and added four new risks. For third-party reviews specifically, the entryfe Ssdf xa that matters most is API10:2023, Unsafe Consumption of APIs, which identifies the specific habit that causes teams problems: developers trust third-party API data more than they trust their own users' input, so validation and sanitization get skipped obsidiansecurity.com. Authorization issues still rank first on OWASP's list and on Curity's 2025 trend reports, and the resource consumption category was broadened in 2023 to cover execution timeouts, upload file size limits, spending caps on third-party services, and limits on records returned per page.

NIST SP 800-228-upd1, "Guidelines for API Protection for Cloud-Native Systems," is the other foundational reference. It published in June 2025 and received two new appendices as of March 13, 2026, mapping API risks and controls across lifecycle stages. Regulatory overlays shape what evidence a review must produce: PCI DSS, GDPR, and SOC 2 all apply wherever an integration touches payment data, personal data, or health data.

Salesforce AppExchange offers a working example of what rigorous evidence looks like in practice securitywall.co. Reviews there combine static analysis tools like Checkmarx CxSAST and Salesforce's own Code Analyzer, dynamic testing through tools such as OWASP ZAP, Burp Suite, or Qualys, and manual review across eight categories defined in the ISVforce Security Review guidelines securitywall.co. Initial reviews typically take 6 to 9 weeks securitywall.co. None of these frameworks replace a reviewer's judgment. They define the minimum vocabulary a review must speak before it can be considered complete.

Vendor Due Diligence Before Integration Code Ships

Before any code gets written, verify recognized security credentials such as ISO 27001, SOC 2, or NIST compliance, review recent audit or penetration test reports, and confirm a formal vulnerability disclosure policy or bug bounty program is in place. A bug bounty or VDP signals that a vendor actively hunts down its own vulnerabilities and resolves them before they result in incidents, rather than learning about them through a breach report.

Every integration needs to be documented: cloud resources, third-party services, internal microservices, and the data flows between them. The definition of what counts as an "application" has expanded as tech stacks have grown more complex, and the inventory has to reflect that.

The question a reviewer needs answered is not whether a vendor looks legitimate. It is whether the vendor has a track record of disclosing issues promptly, and whether its security posture holds up against the regulatory frameworks that apply to the data it will handle. If a vendor does not clear every credential check, that does not automatically mean rejection. It means the residual risk gets documented and accepted by someone with the authority to accept it.

Authentication: Tokens, Credentials, and Assurance Levels

Zero trust as a working principle means every request must demonstrate who it is, what it is permitted to do, and that it should be performing that action at that moment. Being inside the network or carrying a trusted-partner label is not a control.

Static API keys are the clearest example of what not to rely on. They are long-lived, difficult to rotate, and frequently appear in logs or code repositories where they do not belong. They are acceptable only for low-risk data, and only with strong monitoring to catch what the key itself cannot prevent.

The modern baseline is OAuth 2.0 paired with OpenID Connect, so integrations pull short-lived, scoped tokens rather than carrying permanent credentials on every call. Access tokens should run in the 15-to-60-minute range, and refresh tokens somewhere between 1 and 30 days, using one-time-use rotation ssojet.com en.wikipedia.org. If a server receives the same refresh token twice, the whole token family should be revoked immediately.

NIST SP 800-63B Revision 4, published in 2024, reframed the authenticator assurance levels (AAL1, AAL2, AAL3) and reclassified SMS-based MFA as a "restricted authenticator." That classification is still permitted, but only with additional conditions and documented risk acceptance, and this shift now appears in what SOC 2 auditors expect to see as evidence. External partners should receive only opaque tokens, translated into internal JWTs at the gateway, so no outside party reads internal claims or depends on an internal token format. Services must verify JWT signatures on every hop, and no service should be permitted to mint its own tokens. The reviewer checkpoint is to confirm what token lifetimes are actually configured to, and whether a documented rotation and revocation procedure exists behind them.

Authorization: Scope Minimization and Token Accumulation

Every third-party connection issues an OAuth token, and those tokens tend to carry broad, persistent permissions that do not expire quickly and largely go untracked. Tokens accumulate over time, tied to users who left the organization or applications nobody remembers connecting, and because they operate outside the identity provider, they remain active through offboarding and password resets. This is how modern breaches unfold: quietly, with no alert firing, because the token itself has no mechanism to detect that the originating user is gone.

Least privilege must be applied concretely. Scopes and roles should expose specific endpoints, specific fields, and specific actions, never a broad read/write grant issued because it was the easier option during setup. NIST SP 800-228-upd1 requires an authorization system that is high-reliability and low-latency, one that application developers integrate with directly and keep current as users, resources, and permissions change. Even with that system in place, developers can still enforce access decisions inside application code rather than through the authorization system, which defeats the purpose entirely.

Reviewers should confirm what scopes are requested and whether each can be justified by a specific function the integration performs, whether there is a documented process to revoke tokens when an integration retires or a connected user departs, and whether the token inventory is visible to the security team on an ongoing basis.

Data Handling: Treat Third-Party Responses as Untrusted

OWASP identifies this directly as API10:2023: developers tend to trust third-party API data more than user input, leading to weaker validation and sanitization obsidiansecurity.com. That habit is what turns a vendor's breach into an organization's breach.

If an upstream API gets compromised and begins returning malicious payloads, or if a service follows redirects without verifying their destination, the trust relationship itself becomes the vulnerability. All data received from third-party APIs must be validated and sanitized regardless of source reputation. Strict content-type and schema checks should be enforced on every response. Any third-party data must be encoded before it renders on a client. TLS must be enforced across all integration traffic and verified rather than assumed. Redirects should never be followed to a destination that has not been validated first.

Skipping those steps opens the door to SQL injection, cross-site scripting, and data integrity corruption, all carried in on data that was treated as safe because of its origin. The reviewer checkpoint is to trace one data response from the third-party endpoint to wherever it is consumed or rendered and count the validation steps along the way. If that count is zero, the integration is not ready regardless of the vendor's reputation.

Rate Limiting: Capping Blast Radius from Automation

OWASP's 2023 update renamed and broadened the resource consumption category, now API4:2023, Unrestricted Resource Consumption, to explicitly cover execution timeouts, maximum upload file sizes, spending limits on third-party service providers, and caps on records returned per request. Without these controls, a single endpoint can absorb an entire traffic flood, or quietly accumulate runaway costs on a metered third-party service. That damage appears on an invoice as readily as it appears in an incident report.

Controls that must be in place include per-client rate and concurrency limits, caps on request size and query depth, timeouts paired with retry budgets that include backoff to avoid amplifying an outage, pagination limits on any endpoint returning collections, and spend alerts on any metered downstream service the integration touches.

The reviewer checkpoint is to ask what happens to the system if this third-party API returns responses 10x slower than normal, or returns 10x more records than expected. If the team cannot answer that question with specificity, the resource controls are not verifiably in place.

Logging & Monitoring Must Exist Before Go-Live

OWASP identifies this as Security Logging and Monitoring Failures, category A09:2021. Without adequate logging and monitoring, breaches go undetected and response is impossible until damage is already done.

The minimum baseline requires that every authentication event, every authorization decision, and every API error produce a complete record, including under high volume. Logging without alerting is an archive, not a control.

Best practices from security trend analysis for 2026 include automated API discovery, regular API penetration testing, security tests integrated into CI/CD pipelines, and continuous monitoring of APIs in production. Before an integration goes live, the team needs a documented answer to one question: who gets notified when this integration throws an anomalous event, and what is the first action they take? A vendor's own incident response posture matters as due diligence, but it only produces value if the internal team has a process ready to act on a vendor's disclosure. The tabletop version of this should be run before go-live: if this integration began quietly exfiltrating data today, how many hours would pass before anyone detected it? Whatever that number is, it represents the residual risk being accepted, whether anyone has formally signed off on it or not.

Agentic AI & MCP Require Extended Review Criteria

Starting in 2025 and continuing through 2026, enterprise agentic AI deployments are multiplying the number of APIs running in production, and the attack surface is expanding alongside them. Model Context Protocol vulnerabilities grew 270% between Q2 and Q3 of 2025 alone Wallarm 2026 API ThreatStats Report. MCP now accounts for 14.4% of all AI vulnerabilities despite still being early in adoption, and the Wallarm report identified it as the strongest predictor of where future risk is concentrated 2026 API ThreatStats Report.

Agentic systems calling third-party APIs without validation, operating on over-scoped tokens, and lacking rate limits produce the same broad-impact failure modes that any other integration on this list creates getastra.com. The distinction is that an agent acts faster and with significantly less human oversight between the decision and its consequence.

None of the domains covered above stop applying to agentic and MCP integrations. Authentication, authorization, data handling, rate limiting, and logging all remain required Wallarm 2026 API ThreatStats Report. What changes is the pace at which review must keep up, and the assumption that a human will catch a problematic call before it executes. That assumption no longer holds. Letterbrace, for instance, builds this constraint into its content platform for B2B SaaS, requiring human approval before any structural strategy change ships.