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
Can also be done with known names or object identifiers, even if they are not predictable
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
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
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.
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
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
We can bypass the access controls using a request with special headers
Can be done even when the target URL receives parameters, putting them in our accessible point
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
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
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
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
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
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
Last updated