Broken Access Control Owns Everything: Why OWASP's #1 Vulnerability Still Wrecks Apps in 2026

For two consecutive releases of the OWASP Top 10, Broken Access Control has held the number one position. The 2021 data showed that 100% of applications tested exhibited some form of access control failure — though severity ranged from minor to catastrophic. Meanwhile, Broken Object Level Authorization (BOLA) has been the #1 API security risk since 2019. The attack is trivially simple: change a number in a URL and access someone else's data. The fix is conceptually straightforward. And yet the problem is getting worse, not better. Here's why.

There is something deeply embarrassing about the state of access control in modern applications. We've solved infinitely harder security problems. We have mature encryption libraries, hardware security modules, sophisticated network segmentation tools, and AI-powered threat detection platforms. And yet the single most common vulnerability in web applications is: the server didn't check whether you're allowed to see that data before showing it to you.

What Broken Access Control Actually Means

Access control is the enforcement of rules about who can do what with which resources. When it works, a regular user can't access admin functions, User A can't read User B's data, and an unauthenticated visitor can't access protected endpoints. When it fails — and the OWASP data says it fails everywhere — attackers can bypass authorization to escalate privileges, view or modify other users' data, or gain unauthorized access to administrative functions.

The anticipated OWASP 2025 Top 10 update has signaled it will expand the Common Weakness Enumerations (CWEs) covered under Broken Access Control, and notably roll Server-Side Request Forgery (SSRF, previously ranked #10 in 2021) into this category. The committee's reasoning: SSRF is fundamentally an access control bypass — tricking a server into accessing resources the requester shouldn't reach. This consolidation signals a broader understanding that access control failures come in many forms, but they all share the same root cause: the application trusts the requester without verifying their authorization.

The vulnerability manifests through several common patterns. Insecure Direct Object References (IDOR), where an attacker modifies an identifier in a request to access another user's resources — horizontal escalation, moving laterally between accounts at the same privilege level. Privilege escalation, where a regular user accesses administrative functions by navigating directly to a protected endpoint that the UI hides but the server never actually restricts — vertical escalation, jumping up the privilege hierarchy. Missing function-level access controls, where sensitive API endpoints accept any authenticated request regardless of role. And forced browsing, where an attacker directly navigates to URLs the application assumes will stay hidden. In each case, the root failure is the same: the server assumed that if you got here, you're allowed to be here.

BOLA/IDOR: The Simplest Attack That Still Works

BOLA (Broken Object Level Authorization) is the most common specific flavor of broken access control, and IDOR (Insecure Direct Object Reference) is its most recognizable implementation pattern. IDOR describes the specific technique — manipulating an object identifier in a request to access unauthorized data — while BOLA describes the broader authorization failure that makes such manipulation successful. BOLA has been the #1 risk in the OWASP API Security Top 10 since the list was created in 2019, and it maintained that position in the 2023 edition.

The attack is almost insultingly simple. Consider an API endpoint: GET /api/orders/1001. If you're User A and this is your order, the server returns your order data. Now change the ID: GET /api/orders/1002. If the server returns User B's order without checking whether you're authorized to see it, that's BOLA. No exploits, no payload crafting, no special tools — just incrementing a number.

The problem extends beyond sequential integer IDs. Some developers believe that using UUIDs or hashed identifiers prevents BOLA because attackers can't guess the values. This is security through obscurity, and it fails because UUIDs leak through URLs, logs, error messages, email links, browser history, and API responses. Once an attacker obtains a valid UUID from any of these sources, the same BOLA vulnerability is fully exploitable.

Why Automated Scanners Can't Save You

This is the core reason broken access control persists as the number one vulnerability despite decades of awareness. Unlike SQL injection or XSS, which follow recognizable syntax patterns that static analysis tools can detect, access control is a business logic problem. SAST tools can't determine whether /api/invoices/12345 should be accessible to the current user because that answer depends on business rules, data relationships, and organizational context that exist outside the codebase.

DAST tools face the same problem from a different angle. When a dynamic scanner sends a request to /api/orders/1002 and receives an HTTP 200 response with user data, it sees a successful request — not a data breach. The tool doesn't understand the business rule that says Order #1002 belongs to User B, so User A accessing it is unauthorized. Automated tools are like the dog in Conan Doyle's "The Adventure of Silver Blaze" — they don't bark at the intruder because they don't recognize them as one.

This means access control testing fundamentally requires human judgment. Manual penetration testing, multi-profile API testing (making the same requests from different user contexts), and business-logic-aware security reviews are the only reliable ways to find these vulnerabilities. And they're expensive, time-consuming, and hard to scale.

Real-World Breaches: Instagram, Optus, Peloton

BOLA vulnerabilities have affected some of the world's largest platforms. In 2019, researchers discovered that Instagram's backend APIs returned private user data — posts and stories set to private — when object IDs were manipulated in API requests, regardless of the requester's relationship to the account owner. Instagram patched the vulnerability after disclosure.

In September 2022, Australian telecommunications company Optus suffered a catastrophic breach when an attacker exploited an IDOR vulnerability to directly access and enumerate nearly 10 million customer records. The breach exposed names, dates of birth, phone numbers, email addresses, and in some cases passport and driver's license numbers. The simplicity of the exploit — iterating through sequential identifiers — was staggering for a company of that scale.

Peloton's API vulnerabilities, disclosed in 2021, allowed researchers to access private user data including workout history, profile information, and real-time location data — even when user profiles were explicitly set to private. The backend APIs simply didn't enforce the privacy settings visible in the UI. This is the gap between authentication (knowing who you are) and authorization (checking what you're allowed to see) in its purest form.

The API Explosion Made It Worse

Modern applications are built on APIs. A single web application might expose dozens or hundreds of endpoints, each accepting object identifiers and returning data. Every single one of those endpoints is a potential BOLA attack surface. The shift to microservices architecture has multiplied this exponentially — each microservice has its own set of endpoints, its own data access patterns, and its own authorization logic (or lack thereof).

The rise of Non-Human Identities (NHIs) — service accounts, API keys, automated agents, and ephemeral workloads — adds another layer of complexity. NHIs now outnumber human users in many enterprise environments, and the access control models designed for human users don't map cleanly to machine-to-machine authentication. When an AI agent makes an API call on behalf of a user, does the authorization check verify the agent's permissions, the user's permissions, or both? The answer should be both: scoped API keys with explicit resource permissions, per-service authorization policies, and regular audits of which NHIs have access to what. The same default-deny principle applies — a service account should only be able to access exactly what it needs, nothing more.

The anticipated OWASP 2025 update has signaled this expanding complexity by broadening the CWEs under the Broken Access Control category. The message is clear: the problem isn't getting simpler, and the attack surface isn't getting smaller.

How to Actually Fix It

1. Default deny. Every endpoint should deny access by default. Access is explicitly granted, never implicitly assumed. If a permission check is missing, the result should be a 403, not a data leak.
2. Check authorization on every request. OWASP's API Security guidance is explicit: perform object-level authorization checks in every function that accesses a data source using a user-supplied identifier. Every request. No exceptions.
3. Don't trust client-supplied identifiers. Never use user_id, org_id, or tenant_id values from the request payload as authoritative. Derive the user's identity and scope from the authenticated session context and server-side lookups.
4. Use indirect object references. Rather than exposing internal database IDs in URLs and API responses, map public-facing tokens (e.g., order_ref=xk9a2b) to internal identifiers server-side. This eliminates enumeration as an attack vector, though it must be paired with proper authorization checks — obscurity alone is not security.
5. Centralize authorization logic. Scattered, ad-hoc permission checks throughout the codebase are how authorization gaps happen. Use centralized authorization frameworks (like OPA, Casbin, or Auth0 FGA) that define policies in one place and enforce them consistently — for both human users and machine-to-machine API calls.
6. Test with multiple user profiles. Configure your security testing to make the same API calls from different user contexts. If User A can access User B's resources, your authorization is broken regardless of what the UI shows. Also test vertical escalation: verify that regular user sessions cannot reach admin-only endpoints.
7. Implement row-level security at the database layer. Where supported, use database row-level security (RLS) policies to enforce ownership constraints close to the data. This provides a safety net when application-level checks fail.
8. Log and monitor access patterns. Unusual access patterns — a single user accessing thousands of sequential object IDs — should trigger alerts. This is both a detection mechanism and a deterrent.

Key Takeaways

1. It's #1 for a reason: Broken Access Control topped the OWASP Top 10 in 2021 and is widely expected to hold that position in the forthcoming 2025 release, with 100% of tested applications showing some form of the vulnerability — though severity varies greatly. This isn't a niche problem — it's universal.
2. Automated tools can't find it: SAST and DAST tools lack the business context to identify authorization failures. Finding these vulnerabilities requires manual testing, multi-profile scanning, and human judgment.
3. Authentication is not authorization: A valid session token proves identity. It does not prove permission. Every endpoint must independently verify that the authenticated user is authorized to access the specific resource being requested.
4. APIs multiplied the attack surface: Every API endpoint that accepts an object identifier is a potential BOLA target. Microservices, NHIs, and AI agents are making the authorization landscape more complex, not less.
5. Fix it architecturally, not endpoint by endpoint: Centralized authorization logic, default deny policies, and database-level enforcement are the only approaches that scale. If authorization is an afterthought, it will have afterthought-quality results.

Broken access control is the security industry's most persistent embarrassment. The vulnerability is conceptually simple, the fix is well-understood, and yet it dominates every survey, every penetration test, and every breach analysis year after year. The problem isn't that we don't know how to build proper authorization. It's that we keep choosing not to — because it's hard, it's tedious, and it requires thinking about business logic at every layer of the application. Until that changes, BOLA will remain the easiest way to own an application, and Broken Access Control will keep its crown as OWASP's number one.