API Security Threats

What it is

An API (application programming interface) is the contract through which one piece of software talks to another. The web browser version of your app is one client. The mobile app is another. Partner integrations, internal microservices, and third-party tools are still more. All of them speak through APIs.

The shift from monolithic web applications to API-driven architectures was largely complete by 2020. By 2026 it is unusual to find a serious application that is not a thin client over an API backend. That architectural change was good for productivity. It also expanded the attack surface in ways that web app security playbooks do not fully cover.

API security is the practice of protecting that interface. The threats are real, the controls are different from classical web app security, and the gap between what teams test and what attackers exploit is wider than it should be.

Why it matters

A short list of API breaches from the past few years tells you why this category gets its own attention:

• T-Mobile, 2023. An API endpoint allowed attackers to enumerate customer records. Roughly 37 million records exposed before the issue was caught.
• Optus, 2022. An unauthenticated API endpoint exposed personal data on roughly 10 million customers. The breach prompted regulatory and political action across Australia.
• Toyota, 2023. A misconfigured customer-facing API exposed location data and personal information for over two million Japanese customers across nearly a decade.
• Peloton, Venmo, USPS, Parler. All API-related exposures of varying scale in the years prior.

In each case, the underlying flaw was authorisation logic. The endpoint was reachable, the request was technically well-formed, and the server returned data the requester should not have been allowed to see. None of these were exploitable through SQL injection or a missing patch. They were business logic failures, and the attacker just had to ask the right question.

The discovery problem

Before discussing specific threats, it is worth being honest about the precondition: most organisations cannot list their own APIs.

Modern enterprises have:

• Documented APIs. The ones in the API gateway, with OpenAPI specs, monitored and rate-limited.
• Shadow APIs. Built by a team somewhere, exposed publicly, never registered with central security.
• Zombie APIs. Old versions that were supposed to be deprecated. Still reachable. Still serving traffic. Often missing the security controls of the current version.
• Third-party APIs the organisation depends on. SaaS vendors, payment processors, identity providers. Each of them is part of your attack surface even when you do not own them.

If you cannot enumerate your APIs, you cannot test them, monitor them, or rate-limit them effectively. API discovery (using a combination of network telemetry, gateway logs, traffic mirroring, and external scanning) is foundational to everything else.

The OWASP API Security Top 10

OWASP maintains a separate Top 10 specifically for API security, last meaningfully revised in 2023. The categories overlap with the classic web Top 10 but have their own emphases.

API1: Broken Object Level Authorisation (BOLA). Also known as IDOR. The endpoint accepts an object ID, fetches the object, and returns it without checking whether the caller is allowed to see that specific object. GET /api/orders/12345 returns order 12345 even if the authenticated user only owns order 12346. This is the single most common API flaw and the root cause of most of the headline breaches above.

API2: Broken Authentication. Weak token generation, predictable session IDs, missing rate limits on login endpoints, password reset flows that can be brute-forced. Authentication for APIs has the same failure modes as for web apps, plus a few specific to long-lived tokens and machine-to-machine auth.

API3: Broken Object Property Level Authorisation. A more subtle cousin of BOLA. The user can fetch an object they are allowed to see, but the response contains fields they should not be able to read or write. Mass assignment vulnerabilities (where a request body sets fields the user should not control, like isAdmin: true) sit in this category.

API4: Unrestricted Resource Consumption. No rate limits, no quotas, no payload size caps. Lets attackers exhaust resources or run cost-multiplier attacks (some endpoints cost the provider real money per call when they invoke downstream paid services).

API5: Broken Function Level Authorisation. Admin endpoints that work for non-admin users because the authorisation check is in the UI but not the API. The classic case is a "delete user" endpoint that any authenticated user can hit if they know the URL.

API6: Unrestricted Access to Sensitive Business Flows. Automating actions that should only happen at human pace. Mass account creation, ticket scalping, sneaker bots, content scraping at industrial scale. The endpoint works correctly. The problem is that nothing prevents a single actor from running it ten thousand times.

API7: Server Side Request Forgery (SSRF). The API takes a URL as input and fetches it server-side. If unrestricted, the attacker can make the API fetch internal services, including cloud metadata endpoints. Capital One was an SSRF-leading-to-cloud-metadata chain.

API8: Security Misconfiguration. Verbose error messages leaking stack traces, debug endpoints left in production, CORS configured permissively, TLS misconfigurations. The category catches a wide range of real-world findings.

API9: Improper Inventory Management. The shadow API problem. Teams cannot secure APIs they do not know exist. Old versions stay reachable long after the documentation moved on.

API10: Unsafe Consumption of APIs. Trusting the responses from third-party APIs as if they were trusted internal data. A malicious or compromised partner API can inject data your code does not validate.

How attackers exploit it

A typical API attack does not look like a traditional web exploit. It looks like an unusually thoughtful customer.

