Broken Access Control

Authentication versus Authorization

It is crucial to distinguish two concepts that are often confused. Authentication answers "who are you?"; authorization answers "what are you allowed to do?". Access control is the implementation of authorization: the rules that determine which resources and actions each user can use. When these rules are absent, incomplete, or applied incorrectly, we have broken access control.

The OWASP Top 10 places Broken Access Control in first position (A01:2021), because it is the most widespread and frequently exploited vulnerability category. The reason is that access control depends on each application's specific business logic: there is no generic patch, and it is very easy to forget to protect some endpoint or to verify ownership of a resource.

IDOR: Insecure Direct Object References

IDOR (Insecure Direct Object Reference, CWE-639) is one of the most common forms of broken access control. It occurs when an application exposes a direct reference to an internal object (such as a numeric identifier in the URL) and uses that value to access a resource without verifying that the current user has the right to see it.

For example, if when viewing your invoice the URL contains invoice?id=1024 and the application simply returns the invoice with that identifier without checking that it belongs to you, changing the number to 1025 could show you someone else's invoice. The conceptual mechanism is simple: the server trusts a user-controlled parameter to decide which data to deliver, without a server-side authorization check. IDORs can affect reading, modifying, or deleting other people's data, and they are easy to discover with a proxy like Burp Suite by observing the identifiers in requests.

Privilege Escalation

Horizontal privilege escalation occurs when a user accesses the resources of another user at the same level: for example, reading the private messages of another customer account. IDOR is often the vehicle for this kind of escalation. The attacker gains no more power, but does gain access to data that is not theirs.

Vertical privilege escalation is more serious: a user with few permissions manages to perform actions reserved for higher roles, like a normal user accessing the admin panel. This usually happens when the application hides administrative functions in the interface but does not protect them on the server, wrongly assuming that "if the button is not visible, no one can call the function." An attacker who knows or guesses the URL of the administrative endpoint can invoke it directly. Remember the principle: security cannot depend on hiding functionality in the client.

Other Broken Access Control Patterns

Beyond IDOR and escalation, there are other frequent patterns. Forced browsing consists of directly accessing URLs or files not linked from the interface, discovering panels or resources believed to be hidden. Metadata manipulation occurs when an attacker modifies a token, a cookie, or a field (for example a role=user field) to elevate their permissions.

Also included here are problems of misconfigured CORS that allow unauthorized sites to consume protected APIs, and flaws where an API trusts client parameters to decide the role or tenant. The common denominator of all these cases is the same: the authorization decision is made in a manipulable place or not made at all. Each sensitive action must explicitly ask "does this user, at this moment, have the right to do this on this specific resource?".

How to Prevent Broken Access Control

The golden rule is to deny by default: no action should be allowed unless there is an explicit check that authorizes it. Centralize the access control logic in a single reusable component instead of scattering ad-hoc checks throughout the code; this makes it harder to forget one. Always verify on the server that the authenticated user owns the resource or has the required role, on every request, without trusting whatever the client sends.

Adopt a clear access control model, such as RBAC (role-based) or ABAC (attribute-based), and apply the principle of least privilege. Avoid exposing predictable identifiers where possible, or at least do not use them as the sole access criterion. Test access control systematically: with several accounts of different privilege, try to access cross resources using Burp Suite or OWASP ZAP. Access control is hard to fully automate, so manual review and targeted testing are irreplaceable for finding IDOR and escalation flaws.