What Is Broken Access Control?

Broken access control is a security flaw that lets a user or system access data, functions, or resources they should not be allowed to reach. In practice, broken access control means an application fails to properly enforce authorization rules after a user is authenticated, which can lead to data exposure, privilege escalation, or unauthorized actions.

If you are exploring related web security concepts, it also helps to read what is idor and what is authentication vs authorization.

Broken access control definition

Access control answers a basic question: who is allowed to do what? A secure application should verify, on every relevant request, whether the current user is permitted to view a record, modify a setting, download a file, or perform an administrative action.

Broken access control happens when those checks are:

Missing
Incomplete
Inconsistent
Easy to bypass

In short, the application trusts the user too much.

Authentication vs authorization

This distinction matters because teams often confuse the two.

Authentication confirms who the user is
Authorization determines what that user is allowed to access

A user may log in successfully and still have no right to view another customer’s records or call an admin-only function. Broken access control occurs when the application treats “logged in” as enough permission.

How broken access control works

Broken access control can appear in several ways across web apps, APIs, mobile back ends, and internal systems.

Accessing someone else’s data

A classic example is changing a value in a URL or API request, such as an account number, order ID, or document reference, and receiving data for another user.

For example:

/invoice/10025 becomes /invoice/10026
/api/user/123/profile becomes /api/user/124/profile

If the application returns the second user’s data without checking ownership, access control is broken.

Reaching admin-only features

Some applications hide admin buttons in the interface but do not protect the underlying endpoint. A regular user may be able to manually browse to an admin page or send the same request directly to the server.

Front-end controls are not enough. The server has to enforce the rule.

Privilege escalation

Broken access control can allow a user to perform actions above their assigned role, such as:

Promoting their own account
Resetting another user’s password
Modifying pricing, permissions, or security settings
Exporting data intended only for administrators

This may be:

Vertical privilege escalation, where a normal user gains admin capabilities
Horizontal privilege escalation, where one user accesses another user’s data at the same privilege level

Forced browsing and direct object access

Attackers often test whether hidden URLs, filenames, object IDs, or API endpoints are still reachable if they guess or manipulate them. If the application relies on obscurity rather than real permission checks, those resources may be exposed.

API authorization failures

Modern applications often expose APIs for web apps, mobile apps, or partner integrations. Broken access control frequently appears in APIs when developers trust client-side logic, assume a token implies broad access, or fail to validate object ownership on each request.

Why broken access control happens

Broken access control usually comes from design or implementation mistakes, including:

Missing server-side authorization checks
Overly permissive default roles
Inconsistent rules between pages, APIs, and background services
Trusting hidden fields, client-side logic, or browser controls
Reusing code without object-level permission checks
Complex role models that are hard to enforce consistently
Failure to test unauthorized access paths

In many environments, the issue is not one dramatic bug. It is a collection of small assumptions that add up to unauthorized access.

Why broken access control is dangerous

The impact can be severe because access control sits directly between users and sensitive resources. A broken control may expose:

Customer records
Financial information
Internal documents
Administrative capabilities
Security settings
Source code or business data

Unlike some vulnerabilities that require chaining multiple flaws together, broken access control often creates direct business risk immediately.

Common examples

Here are a few realistic examples of broken access control:

A customer changes a URL parameter and sees another customer’s invoice
A standard employee can access an HR export endpoint meant only for managers
A user modifies an API request and marks their account as an administrator
A mobile app hides premium functions in the interface but leaves the API unprotected
An internal tool assumes anyone on the company network can access sensitive records

When you will encounter broken access control

You are most likely to encounter broken access control in applications where different users, roles, or tenants should see different data.

Multi-user business applications

Customer portals, HR systems, billing platforms, case management tools, and internal dashboards all depend on strong authorization logic.

API security reviews

AppSec teams frequently find broken access control during API testing because APIs expose structured object requests that are easy to manipulate. A valid token does not mean the caller should have access to every object the API can reference.

Multi-tenant SaaS environments

In shared platforms, isolation between customers is critical. Broken access control here can turn into a cross-tenant data exposure issue, which is especially serious for both security and compliance.

Penetration tests and bug bounty reports

This is one of the most common findings in assessments because testers routinely check whether they can access unauthorized records, functions, or workflows by modifying requests.

Internal applications

The risk is not limited to internet-facing systems. Internal apps often receive less scrutiny and may trust corporate network access too much, leading to weak role enforcement and exposed administrative functions.

How to reduce the risk

Preventing broken access control requires both design discipline and good testing.

Enforce authorization on the server

Never rely on hidden buttons, disabled fields, or front-end logic as the real control. The server must verify permission on every sensitive request.

Check ownership and role every time

For object-level access, verify that the current user is allowed to reach that specific record, file, or action. For admin functions, verify the role explicitly.

Use least privilege

Design roles and permissions so users and systems have only the access they actually need.

Test negative cases

Security testing should include attempts to access things a user should not be able to reach, not just validation that allowed actions work.

Reduce admin sprawl

Strong credential hygiene matters too. Storing privileged credentials securely in a tool like 1Password can help teams reduce unsafe sharing and improve account management practices. On developer and test endpoints, endpoint protection such as Malwarebytes can also help limit broader compromise if attackers pair authorization flaws with malware or credential theft.

Bottom line

Broken access control means the application is not reliably enforcing who can access what. If a user can view another user’s data, call an admin function, or manipulate object references without proper checks, the issue is not just a bug. It is a direct path to data exposure, privilege escalation, and business risk.