What Is Broken access control? Security Definition

Imagine you live in an apartment building. The building has a main entrance that requires a key to get in. That key is like logging in with a username and password. Once you are inside, there are different areas: the mail room, the laundry room, the rooftop, and each individual apartment.

Now, broken access control is like having a key that lets you into the building but then finding that the door to the rooftop is wide open when it should be locked. Worse, imagine you walk into the wrong apartment because the doors are not locked at all, or you find that the laundry room door opens if you just push hard enough even though it should only be for residents who paid the fee. In the digital world, this is exactly what happens.

When you log into a web application, you are authenticated, which means the system knows who you are. But authorization is the next step. It decides what you are allowed to do after you are inside.

Broken access control happens when that second step fails. For example, you might be a regular user on a banking website, but because the access controls are broken, you can see another customer’s account balance just by changing a number in the web address. Or you might be a student on a learning platform, but you can delete a course because the system didn’t check if you had permission to delete things.

The problem is not about tricking the system into letting you in without a password. The problem is that once you are in, the system trusts you too much. It doesn’t check what you are allowed to do at each step.

This is incredibly common in software because developers often focus on making the login page secure but forget to check permissions on every single page and every single function. In cloud environments, broken access control can happen when a storage bucket is configured to be publicly readable instead of private, so anyone on the internet can download the files. In APIs, it happens when an endpoint that should only be accessible to administrators is not protected and any authenticated user can call it.

The core idea is simple: just because someone is logged in does not mean they should be able to do everything. Broken access control is the failure to enforce that distinction. It is currently ranked as the number one security risk in the OWASP Top 10, which is a widely recognized list of web application security risks.

Understanding this concept is critical for any IT professional because it affects almost every system you will work with, from a small business website to a large enterprise cloud deployment. The fix usually involves implementing role-based access control, testing permissions thoroughly, and never trusting the client to tell the server what permissions it has.

Broken access control is a class of security vulnerability that arises when an application fails to enforce authorization policies properly, allowing users to perform actions or access resources that are outside their intended privileges. In the context of web applications, APIs, and cloud services, access control is typically implemented through a combination of authentication, session management, and authorization checks. Authentication verifies the identity of the user, while authorization determines what that verified user is allowed to do.

Broken access control represents a failure in the authorization layer. The vulnerability manifests in several forms, including vertical privilege escalation, horizontal privilege escalation, and missing function-level access control. Vertical privilege escalation occurs when a low-privilege user, such as a regular user, gains access to functions or data reserved for higher-privilege roles like administrators.

For example, a user with a ‘viewer’ role might access an API endpoint that allows deleting resources, simply because that endpoint does not check the user’s role before processing the request. Horizontal privilege escalation occurs when a user accesses data belonging to another user at the same privilege level. A classic example is Insecure Direct Object References (IDOR), where a user can modify a parameter in the URL, such as account_id=12345, to view another user’s account details, because the server does not verify that the requesting user owns that object.

Missing function-level access control is another pattern where certain functions, like a debug console or an admin panel, are not properly protected and can be accessed by any authenticated user. In cloud environments, broken access control often involves misconfigured Identity and Access Management (IAM) policies. For example, an AWS S3 bucket might be set to ‘public-read’ instead of ‘private’, allowing any anonymous user to read its contents.

Similarly, an Azure Storage Account might have a network rule misconfigured, allowing access from all IP addresses. In containerized environments, broken access control can occur when a container runs with overly permissive capabilities or when Kubernetes Role-Based Access Control (RBAC) is not configured correctly, allowing a pod to access secrets it should not see. The technical implementation of access control relies on several mechanisms.

At the application level, it often involves middleware that intercepts HTTP requests and checks the user’s role and permissions before passing the request to the controller. This middleware typically consults a database of roles and permissions, often stored in a relational database or a directory service like LDAP or Active Directory. Modern applications increasingly use token-based authentication with JSON Web Tokens (JWT) or OAuth 2.

0 tokens. However, the presence of a token alone does not guarantee proper access control. The server must validate the token and then enforce authorization using information within the token, such as claims about the user’s role, or by making additional database queries.

A common mistake is to rely solely on the client to send the user’s role. An attacker can easily modify the HTTP request to claim a higher privilege role. For example, if a web application stores the user’s role in a cookie or a hidden form field and then uses that value to decide permissions, an attacker can change the cookie to ‘admin’ and gain administrator access.

