OWASP API Security Top 10 Applied to Real Integrations

BOLA has sat at the top of the OWASP API list since 2019. Most exploited, hardest to catch automatically, and the mechanism is almost embarrassingly simple: an API accepts an object ID, never checks whether the requesting user actually owns that object, and attackers change /api/v1/orders/1001 to /1002. That's it. Sequential IDs, scripted enumeration, thousands of records exposed before anyone notices a thing.

Salt Security research puts BOLA at roughly 40% of all API attacks. Not close to the top. The top, by a wide margin.

Here's where it gets genuinely interesting for integration work specifically. Third-party APIs routinely use predictable identifiers across tenants. When your application proxies requests on behalf of users and passes those IDs upstream without re-validating ownership on your side first, the third-party API will answer. It has no reason not to. It got a valid-looking request. Done. There's a well-documented automotive sector case where API endpoints had no authorization check binding a requesting user to a vehicle identity. A valid VIN was all you needed to pull records belonging to someone else entirely — like a master key that works on every lock in the building simply because the locksmith never bothered to cut different teeth. Trello hit a similar wall in January 2024, exposing email addresses for a large number of users through a broken object-level flaw.

What this looks like in practice for an integration team:

• Never pass user-controlled IDs directly to upstream APIs without server-side ownership validation happening on your end first, before the call goes out.
• Map external IDs to internal, user-scoped references. Don't expose raw third-party resource IDs to the client at all.
• Verify the returned object actually belongs to the authenticated session before surfacing it. Don't assume the API gave you the right thing just because it responded.

That third one is where teams consistently slip. You called the API, you got a response, so you assume it's correct. That assumption is the vulnerability. The API doesn't know or care. It just answered.

API2 — Broken Authentication and the credential sprawl that integrations create

Most teams understand broken authentication in the abstract: credential stuffing, token theft, brute force. What gets underestimated is what integrations do to that problem. You are now managing authentication for many external services simultaneously, and each one is its own attack surface operating on its own rules, rotation schedules, and failure modes. Managing API credentials across a growing integration stack is like being handed a new set of house keys every time you hire a contractor — and being solely responsible for changing the locks when any one of them goes missing.

Two real examples that illustrate the range of how badly this goes wrong. In 2018, a public-facing USPS API let any authenticated user query account details for other users. The API checked "are you logged in" but not "are you allowed to see this account." Different problem, same failure category. On the other end, an internal API meant for county staff in Franklin County, Kansas, was left completely open, no authentication at all, Social Security numbers and tax records sitting there for anyone who found the endpoint.

Dropbox Sign and Cox Communications both traced significant incidents back to compromised API keys or unauthenticated endpoints. A GitHub secrets spill in March 2024 exposed a large number of API secrets across public repositories. These aren't exotic attack techniques. Credentials are the integration layer's primary attack surface, full stop. Every new connector your team adds brings another set: OAuth tokens, API keys, service account secrets, each one a potential point of compromise, each one with its own rotation cadence that someone has to actually manage.

Practical mitigations, and none of them are particularly fun operationally:

• Enforce short-lived tokens. Long-lived API keys in environment variables or source code are a deferred incident, not a configuration.
• Use per-integration credential isolation. A compromised key for one service should not cascade to others.
• Centralize credential lifecycle management. If your team is handling this per-connector by hand, you will eventually miss a rotation. That's not a prediction, that's a guarantee at scale.

API3 — Broken Object Property Level Authorization and the data your API returns that you didn't mean to

The 2023 list merged two 2019 categories here. Excessive Data Exposure and Mass Assignment became a single item because they share the same root cause: no validation at the property level, even when object-level access is correctly enforced.

In an integration context, excessive data exposure shows up like this. Your product calls a third-party API. The API returns a full user object. Your backend forwards the response to the client. The UI displays three fields. The other forty fields, including internal IDs, metadata, system paths, and occasionally actual credentials, go along for the ride. Nobody meant to send them. They just didn't filter them out. There's a documented case where a buggy API exposed roughly 650,000 sensitive messages, passwords and internal system paths visible in the response object and completely invisible in the UI rendering it.

