Broken Access Control has claimed the top spot in the OWASP Top 10 since 2021, and for good reason.
Unlike many vulnerability classes that require chaining complex exploits, access control failures are often surprisingly straightforward: increment an ID parameter, drop a privilege header, or request a URL you weren’t supposed to know existed.
The consequences, however, are anything but small.
From mass data exposure to full account takeover, the blast radius can be catastrophic. This article will dive into the mechanics of broken access control, examine how attackers exploit it to gain access to your sensitive information, and equip security professionals with the detection and remediation strategies needed to close the gap.
What Is Broken Access Control?
Access control is the mechanism by which an application enforces who can do what.” It sits downstream of authentication and governs every resource request, action, and data operation a user performs after logging in.
By that logic, broken access control vulnerabilities occur when applications fail to restrict user actions to authorised permissions, allowing attackers to access unauthorised data, manipulate content, or gain administrative rights.
Authentication vs. Authorisation: Know the Difference
| Authentication | Authorisation | |
|---|---|---|
| Question asked | Who are you? | What are you allowed to do? |
| Mechanism | Passwords, MFA, tokens | Roles, permissions, ACLs, policies |
| Failure result | Impersonation | Privilege escalation, data exposure |
| When it runs | Login/session start | Every subsequent request |
Access control breaks when authorisation checks are absent, irregularly applied, or enforced client-side rather than on the server. Authentication may be perfectly intact, and the user is exactly who they claim to be, yet the user can still reach data or functions they were never meant to access.
OWASP Ranking: No Small Threat
Broken Access Control holds the #1 position in the OWASP Top 10 (2021), present in 94% of applications tested, the highest of any category.
It climbed from #5 in 2017, reflecting both improved detection tooling and the immensity of the flaw across modern web architectures. This only emphasises why access control vulnerabilities are no small threat, and should be treated as a severe security risk to web application security and any sensitive data held by your organisation.
Common Broken Access Control Attacks And Access Control Flaws
Attackers bypass access controls and take advantage of access control vulnerabilities through a number of malicious strategies. Here are some of the key methods malicious attackers use to gain administrative access and enact data theft:
Exploiting Endpoints and Hidden APIs
Endpoint Discovery Testing
Endpoint discovery testing identifies all accessible API routes, including undocumented ones not intended for public use. Tools such as Burp Suite and ffuf enumerate hidden paths by brute-forcing common route patterns. A tester might uncover /api/v1/admin/users simply by iterating over standard prefixes, exposing privileged functionality that developers assumed was obscure enough to be safe.
Server-Side Authorisation Check Omission
This occurs when access restrictions exist only at the UI layer, with no corresponding validation on the underlying API. A standard user sending DELETE /api/v1/users/42 directly, bypassing the hidden admin button entirely, will succeed if no server-side role check is present. This vulnerability contributes to a significant proportion of OWASP API Security Top 10 findings in real-world penetration tests.
URL Manipulation and Parameter Tampering
Demonstrating URL Parameter Tampering
Parameter tampering modifies query strings or path values to alter application behaviour beyond intended boundaries. Changing discount=0 to discount=100, or role=user to role=admin, can grant unauthorised access if the server accepts client-supplied values uncritically. Signed parameter tokens, strict input validation, and server-side enforcement are the primary defences against this class of attack.
IDOR as a Related Technique
Insecure Direct Object References are a closely related and frequently exploited consequence of parameter tampering. Where general tampering targets application logic, IDOR targets the identifiers referencing server-side objects.
An attacker changing accountId=5523 to accountId=5524, for example, may successfully retrieve another user’s financial records if ownership is not verified server-side, a vulnerability central to several high-profile breaches affecting millions of individuals.
Insecure Direct Object References (IDOR)
The Ownership Verification Test
This simple test checks if an application properly verifies whether a user is allowed to access a specific object. The tester logs in as User A, captures a request with a resource ID, then tries the same request while logged in as User B.
If User B can access or change User A’s resource, it means the ownership check failed. This test should be done on all endpoints that accept object IDs, like profiles, files, messages, and transactions.
Object-Level Authorisation Checks
These server-side controls validate, for every request, whether the authenticated user has explicit permission to interact with the specific object referenced. Implemented at the data access layer rather than the controller layer, they ensure no bypass path exists regardless of how a request is constructed.
Relying on obscure identifiers or UI-level restrictions alone is insufficient and consistently exploited in practice.
Privilege Escalation and Broken Access Control Vulnerabilities
Vertical Privilege Escalation Scenario
Vertical privilege escalation occurs when a lower-privileged user accesses functionality reserved for higher-privileged roles. A common scenario involves a standard user discovering an administrative endpoint such as POST /api/admin/createUser and submitting a valid payload.
Without role-based access validation, the request succeeds, granting administrative control. This vulnerability frequently emerges in applications that expand functionality rapidly without revisiting access control architecture.
Role Tampering Test Method
This method involves modifying role or permission indicators within request bodies, headers, or cookies to assess whether the server accepts client-supplied privilege claims. A tester might decode a JWT payload containing “role”: “user”, modify it to “role”: “admin”, and resubmit.
If cryptographic signature validation or server-side role verification is absent, the elevated role is accepted, confirming that trust has been incorrectly placed in client-controlled data.
Session, Token, and Authentication Controls Attacks
Token Replay and Forgery Tests
Token replay testing assesses whether an application honours tokens beyond their intended expiry window. A tester captures a valid bearer token, waits for the documented expiry period, then re-submits it.
Forgery testing examines whether tokens can be constructed using known weaknesses, such as switching JWT algorithms to none or guessing weak symmetric keys. Both techniques are critical authentication assessment components and are commonly found to be insufficiently controlled.
Verifying Session Binding and Expiration
Session binding confirms that authenticated sessions are tied to specific contextual attributes, such as device fingerprint or user agent, limiting the exploitability of token theft. Expiration verification ensures sessions terminate after defined inactivity and absolute lifetime thresholds.
Testers should confirm that logout invalidates the server-side session record entirely, not merely deleting the client-side cookie, as server-side persistence leaves applications vulnerable to replay attacks using intercepted credentials.
How To Prevent Broken Access Control Vulnerabilities
| Category | Control | Description | Example |
|---|---|---|---|
| Foundational Principles | Deny by default | Block all access unless explicitly permitted. Never rely on hiding endpoints as a security measure. | A new API endpoint returns a 403 error automatically until access rules are defined and applied. |
| Foundational Principles | Centralised access policies | Manage all access decisions from one place rather than writing permission checks individually across your codebase. | One shared policy service handles all authorisation, so rules are consistent across the entire application. |
| Foundational Principles | The principle of least privilege | Give users and services only the access they need to do their job, nothing more. | A reporting user can view data but cannot edit or delete anything, even on platforms where other users can. |
| Foundational Principles | Regular access control checks | Check permissions on a regular schedule to catch accounts that still have access they no longer need. | A quarterly review identifies former employees or those with changed roles who still hold admin-level permissions. |
| Server-Side Authorisation | Check every endpoint | Validate permissions on the server for every request, not just in the user interface. | An admin-only route returns 403 to a standard user even when accessed directly via an HTTP request tool. |
| Server-Side Authorisation | Enforce within each service | Each service checks its own permissions rather than trusting that a gateway has already done so. | A payments service validates the caller’s role independently, even when the request comes from another internal service. |
| Session and Authentication | Short-lived tokens | Keep token expiry windows short and allow them to be cancelled server-side when needed. | A token set to expire after 15 minutes is immediately invalidated on logout, blocking any intercepted copies from being reused. |
| Session and Authentication | Step-up authentication | Require an extra verification step before allowing sensitive actions, even for logged-in users. | Moving money from an account prompts a one-time passcode, regardless of how recently the user logged in. |
| Session and Authentication | Bind tokens to the user’s device | Tie tokens to device or network attributes so they cannot be used if stolen and replayed elsewhere. | A session token captured from one browser fails when submitted from a different device or network. |
| RBAC and ABAC Policies | Use specific, narrow roles | Design roles around what people actually need rather than creating broad permissions to cover multiple use cases. | A regional manager can only access data for their own territory, restricted by an attribute rule rather than a separate role. |
| RBAC and ABAC Policies | Document every policy | Record what each role can access and why, so there is no ambiguity during development or security reviews. | A permissions log maps every role to the specific endpoints and data fields it is allowed to reach. |
| RBAC and ABAC Policies | Automate role changes | Connect role assignment and removal to your HR or identity system so access is updated without manual steps. | When an employee leaves, all their tokens and roles are removed automatically within minutes of the change being recorded. |
| Testing and Monitoring | Test authorisation in code | Write automated tests that confirm each endpoint correctly allows or blocks requests based on the caller’s role. | A test suite checks that a standard user account receives a 403 response on every admin-level endpoint. |
| Testing and Monitoring | Test cross-user access | Actively attempt to access another user’s or tenant’s data during testing to confirm ownership checks are working. | A test logs in as one tenant and requests data belonging to another, confirming the response returns nothing. |
| Testing and Monitoring | Log and alert on denials | Record every blocked request with enough context to investigate, and alert when unusual patterns appear. | A sudden increase in 403 responses from one account triggers a security alert for the team to review. |
Practical Checklist For Developers And AppSec Teams
- Add authorisation tests to your CI pipeline. Automatically verify that protected endpoints return the correct response for both permitted and unpermitted callers on every pull request.
- Maintain an inventory of public endpoints. Document every externally accessible route, including legacy and third-party integrations, so access control coverage can be verified against a known baseline.
- Schedule quarterly role entitlement reviews. Permissions accumulate as teams and responsibilities change; regular reviews catch orphaned and over-privileged accounts before they become exploitable.
- Log every access control failure. Capture user identity, endpoint, timestamp, and request origin on every denied request so that privilege escalation attempts do not go undetected.
- Run authorisation-focused penetration tests. Source dedicated testing that systematically attempts privilege escalation, IDOR exploitation, and role tampering, at least annually and after significant architectural changes.
Defend against broken access control vulnerabilities with OnSecurity’s pentesting services
Don’t let broken access control risks get the better of your organisation. Regularly review access control policies, implement proper error handling and session management, and ensure user permissions are scoped to what individuals’ roles actually require.
OnSecurity’s platform-based penetration testing services support businesses in enforcing secure session management and highlighting any access control weaknesses to fortify your cybersecurity.
Get in touch today for an instant quote to find out more.
