Every application has doors. Some are meant for everyone, like a login page or public product catalog. Others are meant only for specific people: an admin dashboard, another user’s invoice, a private document, or a server configuration panel. Broken access control happens when those doors exist, but the locks do not work properly.
TLDR: Broken access control is a security flaw that allows users to access data or perform actions they should not be allowed to. It often happens when applications fail to properly check permissions on every request. Attackers can exploit it to view private records, modify accounts, delete data, or gain administrative power. Preventing it requires strong authorization rules, server-side checks, and regular testing.
Understanding Access Control
Access control is the system that decides who can do what inside an application. It answers questions such as: Can this user view this page? Can they edit this record? Can they approve this payment? Can they delete another user’s content?
Authentication and authorization are often confused, but they are not the same. Authentication verifies identity: “Who are you?” Authorization verifies permission: “What are you allowed to do?” A user may be correctly logged in but still not be allowed to access certain resources. Broken access control occurs when that second part fails.
What Makes Access Control “Broken”?
Access control is considered broken when an application allows a user to bypass intended restrictions. This might be obvious, such as a regular customer reaching an admin panel. It can also be subtle, such as changing a number in a URL to view someone else’s account details.
For example, imagine a banking app where your account statement is available at:
examplebank.com/statements?account=12345
If changing 12345 to 12346 shows another customer’s statement, the application has a serious access control vulnerability. The user is authenticated, but the server is failing to confirm that the requested account actually belongs to that user.
Common Types of Broken Access Control
Broken access control appears in many forms. Some of the most common include:
- Horizontal privilege escalation: A user accesses another user’s data or actions at the same permission level, such as viewing someone else’s profile or order history.
- Vertical privilege escalation: A lower-privileged user gains access to higher-level functions, such as an ordinary user opening an admin dashboard.
- Insecure direct object references: Also known as IDOR, this happens when internal object identifiers, such as user IDs or file IDs, can be manipulated to access unauthorized data.
- Forced browsing: An attacker manually enters URLs or paths that are not linked in the interface but still exist on the server.
- Missing server-side checks: The interface hides a button or menu item, but the server still accepts the restricted request if it is sent directly.
- Overly permissive roles: Users are assigned broader permissions than they need, increasing the damage if an account is misused.
Why It Is So Dangerous
Broken access control is one of the most serious web application risks because it often leads directly to data exposure or system compromise. Unlike some vulnerabilities that require complex exploitation, access control flaws can sometimes be discovered with simple browser manipulation, intercepted requests, or guessed URLs.
The consequences can be severe. Attackers may steal personal information, download confidential business documents, alter account settings, issue refunds, approve transactions, or delete important records. In some cases, broken access control can allow an attacker to take over administrator functions and control large parts of a system.
This is especially damaging because access control flaws tend to affect business logic. They are not always caught by automated scanners, because a tool may not understand whether User A should be allowed to access Document B. That context often requires careful design, code review, and manual testing.
How Broken Access Control Happens
Many access control problems come from assumptions. Developers may assume that users will only click buttons they can see, that IDs are too hard to guess, or that client-side restrictions are enough. Unfortunately, attackers do not use applications only through the visible interface. They inspect requests, change parameters, call APIs directly, and test hidden routes.
Another frequent cause is inconsistent enforcement. One page may check permissions correctly, while another API endpoint forgets to do so. A mobile app may apply restrictions differently from the web app. A newly added feature may reuse old code without applying the proper authorization model.
Complex role systems can also create risk. As organizations add administrators, managers, editors, auditors, customers, contractors, and support staff, permissions become harder to manage. Without a clear model, it becomes easy to accidentally grant too much access or forget to revoke permissions when a person changes roles.
Realistic Examples
Consider a project management platform. A user belongs to Workspace A and should not see Workspace B. If the application uses a project ID in the URL and does not confirm workspace membership, the user may access projects outside their organization. That is horizontal privilege escalation.
Now imagine an online store where the admin page is located at /admin/orders. The navigation menu hides this link from normal customers, but the page itself does not check whether the visitor is an administrator. If a customer types the URL and sees order management tools, that is vertical privilege escalation.
APIs are another common weak point. A web interface may prevent ordinary users from changing account roles, but the underlying API endpoint might still accept a request such as {"role":"admin"}. If the server trusts that input without verifying authority, the result can be devastating.
How to Prevent Broken Access Control
Strong prevention starts with a simple principle: never trust the client. Browsers, mobile apps, and front-end code can guide the user experience, but they must not be the final authority on permissions. The server must enforce access control on every sensitive request.
Important defensive practices include:
- Deny by default: Access should be blocked unless it is explicitly allowed.
- Check permissions server-side: Every request to view, create, update, or delete data should verify the user’s rights.
- Use centralized authorization logic: Avoid scattering permission checks across the codebase in inconsistent ways.
- Apply the principle of least privilege: Users and services should receive only the permissions they truly need.
- Avoid predictable object access: Do not rely on secrecy of IDs alone; always verify ownership or permission.
- Log access control failures: Repeated denied attempts may indicate probing or an active attack.
- Test role boundaries: Security testing should include multiple users with different permission levels.
The Role of Testing
Testing for broken access control requires thinking like both a user and an attacker. Testers should create accounts with different roles and attempt to cross boundaries. Can a basic user access premium features? Can one customer view another customer’s data? Can an editor perform administrator actions by calling an API directly?
Manual testing is especially valuable because authorization rules are tied to business requirements. A scanner may detect missing authentication, but it may not know that a support agent should view a customer’s email address but not their payment details. Human understanding of the application’s rules is essential.
Building a Security Mindset
Broken access control is not just a coding mistake; it is a design issue. Secure systems define permission rules early, document them clearly, and enforce them consistently. Teams should ask, for every feature: Who should be allowed to do this, under what conditions, and how will the server verify it?
As applications grow, access control can become one of the hardest parts of security to maintain. New roles, new integrations, and new APIs all create opportunities for mistakes. But with careful design, centralized enforcement, least-privilege permissions, and thorough testing, organizations can greatly reduce the risk.
In the end, broken access control is about misplaced trust. The application trusts a URL parameter, a hidden button, a user-supplied ID, or a front-end restriction more than it should. Secure applications do the opposite: they verify every sensitive action, every time.