Mass assignment is the flip side, and it's sneakier. Accept an entire JSON body from a third-party webhook or API response, bind it directly to an internal model without filtering, and an attacker who can influence the upstream response can inject fields your model will happily accept. Your model becomes the vulnerability, even though the payload came from outside your system entirely.

The discipline required here isn't complicated, but it does have to be deliberate:

• Parse and project only the fields your application actually needs. Not the full response object. Not whatever comes back.
• Define explicit allowlists of properties to bind. Never pass raw response bodies through to your data layer.
• Apply the same scrutiny to webhook payloads that you would apply to a form submission from an anonymous user on the internet.

That last one is where things go sideways most often. Webhook payloads feel like internal system data because they originate from another API. They're not. Treat them accordingly.

API4 — Unrestricted Resource Consumption and what happens when an integration has no throttle

Every API call consumes something. Bandwidth, compute, memory. In an integration stack, it often also consumes money directly: metered calls you pay for per request, whether that's email sends, SMS messages, geocoding lookups, or biometric checks. That cost dimension is what makes this category distinctly painful in a way that pure-API rate limiting discussions rarely capture.

The Dell breach shows what unthrottled access looks like at scale when nobody stops it. Attackers sent over 5,000 requests per minute for nearly three weeks. 49 million customer records exposed. That was a failure across multiple categories simultaneously, but the resource consumption piece is what made a three-week sustained exfiltration operationally possible. Without throttling, there was nothing to interrupt it. It brings to mind a tap left running in an empty house — by the time anyone notices the bill, the flood has already happened.

Integration stacks have a version of this that doesn't require taking your service down to hurt you badly. An unthrottled integration endpoint that triggers downstream API calls can generate costs that spike faster than any security monitoring catches them. Sometimes the finance team finds it first. Recent threat research has noted a sharp rise in automated scraping and enumeration attacks against integration endpoints specifically because the attack pattern is volume, not sophistication. Keep knocking until the door comes off.

What rate-limiting actually needs to look like at the integration layer:

• Rate-limit outbound calls to third-party APIs per tenant per time window. Inbound request limits alone don't protect you here.
• Set hard caps on downstream API call volume. Know your ceiling before an attacker discovers it experimentally.
• Alert on anomalous call volumes early, before it becomes a security incident and before it becomes a billing line item your finance team flags in a quarterly review.

API5 — Broken Function Level Authorization and the admin endpoints that integrations quietly expose

BFLA and BOLA are different problems. BOLA is accessing another user's record. BFLA is calling a function you were never supposed to have access to at all: adding records, changing roles, triggering admin workflows, deleting things that should require a different class of user entirely. The mitigations diverge because the failure modes diverge.

The integration-specific version of this is easy to let slide for a long time without noticing. When your product integrates with a third-party platform, it often acquires elevated API scopes to support a specific feature at build time. Those scopes then persist. The feature that only needed read access was built with a token that also grants write and delete because someone requested broad scopes to avoid coming back for more later. Nobody flagged it. Complex role hierarchies in enterprise platforms tend to produce authorization gaps exactly at the boundary between normal and administrative functions, which is precisely where integration tokens tend to operate.

What actually helps:

• Request the minimum necessary OAuth scopes for each integration. "Just in case a future feature needs it" is not a justification for admin scopes today.
• Enforce function-level authorization checks in your own API layer, even when you're calling a third-party that has its own checks. Don't rely on the upstream service to enforce your access model.
• Audit token scopes whenever a connector is updated or a new feature ships. Scope creep over time is real and almost entirely invisible without a deliberate review cadence.

API6 — Unrestricted Access to Sensitive Business Flows and attacks that exploit your integration logic, not your bugs

This one is genuinely hard to patch because the API is doing exactly what it was designed to do. There is no bug. An attacker is using your business logic in ways you didn't anticipate. Scalping limited-inventory items, creating fake accounts in bulk, exhausting promotional codes: technically valid API calls, every one of them.

A retail case in the research makes the financial stakes concrete. A retail API allowed one discount code per order. Attackers chained multiple API calls to apply dozens of codes to a single order. $400,000 in fraudulent discounts before anyone caught it. The API was working correctly. That's the uncomfortable part.