This is known as a parameter tampering attack. Therefore, the server must always be the authoritative source for authorization decisions. Access control models are typically categorized as Discretionary Access Control (DAC), Mandatory Access Control (MAC), Role-Based Access Control (RBAC), and Attribute-Based Access Control (ABAC).

RBAC is the most common in enterprise applications, where permissions are assigned to roles, and users are assigned to those roles. ABAC is more dynamic and uses policies based on user attributes, resource attributes, and environmental conditions. For example, an ABAC policy might allow access to a document only if the user is in the same department as the document owner and the access is attempted during business hours.

The OWASP Top 10 lists Broken Access Control as the most critical security risk for web applications. In cloud security, frameworks like the AWS Well-Architected Framework and the Azure Security Benchmark emphasize the principle of least privilege, which dictates that users and services should only have the minimum permissions necessary to perform their tasks. Testing for broken access control involves automated scanning tools that try to access resources with different roles and manual penetration testing that attempts to bypass restrictions.

Common testing techniques include changing parameter values, manipulating HTTP headers, and attempting to access unauthorized URLs directly. White-box testing involves reviewing the source code to ensure that authorization checks are performed consistently and correctly. Broken access control is a fundamental security flaw that arises from inadequate enforcement of authorization policies.

It is not a failure of authentication but rather a failure of the system to properly limit what an authenticated user can do. Addressing it requires a layered approach: designing access control at the architecture level, implementing it correctly in code, configuring it properly in cloud services, and testing it rigorously before deployment.

Broken access control matters because it is the root cause of some of the most damaging data breaches in history. When an attacker exploits broken access control, they do not need to steal passwords or bypass authentication. They simply use their own valid credentials to access data or functions they should not be allowed to see or use.

This makes the attack harder to detect because it looks like legitimate traffic from a valid user. For an IT professional, understanding broken access control is essential for designing, building, and maintaining secure systems. In cloud environments, a misconfigured IAM policy on an S3 bucket can expose millions of customer records to the entire internet.

In web applications, a missing authorization check on an API endpoint can allow one user to delete another user’s account. In enterprise environments, broken access control can allow a junior employee to change their own salary in the HR system. The impact is not just technical.

There are legal and regulatory consequences. Regulations like GDPR, HIPAA, and PCI-DSS require organizations to enforce strict access controls. A breach caused by broken access control can lead to fines, lawsuits, and loss of customer trust.

For example, the 2019 Capital One breach, which exposed the personal information of over 100 million customers, was caused by a misconfigured firewall that allowed an attacker to assume an IAM role with excessive permissions. That is a cloud access control failure. For IT certification exams like the AWS Solutions Architect Associate, the Azure Administrator Associate, CompTIA Security+, and the CISSP, broken access control is a core topic.

You will be expected to understand how to configure IAM policies, how to implement RBAC, and how to test for common vulnerabilities like IDOR. You will also need to know the difference between authentication and authorization, and the best practices for preventing broken access control. In practice, preventing broken access control requires a defense-in-depth approach.

It starts with designing a solid authorization model, typically using roles and policies. It continues with implementing server-side checks on every request, never trusting client-side inputs for authorization decisions. It involves using frameworks that enforce access control automatically, like Spring Security or ASP.

NET Core Authorization. And it requires regular testing, including automated scans and manual penetration testing. For IT professionals, this is not just about passing an exam. It is about building and maintaining systems that protect user data and maintain business continuity.

A single broken access control vulnerability can undo months of work and damage a company’s reputation irreparably. That is why it matters.

Broken access control appears in exam questions primarily through scenario-based questions that test your ability to recognize the vulnerability and apply the correct remediation. One common pattern is the Insecure Direct Object Reference (IDOR) scenario. For example, a question might describe a web application that allows users to view their own invoices by navigating to a URL like /invoice?

id=1234. The question states that a security researcher discovered that by changing the id parameter to 5678, they could view another customer’s invoice. The answer choices might include fixing SQL injection, enabling HTTPS, or implementing server-side authorization checks.

The correct answer is to add a check that verifies the invoice belongs to the currently authenticated user before returning the data. Another common pattern involves cloud IAM misconfigurations. A question might present an AWS S3 bucket policy that grants ‘GetObject’ access to ‘Principal: *’, meaning anyone on the internet can read the objects.

The question asks what the vulnerability is. The answer is broken access control due to overly permissive bucket policy. The remediation might be to remove the wildcard principal or add a condition that restricts access to only authenticated users from a specific account.

In Azure exams, you might see a question where a user is assigned the ‘Contributor’ role on a resource group but cannot deploy a virtual machine. The question asks why. The answer could be that the user needs the ‘Network Contributor’ role for the virtual network resource, or that the subscription policy blocks the deployment.

