In May 2019, First American Financial Corporation exposed 885 million title insurance documents — bank account numbers, Social Security numbers, mortgage records — because anyone who guessed a sequential document ID in a URL could pull up someone else's file without logging in. No exploit, no malware, just a broken access control. In OWASP's 2021 Top 10, broken access control jumped from the fifth most common web application risk to the first, appearing in 94% of applications tested across more than 318,000 recorded occurrences. It's not an exotic vulnerability class. It's a design failure: the application checks who you are but forgets to check what you're allowed to touch. For security teams shipping code weekly, that gap is one of the cheapest for attackers to find and one of the most expensive to clean up after the fact.
What is broken access control?
Broken access control happens when an application fails to properly enforce restrictions on what authenticated (or unauthenticated) users can view, modify, or execute. Access control is supposed to answer "is this specific user allowed to perform this specific action on this specific resource" — broken access control means the check is missing, misconfigured, or trusts data (like a role or ID) that the client can manipulate. OWASP's Application Security Verification Standard maps 34 distinct CWEs into this single category, more than any other Top 10 entry, spanning everything from insecure direct object references (CWE-639) to missing function-level authorization (CWE-862) to path traversal (CWE-22). The common thread across all 34 is the same: the server trusted something it shouldn't have.
Why did broken access control become the #1 OWASP risk in 2021?
It became #1 because of scale and detectability, not novelty. In the OWASP Top 10 2021 report, contributed testing data showed an average incidence rate of 3.81% for this category — the highest of any of the ten — across 94% of applications assessed showing at least one form of it. Compare that to injection, which held the top spot in 2013 and 2017 but dropped to #3 in 2021 as parameterized queries and ORMs became default practice. Access control has no equivalent silver bullet. Every application has a bespoke authorization model — who owns what, which roles can escalate which records — and that logic has to be re-implemented and re-tested on every new endpoint, every new microservice, every new API version. Frameworks solved SQL injection with abstraction; nobody has solved "does user 4471 own order 8823" with a library.
What are the most common forms of broken access control in production code?
The most common form by far is the Insecure Direct Object Reference (IDOR), where an application exposes an internal identifier — a sequential user ID, an incrementing invoice number, an unencoded UUID — and lets a request substitute another user's ID without re-checking ownership. Close behind are: horizontal privilege escalation (User A reads or edits User B's data at the same permission tier), vertical privilege escalation (a standard user reaches an admin-only endpoint because the check exists on the UI but not the API), missing function-level access control (an API route has no authorization middleware at all, only a hidden link in the frontend), and CORS misconfigurations that allow any origin to make authenticated cross-site requests. In late 2018, USPS's Informed Delivery API let any logged-in user query account details, including real names and mailing addresses, for any of USPS's roughly 60 million registered users, because the API validated authentication but never validated that the requester owned the account being queried — a textbook IDOR at national scale.
What real-world breaches trace back to broken access control?
Beyond First American and USPS, the January 2021 Parler breach is the clearest large-scale example: researchers scraped roughly 70 terabytes of user posts, videos, and location metadata in the days before the platform went offline, made possible because post IDs were sequential and the API enforced no per-post authorization check, letting automated scripts iterate through billions of IDs. In April 2023, CVE-2023-27350 in PaperCut MF/NG let unauthenticated attackers reach an internal API endpoint intended only for the built-in admin user, because the access control on that endpoint checked a request parameter the client controlled rather than an authenticated session — CISA added it to the Known Exploited Vulnerabilities catalog within weeks after ransomware groups including Cl0p and LockBit weaponized it against dozens of organizations. Each case has the identical root cause: an authorization decision that lived in the wrong place, or didn't exist at all.
How can engineering and security teams find broken access control before attackers do?
You find it by testing authorization per-object and per-role, not just per-endpoint, because standard SAST and DAST scanners routinely miss it. Static analysis tools are good at spotting a missing @RequiresAuth annotation but bad at knowing that the GET /api/invoices/{id} route needs a tenant-scoped ownership check rather than just a valid session token — that context lives in business logic, not syntax. Effective detection combines authenticated dynamic testing where the same request is replayed with a second, lower-privileged account's token substituted in (the fastest way to surface IDOR and horizontal escalation), code review focused on where authorization middleware is applied versus where it's assumed, and reachability analysis that traces whether an exposed API route actually has a live, unauthenticated path to a sensitive data model. Manual and automated pen testing still catch things scanners don't, which is part of why access control remains chronically underreported by tooling relative to how often it appears in real breaches.
How Safeguard Helps
Safeguard's reachability analysis traces whether a vulnerable or under-protected code path — including missing authorization checks on API routes and data-access functions — is actually exploitable from an external entry point, rather than flagging every endpoint equally. Griffin AI reviews pull requests for authorization logic changes, flagging patterns like client-controlled role parameters, missing ownership checks on object IDs, and endpoints added without corresponding access-control middleware, before they merge. Safeguard's SBOM generation and ingest pipeline tracks which third-party libraries and frameworks handle authorization in your stack, so a CVE like PaperCut's access-control bypass surfaces against your actual deployed inventory instead of a generic advisory feed. Where a fix pattern is well-established — adding an ownership check, correcting a route's middleware chain — Safeguard can open an auto-fix PR directly, cutting the time between detection and a merged remediation.