Broken Access Control
Broken access control is a vulnerability class where an application fails to enforce restrictions on what authenticated or unauthenticated users are allowed to do, letting them access data or functions that should be off-limits. It ranks first in the OWASP Top 10 and includes flaws such as insecure direct object references and privilege escalation within an application.
Broken access control refers to any failure in an application to correctly enforce who can do what. When access rules are missing, incomplete or checkable only on the client side, users can reach data and functionality beyond their permission level, whether by viewing another customer’s records, editing resources they do not own, or invoking administrative actions from an ordinary account.
OWASP ranks broken access control as the most prevalent risk in modern web applications, ahead of injection and other classic flaws. The reason is that access control is spread across an entire application: every endpoint, object and action needs a correct check, and a single missing or inconsistent check creates a hole. Automated scanners struggle to find these issues because judging what a given user should be allowed to do requires understanding the application’s business logic.
Common forms include insecure direct object references, where an application uses a user-supplied identifier to fetch a record without verifying ownership, so changing the identifier returns someone else’s data. Others include missing function-level authorisation, where a privileged endpoint is hidden in the interface but not actually protected on the server, and horizontal or vertical privilege escalation, where a user reaches the data of a peer or the powers of an administrator. Forced browsing to unlinked URLs and manipulation of metadata such as JSON Web Tokens also fall in this category.
The impact ranges from data breaches and privacy violations to full account takeover and unauthorised administrative control. Because access-control flaws often expose personal data directly, they carry regulatory weight under regimes such as UK GDPR, in addition to the direct security risk.
Preventing broken access control means enforcing authorisation on the server for every request, denying by default, and deriving a user’s identity and permissions from a trusted session rather than from parameters the user can change. Centralising access-control logic, testing it against a defined permission model, and avoiding reliance on obscurity are all essential, because a well-designed model still fails if it is not consistently applied.
Because access-control flaws so often expose personal data directly, they carry weight beyond the immediate security risk. A single missing ownership check that lets one customer read another’s records can constitute a reportable personal-data breach under regimes such as UK GDPR. This regulatory dimension is part of why broken access control ranks first in the OWASP Top 10 and why it deserves priority attention in any application security programme.
Broken access control is best found by manual testing that reasons about intended permissions and then tries to violate them, which is exactly what a web application penetration test does. Precursor tests access control against the roles and ownership rules your application is meant to enforce, and reports each case where those boundaries can be crossed.