This tests your understanding that RBAC is granular and that proper authorization requires multiple role assignments. Function-level access control is another frequent topic. A question might describe a web application where the admin panel is at /admin, but the link to it is hidden from regular users.

The question asks if this is a secure implementation. The answer is no, because security by obscurity is not effective. The correct approach is to verify the user’s role on the server side before rendering the admin panel.

In practice, exam questions often mix broken access control with other concepts like session management or cross-site request forgery (CSRF). You might see a scenario where a user remains logged in on a public computer and another user accesses the application and can see the first user’s data. This could be a session fixation issue, but it also involves broken access control if the application does not validate the session owner on each request.

Troubleshooting questions also appear frequently. For example, you might be given a log entry showing that a user with a ‘viewer’ role accessed a ‘delete’ API endpoint successfully. The question asks what misconfiguration caused this.

The answer options might list various causes, and the correct one is that the API does not check the user’s role before executing the delete operation. The fix is to add role validation middleware. Some questions use configuration snippets.

For example, an Azure ARM template or an AWS CloudFormation template might be shown with an IAM policy that has an ‘Effect: Allow’ and a ‘Principal: *’. You would be asked to identify the vulnerability and choose the correct policy to replace it. The correct policy would restrict the principal to a specific AWS account or a specific role.

Exam questions expect you to think critically about where authorization checks should be placed, how to configure them in cloud platforms, and how to recognize when they are missing or misconfigured.

Broken access control is not just a theoretical vulnerability. It is a practical, day-to-day concern for developers, system administrators, and security professionals. To understand it in practice, you need to know how to implement proper access control in your applications and infrastructure.

Let us start with web applications. The most common pattern is to use a middleware that runs on every request. In frameworks like Express.js for Node.js, you can create a middleware function that checks if the authenticated user has the required role before proceeding to the route handler.

For example, you might define a middleware called ‘requireAdmin’ that checks if req.user.role === ‘admin’ and returns 403 if not. This middleware is then applied to any route that should be admin-only.

The same concept applies to ASP.NET Core with the [Authorize] attribute, where you can specify roles like [Authorize(Roles = “Admin”)]. The framework enforces the check before the controller action executes.

In cloud environments, access control is configured using IAM policies. For example, in AWS, you attach an IAM policy to a user, group, or role. The policy is a JSON document that specifies which actions are allowed or denied on which resources.

A common mistake is to use a wildcard (*) for actions or resources, granting too much permission. The principle of least privilege dictates that you should specify exactly the actions needed and limit the resources to those the user must interact with. For instance, a policy for a read-only user should only include ‘s3:GetObject’ and only for a specific bucket, not all buckets.

In Azure, access control is managed through RBAC. You assign a role like ‘Reader’, ‘Contributor’, or ‘Owner’ at a specific scope (management group, subscription, resource group, or resource). Custom roles can be created for fine-grained control.

You must understand the scope at which the role is assigned because a role assigned at the subscription level gives permissions to all resources in that subscription, which might be too broad. Testing for broken access control requires both automated and manual methods. Automated tools like OWASP ZAP can scan for missing access controls by trying to access restricted pages with low-privilege accounts or without authentication.

Manual testing involves analyzing the application’s functionality and trying to bypass restrictions. For example, if the application has a ‘user profile’ page at /user/profile/123, you should test if you can change the number to see another user’s profile while logged in as a different user. You should also test endpoints that perform side effects, like DELETE /user/123, to see if you can delete another user’s account.

What can go wrong? A lot. The most common mistake is dependence on client-side security. Developers sometimes hide buttons for actions that the user should not perform. But an attacker can send a direct HTTP request to the endpoint, bypassing the UI.

Another mistake is relying on the URL path alone for security, such as putting the admin panel at a different port or a hidden directory, but without server-side checks. Another issue is inconsistent authorization checks across different parts of the application. For instance, the main CRUD operations might have checks, but a special export function might be missed.

In real-world incidents, broken access control has led to massive data leaks. A notable example is the 2018 Facebook breach where attackers exploited a feature that allowed viewing the ‘View As’ page, which combined with a video uploader bug, led to an access token theft. That was a form of broken access control.

More recently, cloud storage misconfigurations continue to be a leading cause of data breaches. The lesson is clear: access control must be systematic, layered, and never rely on obscurity or client-side enforcement. As a professional, you should always assume that an attacker knows every URL and parameter.

Your only defense is a robust server-side authorization check on every single request.