1. Discover endpoints. Browse the application normally with a proxy running. Enumerate every API call the legitimate UI makes. Pull the mobile app's binary and extract endpoints from it. Check JavaScript bundles for hardcoded URLs.
2. Map the object model. Identify the IDs the endpoints accept. Are they sequential integers? UUIDs? Hashed?
3. Test for BOLA. Authenticate as user A. Request user B's resources. Does the API check, or does it return them?
4. Test for mass assignment. Send a normal POST request. Then send the same request with extra fields (role, is_admin, tenant_id, internal_notes). Does the API silently accept them?
5. Hit the rate limits. Send rapid requests. Is there a limit? At what threshold? Per user, per IP, per token?
6. Probe for SSRF. Endpoints that take URLs (webhooks, image imports, link previews) get the metadata service URL stuffed into them.
7. Look for old versions. /api/v1/, /api/v2/, /internal/api/, /admin/api/. Versions left running often lack the controls of the current version.

Tools like Postman, Burp Suite, and dedicated API security testers automate most of this. The skill is not in the tooling. It is in knowing what to look for.

Why traditional WAFs miss it

A web application firewall built before the API era is largely pattern-matching against known bad payloads. SQL injection strings, XSS payloads, path traversal sequences. Useful, and not what most modern API attacks look like.

A BOLA exploit is a perfectly well-formed HTTP request that asks for someone else's data. Nothing in the URL, headers, or body looks malicious. The WAF cannot tell the difference between "user fetching their own order" and "user fetching someone else's order" without understanding the application's authorisation model.

API-aware security tools (sometimes labelled "API security platforms" or "API security gateways") try to fill this gap by:

• Learning the normal call patterns of each endpoint
• Detecting deviations (a user account suddenly fetching ten thousand different object IDs)
• Validating responses against schema, including detecting unintended sensitive field leakage
• Rate-limiting per object, per user, and per endpoint rather than just per IP

Even with these in place, the underlying authorisation logic still has to be correct. No tool replaces secure code.

How to detect API issues

Detection is a combination of discovery, testing, and runtime monitoring.

• Continuous discovery. API gateways, network telemetry, and external scanning together produce an evolving inventory. Compare it against the documented inventory and treat the delta as a finding.
• Authenticated security testing. Run scanners and manual testing as actual user roles. BOLA only shows up when you can compare what user A sees to what user B sees.
• Schema validation in production. Detect responses that contain fields not in the schema, or accept inputs that should be rejected. Either is a sign of misconfiguration or drift.
• Anomaly detection on call patterns. A sudden spike in distinct object IDs requested per user is a classic sign of enumeration.
• External attack surface monitoring. Find APIs that became reachable from the internet without going through the gateway. This is where shadow and zombie APIs surface.
• Specification testing in CI. Tools that read the OpenAPI spec and generate test cases catch a meaningful fraction of issues before deploy.

How to remediate

Most API findings fall into a few buckets, each with a standard fix:

1. BOLA and BOPLA. Add object-level authorisation checks at every endpoint. The check belongs at the data layer, not the controller. Tag every request with the authenticated principal and verify ownership before returning anything.
2. Mass assignment. Use explicit allowlists for accepted fields. Never bind request bodies directly to database models without filtering.
3. Missing rate limits. Apply per-user, per-IP, and per-endpoint limits in the gateway. Different endpoints need different thresholds.
4. Function-level authorisation. Enforce role checks server-side at every endpoint. The UI hiding a button does not protect the API.
5. SSRF. Allowlist destination URLs. Block requests to internal IPs, private ranges, and metadata addresses. Where outbound calls must reach arbitrary URLs, do it from a hardened service that cannot reach internal resources.
6. Inventory gaps. Onboard every API to the gateway. Decommission old versions explicitly. Treat unknown endpoints as findings.
7. Sensitive data over-exposure. Schema-driven response filtering. Define what each endpoint returns and reject responses that diverge.

Best practices

• Treat APIs as first-class assets. Document them, monitor them, tag ownership, and have a deprecation policy.
• Authorisation at the data layer. Every database query carries the calling principal. Every record returned is filtered by what that principal can see.
• Default deny. New endpoints are unreachable until an authorisation policy is attached.
• Rate limit by default. Even if the limit is generous. An endpoint with no limit is a future incident.
• Use short-lived tokens for machine-to-machine traffic. Rotation built in, scope minimal.
• Test authenticated paths, not just public ones. Most modern API breaches require authentication. Public-only scanning misses them entirely.
• Discover continuously. Static API inventories drift. Daily or hourly comparison against actual traffic is the only reliable approach.
• Log and review. API logs are far richer than traditional web logs. Use them. A user account that fetched ten thousand distinct object IDs in an hour should generate an alert.

API security is not a separate discipline from application security, but it has its own shape. The tools, the failure modes, and the testing approaches are different enough that treating it as "we already do AppSec, we are covered" leaves visible gaps. The breaches that have made news in the past four years are evidence enough.