Broken Access Control: why it remains OWASP number one

Broken Access Control has held the number one position in the OWASP Top 10 since 2021, and the 2025 edition confirms it once more. In the web application penetration tests we perform, it is consistently the category that yields the most findings, and often the most severe. The reason is as simple as it is persistent: nearly every application handles authentication (who are you?) reasonably well, but authorization (what are you allowed to do?) far more carelessly. And it is that second question that determines whether user A can reach user B's data.

What access control actually is

Access control is the set of rules that determines which actions a user may perform and which data they may see. Broken access control arises when those rules are missing, incorrectly implemented, or trivial to bypass. It is almost never about a user cracking their own password; it is about an authenticated user doing more than intended, or an outsider reaching a function that should have sat behind a login.

A crucial distinction is between horizontal and vertical escalation. In horizontal escalation, a user accesses the data of another user at the same privilege level — for example the invoice, record, or message of another customer. In vertical escalation, an ordinary user obtains privileges of a higher level, such as administrator functions. Both are serious, but vertical escalation often hands an attacker the keys to the entire system.

How we attack it during a pentest

Broken access control is precisely the category where the manual expertise of the pentester makes the difference. Our standard approach starts with two test accounts holding different privileges, plus an administrator account where possible. We then systematically probe whether user A can reach everything belonging to user B.

The most productive line of attack is the Insecure Direct Object Reference, or IDOR. Many applications display data based on an identifier in the URL or in an API request, for example /api/invoices/1042. We increment or decrement that number and check whether the application verifies that the requesting user is actually entitled to invoice 1043. Surprisingly often, it does not. We apply the same logic to UUIDs, email addresses, and customer numbers passed along in requests.

A second line is forced browsing: we access admin URLs, export functions, and API endpoints directly, without going through the normal navigation. If /admin or /api/users/export is reachable by an ordinary user, there is a vertical escalation problem. We pay close attention to hidden or unlinked functionality that exists but is insufficiently protected.

A third, subtler line involves manipulable parameters that determine role or context. Think of a hidden form field role=user that we change to role=admin, a cookie or JWT claim that fixes the privilege level, or a parameter that decides on whose behalf an action is performed. Method-based bypasses belong here too: a function that is properly checked when triggered from the interface button, but skips the check when called with a different HTTP method directly (for example PUT instead of GET).

Since the OWASP Top 10:2025, Server-Side Request Forgery (SSRF) also falls under this category. In SSRF, we abuse the server to make requests to internal systems or cloud metadata endpoints that should be unreachable from the outside. It is essentially access control from the server's perspective: the application should not make requests to internal resources on the attacker's behalf.

Why scanners miss this category

An automated vulnerability scan is excellent at finding known vulnerabilities and misconfigurations, but practically blind to broken access control. A scanner does not know that invoice 1042 belongs to customer A and invoice 1043 to customer B; it has no knowledge of the intended authorization matrix. Recognising an IDOR requires understanding of the business logic and of who is allowed to see what. This is exactly why a pentest differs fundamentally from a scan, and why this category stays under the radar without manual investigation.

Concrete impact

The consequences of broken access control are rarely theoretical. In our practice, these findings have led to access to third-party customer records, the ability to modify orders and prices on behalf of other accounts, and access to administrative functionality from an ordinary user account. For organisations processing personal data, an IDOR quickly qualifies as a data breach under the GDPR, with the accompanying notification and documentation obligations.

How to prevent it

The most important design rule is deny by default: every function and every piece of data is protected by default, and access is granted only explicitly. Always enforce authorization on the server side, on every request, and never rely on hidden fields, disabled buttons, or client-side checks — those are trivial to bypass.

Where possible, use ownership checks rather than role checks alone. It is not enough to verify that someone holds the 'user' role; the application must verify that this user owns this specific object. Centralise the authorization logic in a single layer or component instead of scattering checks throughout the codebase, so they remain consistent and testable. Log access failures and alert on patterns that suggest systematic probing. And include access control explicitly in your test cases: a good automated test suite contains scenarios in which user A deliberately attempts to reach user B's data.

From finding to remediation and retest

When we uncover broken access control, we describe not only the vulnerability but also its exploitability and concrete impact per finding — which data or functions were reachable and by whom. The remediation advice targets the underlying cause, not the sealing of a single URL. Because access control problems are often structural, we typically recommend checking comparable endpoints across the entire application. After remediation, a targeted retest follows: only when it is verifiable that the bypass no longer works, and that the fix has not been forgotten elsewhere, do we consider the finding closed.

Secure Audit performs web application penetration tests combining automated tooling with manual investigation, with particular attention to authorization and business logic. Get in touch for a no-obligation conversation about the scope of a pentest for your application.