Integration workflows make this harder to catch, not easier. Automated pipelines expose business flows in ways that are significantly more difficult to monitor than user-facing interfaces. A webhook triggering a provisioning flow, a connector syncing user entitlements, an API kicking off a billing event: each of these is a business flow that can be abused if the trigger is accessible, and automation that looks legitimate from the API's perspective is invisible to signature-based defenses. There's no anomalous payload to flag. The requests are clean.

What actually helps here:

• Model expected usage patterns for integration-triggered flows. Define what normal looks like first, then alert on deviation from it.
• Apply business-logic validation server-side: idempotency keys, per-account flow limits, sequence validation.
• Don't rely on the upstream API to enforce your business rules. A third-party service will accept valid calls regardless of whether those calls represent legitimate use on your platform.

API7 — Server Side Request Forgery and why webhooks and URL-fetching integrations are natural SSRF targets

SSRF made the 2023 list specifically because it became more prevalent as API-based architectures spread. The mechanism is worth being clear about. An API fetches a user-supplied URL. An attacker supplies an internal address, a cloud metadata endpoint, a VPC resource. The server resolves it because the server sits inside the network perimeter and the destination does too. The server is acting in good faith on bad instructions, and it has the access to make it work.

Kubernetes and Docker rely on HTTPS API-based communication internally, which means an SSRF flaw in a web-facing API can pivot into internal cluster APIs with minimal additional effort.

CVE-2024-27564 allowed crafted URL injection into a proxy file with no authentication required. Over 10,000 exploit attempts were logged from a single IP address in a single week in March 2025. The proof-of-concept code had been publicly available for nearly a year before that spike. That's not a zero-day problem. That's a patching discipline problem.

The integration-specific exposure points are pretty direct:

• Webhook registration. If your product lets users specify a webhook destination URL, an attacker can point it at an internal endpoint. Your server makes the request. Your server has the access.
• URL-fetching integrations. File imports, link previews, OAuth redirects: any feature that issues a server-side HTTP request based on user-controlled input is a potential SSRF vector.

Mitigations that actually close the gap:

• Validate and allowlist outbound URL destinations. Block private IP ranges, link-local addresses, and cloud metadata endpoints explicitly, not by default assumption.
• Never issue server-side requests to user-provided URLs without sanitization happening first.
• Treat webhook destination URLs as untrusted input until they've been validated against an explicit allowlist.

API8 — Security Misconfiguration across the integration stack, from CORS to verbose error messages

Misconfiguration is a catch-all category. That breadth is intentional because misconfiguration shows up everywhere and the individual instances look minor until they're not. Missing security headers, overly permissive CORS settings, unnecessary HTTP methods left enabled, verbose error responses that hand an attacker a detailed map of your infrastructure: any one of these is exploitable on its own.

What this actually looks like in the wild:

• An API returning full stack traces in error responses, with internal file paths, database names, and framework versions included. That's not a minor issue. That's a briefing document for anyone planning an attack.
• CORS configured with a wildcard origin and credentials enabled simultaneously. Any site can now make authenticated cross-origin requests to your API.
• Injection attacks, which were their own category in 2019, now fall under API8 in the 2023 list. Misconfigured input handling is the vector.

A 2025 fintech breach exposed 2.6 million financial records through misconfigured endpoints. Not a code vulnerability. A configuration error. That distinction matters specifically because configuration errors don't show up in code review. You can have clean code and a completely exposed API at the same time.

Integration stacks compound this. Every service added to a stack introduces its own configuration surface. A misconfigured CORS policy on one internal API can expose the entire integration pipeline flowing through it. Staging and development environments for integrations are frequently misconfigured and sometimes left internet-accessible, often because someone needed to test a webhook quickly and never locked it back down afterward. That's not negligence in most cases. It's just how things slip.

Integration-layer risk is where API risks stop being isolated problems and start compounding across connected surfaces. One misconfiguration, one overly scoped credential, one unvalidated object ID: in a single-service context those are contained. In an integration stack they touch a dozen external services, and the blast radius is proportionally larger. The OWASP list gives you the framework. The integration layer is where it actually has to be applied.