In November 2022, T-Mobile disclosed that an attacker had pulled personal data on 37 million customer accounts through a single API endpoint that required no additional authentication once a session token was obtained — and the exposure ran for roughly six weeks before anyone noticed. Ten weeks earlier, Optus lost 9.8 million customer records in Australia to an API that didn't require authentication at all. Neither incident involved a novel exploit technique or a zero-day. Both involved a REST endpoint doing exactly what it was coded to do, for anyone who asked. That is the uncomfortable truth about API security in 2026: the OWASP API Security Top 10 has flagged the same handful of failure classes since 2019, and they are still the ones showing up in breach disclosures. This post walks through where REST APIs actually fail, with real incidents and specific mitigations, not generic advice.
What are the most common ways REST APIs actually get breached?
The single largest category is Broken Object Level Authorization (BOLA), listed as API1:2023 in the OWASP API Security Top 10, and it accounts for the plurality of API-specific CVEs tracked by OWASP's own working group since the list's 2019 debut. BOLA happens when an API checks that a request is authenticated but never checks that the authenticated user is authorized to access the specific object referenced in the URL or payload — for example, GET /api/v2/invoices/8841 returning invoice 8841 to any logged-in user, regardless of whether they own it. Salt Security's State of API Security report (Q3 2023) found that 94% of surveyed organizations had experienced an API security incident in the preceding 12 months, and API attack traffic had grown 211% year over year. The remaining top categories — Broken Authentication (API2), Broken Object Property Level Authorization (API3), and Unrestricted Resource Consumption (API4) — round out the incidents that show up in breach reports, but BOLA alone explains why "the API worked correctly" and "the API was insecure" are not the same statement.
How does a Broken Object Level Authorization attack actually work?
A BOLA attack works by incrementing or substituting an object identifier in an otherwise valid, authenticated request and observing whether the server returns data belonging to someone else. The canonical public example is the Peloton API disclosed in May 2021: the /api/user/{userId} endpoint returned full profile data — including age, gender, weight, and location — for any user ID, to any authenticated caller, even when the requesting account had no relationship to the target and even when the target had marked their profile private. Researchers at Pen Test Partners demonstrated pulling data on Peloton's then-3+ million subscriber base simply by iterating sequential numeric IDs. The fix Peloton eventually shipped is the same fix that applies everywhere: every object-fetching endpoint must verify, server-side, on every request, that the authenticated principal is entitled to that specific object — not just that a valid session exists. Sequential integer IDs make this worse because they make enumeration trivial; switching to UUIDs raises the bar for a scripted attacker but does not replace the authorization check itself.
Why do rate limiting and a WAF fail to stop API abuse?
Rate limiting and WAFs fail because they are built to catch volume and known-bad signatures, not business-logic abuse that looks like normal traffic one request at a time. A WAF trained on SQL injection and XSS payloads has nothing to match against a request like GET /api/orders/1002 followed by GET /api/orders/1003 — every request is syntactically valid, properly authenticated, and well within a "reasonable" per-minute threshold. This is precisely how the USPS Informed Visibility API exposure (reported by KrebsOnSecurity in November 2018) went unnoticed for over a year: roughly 60 million user records were queryable by any authenticated account through an API that had no anomaly detection on per-object access patterns, only coarse rate limits. Effective API abuse detection requires behavioral baselining — flagging a user who normally fetches 5 of their own records a day suddenly fetching 5,000 sequential records across other users' ID space — which is a different control than request-per-second throttling and typically sits at the API gateway or in-app layer rather than the network edge.
How should authentication and authorization be structured for REST APIs?
Authentication and authorization should be treated as two separate checks executed on every single request, not a one-time gate at login. For authentication, that means short-lived JWTs (15 minutes or less for access tokens is a common baseline), signature validation using an allow-listed algorithm (explicitly reject alg: none, a bug class that hit multiple JWT libraries between 2015 and 2022 and is still found in code today), and refresh tokens that are rotated and revocable server-side. For authorization, OWASP's API2:2023 and API5:2023 guidance both converge on the same principle: authorization decisions belong in a centralized policy layer — not scattered across if-statements in individual controller methods — using an explicit deny-by-default model, commonly implemented with a framework like OPA (Open Policy Agent) or a scoped OAuth 2.0 model where tokens carry fine-grained scopes (invoices:read:own rather than a blanket invoices:read). The 2019 Facebook/Instagram API bug that let researchers view private account data by manipulating access-token scope checks is the pattern to design against: scopes that exist on paper but aren't enforced at every downstream call are not a control.
How do you find the APIs you don't already know exist?
You find them through continuous discovery against deployed traffic and code, because static documentation is reliably wrong within weeks of being written. Gartner's API security research has repeatedly flagged "shadow APIs" (undocumented, unmonitored endpoints) and "zombie APIs" (deprecated endpoints still reachable in production) as a top driver of API breaches — Salt Security's Q1 2022 report found that 44% of organizations lacked a complete, accurate inventory of the APIs they had exposed. This matters concretely: the Optus breach traced back to a test API endpoint left internet-facing without the authentication that had been applied to its production counterpart. Discovery has to run against three sources simultaneously — live traffic logs (gateway or reverse-proxy access logs), the deployed OpenAPI/Swagger spec versus what's actually reachable, and the source code itself (route definitions, controller annotations) — because relying on any single source will miss the endpoints the other two would have caught.
What should an API security testing checklist actually include before production?
An API security testing checklist should combine authorization-focused dynamic testing with static analysis, because the two catch different bug classes and neither alone covers OWASP's Top 10 for APIs. Concretely: run automated BOLA/BFLA test cases that swap object and role identifiers across every authenticated endpoint (tools like OWASP's own ZAP or commercial API-specific DAST can automate this against a running staging environment); run SAST against the codebase specifically for missing authorization checks and hardcoded secrets in route handlers; contract-test the live API against its OpenAPI spec to catch drift (undocumented fields or endpoints are exactly where shadow-API risk accumulates); and load-test resource-intensive endpoints (file uploads, search, bulk export) against OWASP's API4:2023 (Unrestricted Resource Consumption) with concrete limits — e.g., capping a /export endpoint at 1,000 records per call rather than allowing an unbounded limit query parameter, which is the exact pattern behind several bulk-scraping incidents disclosed against social platforms between 2021 and 2023.
How Safeguard Helps
Safeguard closes the gap between "we found a vulnerable dependency or endpoint" and "we know it's actually exploitable in this API," which is where most API security programs lose signal to noise. Reachability analysis traces whether a flagged authorization or injection weakness sits on a code path an external request can actually reach, so a BOLA-shaped finding in a debug-only route doesn't consume the same triage time as one on /api/v1/orders/{id}. Griffin AI, Safeguard's detection engine, correlates API route definitions, authentication middleware, and object-access patterns across a codebase to surface missing per-object authorization checks — the exact class of bug behind the Peloton and USPS incidents — before merge. Safeguard generates and ingests SBOMs to keep API-adjacent dependency risk (auth libraries, JWT parsers, framework middleware) tied to the same inventory used for endpoint discovery, and where a fix is well-defined — an unenforced scope check, a missing rate limit, a debug endpoint left routable — Safeguard opens an auto-fix pull request so the remediation ships with the same velocity as the finding.