What Is Broken Access Control?

Broken access control occurs when a web application fails to properly enforce what users are allowed to access or what actions they are allowed to perform.

It can allow users to access sensitive information, functionality or accounts that should be restricted to them. In serious cases, broken access control can result in unauthorised access to other users' data, administrative functions or entire systems.

What Is Access Control?

Access control is the process of determining who is allowed to access something and what they are allowed to do with it.

For example, an application might have different types of users:

• Standard customers
• Managers
• Administrators
• Support staff

A standard customer might be allowed to view their own account and orders, while an administrator might be allowed to manage users and configure the application.

The application needs to enforce these rules every time a user attempts to access protected functionality or data.

If those controls can be bypassed, the application may have a broken access control vulnerability.

What Does Broken Access Control Look Like?

Consider an administration page:

https://example.com/admin/users

A normal customer should not be able to access this functionality.

If the application relies on the interface simply hiding the administration link, an attacker could potentially navigate directly to the URL.

If the server fails to check the user's privileges and returns the administration page, the access control has been bypassed.

The same principle applies to APIs.

An application might prevent a standard user from seeing an administrative function in its web interface while still allowing the underlying API request to be made directly.

This is why security controls must be enforced server-side, rather than relying on what the user interface displays.

Common Types of Broken Access Control

Broken access control can take several forms.

Vertical Privilege Escalation

This occurs when a lower-privileged user can access functionality intended for a more privileged user.

For example, a standard customer might gain access to an administrative function.

Horizontal Privilege Escalation

This occurs when a user can access resources belonging to another user with the same level of privileges.

For example, Customer A might be able to view Customer B's invoices.

This is closely related to IDOR (Insecure Direct Object Reference) vulnerabilities.

Unauthorised Function Access

An application might restrict access to certain functionality through its interface but fail to enforce the restriction on the server.

An attacker could therefore directly request the restricted endpoint.

Missing Access Controls on APIs

Modern applications frequently use APIs to handle data and functionality.

If API endpoints do not correctly enforce authentication and authorisation, an attacker may be able to interact with functions that should be restricted.

Multi-Tenant Access Control Failures

Applications used by multiple organisations need to maintain strict separation between tenants.

A vulnerability that allows one customer to access another customer's data can have significant consequences.

Authentication Isn't the Same as Authorisation

A common mistake is to assume that because a user is authenticated, they should be allowed to access a resource.

Authentication answers:

Who are you?

Authorisation answers:

What are you allowed to access or do?

For example, successfully logging into a customer portal proves that the user has authenticated.

It does not mean that the user should be able to access another customer's account.

Every protected resource and sensitive action therefore needs appropriate authorisation checks.

Why Is Broken Access Control Dangerous?

Broken access control can expose some of the most sensitive functionality within an application.

Depending on the vulnerability, an attacker could potentially:

• View another user's personal information
• Access confidential documents
• Modify customer records
• Change account permissions
• Access administrative functionality
• Delete data
• Perform actions as another user
• Cross tenant boundaries
• Access sensitive API functionality

The impact can therefore range from a relatively limited information disclosure to complete compromise of an application's data or functionality.

How Do Penetration Testers Identify Broken Access Control?

Testing access control requires more than simply scanning an application for known vulnerabilities.

A penetration tester will typically assess the application using accounts with different roles and levels of privilege.

For example, a tester might create:

• A standard user account
• A second standard user account
• A privileged user account

The tester can then determine whether each account can access functionality and data belonging to the others.

Testing may include attempting to:

• Access restricted URLs directly
• Manipulate API requests
• Change object identifiers
• Access another user's resources
• Perform administrative functions
• Modify or delete unauthorised data
• Bypass restrictions implemented in the user interface
• Cross organisational or tenant boundaries

The objective is to determine whether the application's actual security controls match its intended permission model.

How Can Organisations Prevent Broken Access Control?

Access control should be designed and implemented as a fundamental part of the application's security architecture.

Important measures include:

• Enforce authorisation on the server side
• Apply least-privilege principles
• Deny access by default
• Check permissions on every sensitive request
• Avoid relying on client-side controls
• Implement consistent access control across APIs and web interfaces
• Maintain strict separation between tenants
• Test different user roles during development
• Log and monitor suspicious access attempts

Developers should also avoid assuming that hiding functionality from a user is sufficient protection.

If a sensitive function exists on the server, the server must independently verify whether the requesting user is authorised to use it.

Can Automated Scanning Detect Broken Access Control?

Automated vulnerability scanners can identify some access control weaknesses, but they have significant limitations.

A scanner may identify endpoints, parameters and other potentially interesting functionality. However, understanding whether a particular user should be allowed to perform a particular action often requires knowledge of the application's intended roles and permissions.

For example, a scanner might discover an API endpoint that returns customer information.

It may not know that Customer A should only be able to retrieve their own information and must not be able to retrieve Customer B's data.

This is why manual testing and authenticated testing are particularly important when assessing access control.

Broken Access Control and Web Application Penetration Testing

Broken access control is one of the key areas that should be assessed during a comprehensive web application penetration test.

A penetration tester can approach the application from the perspective of different users and deliberately attempt to cross the boundaries between them.

This can reveal weaknesses that automated vulnerability scanning may miss, particularly where the vulnerability depends on the application's specific business logic.

For organisations handling sensitive data or operating multi-user or multi-tenant applications, testing these controls can be particularly important.

Conclusion

Broken access control occurs when an application fails to properly enforce the permissions that determine what users can access or what actions they can perform.

It can result in unauthorised access to data, functionality or administrative features and is a common source of serious web application vulnerabilities.

Strong server-side authorisation, least-privilege principles and appropriate security testing are essential for reducing the risk.

Regular web application penetration testing can provide an independent assessment of whether those controls actually work as intended, rather than simply assuming that they do.