What Is Broken Access Control?

Broken access control is a security vulnerability that allows users to access data, resources, or functionality outside their intended permissions. Attackers can exploit these weaknesses to view sensitive information, modify records, perform unauthorized actions, or gain administrative privileges.

Access control failures can appear in websites, applications, APIs, cloud services, and microservices. Because they often expose critical data and business functions, broken access control remains the number-one risk in the OWASP Top 10:2025.

Broken access control explained

Access control determines what an authenticated or unauthenticated user is permitted to see and do. Broken access control occurs when an application fails to enforce those restrictions consistently.

For example, an online banking application may allow a customer to access their account using a URL like: example.com/accounts/12345

If the customer can change the account number in the URL and view another customer’s account, the application has a broken access control vulnerability. The user may be properly authenticated, but the application has failed to verify that they are authorized to access that particular resource.

Broken access control can result in:

Unauthorized exposure of personal or business data
Modification or deletion of sensitive records
Access to another user’s account
Abuse of restricted APIs
Privilege escalation from a standard user to an administrator
Execution of sensitive business functions without permission

How does broken access control work?

Broken access control typically begins with a missing, inconsistent, or improperly implemented authorization check. An attacker identifies a resource or function that should be restricted and then modifies a request to bypass the expected controls.

Common techniques include:

Changing an object identifier in a URL or API request
Navigating directly to a restricted page
Changing an HTTP method from GET to POST, PUT, or DELETE
Manipulating cookies, hidden fields, or JSON Web Tokens
Calling an API endpoint that lacks authorization checks
Altering role or account information sent by the client
Bypassing controls implemented only in browser-side JavaScript
Exploiting an overly permissive cross-origin resource sharing configuration

Access control enforced only in the user interface is especially vulnerable. Hiding an administrator button, for example, does not prevent a user from sending the corresponding request directly. Authorization must be enforced by trusted server-side application logic for every protected request.

Why is broken access control such a critical security risk?

Broken access control can give attackers direct access to the data and functionality an application is supposed to protect. Unlike some vulnerabilities that require advanced exploit techniques, access control failures can sometimes be abused by making a simple change to a URL, parameter, or API request.

The potential consequences include:

Data breaches: Attackers may access customer records, payment details, intellectual property, or internal documents.
Account compromise: A user may view or modify another user’s profile, orders, messages, or financial information.
Privilege escalation: A standard account may gain administrative or operational capabilities.
Fraud and business abuse: Attackers may change prices, approve transactions, redeem benefits, or bypass purchase limits.
Regulatory exposure: Unauthorized access to protected data can contribute to compliance violations and reputational damage.
Large-scale API abuse: Automated tools can rapidly enumerate object identifiers and collect data across thousands of records.

OWASP reports that every application represented in its 2025 testing data had some form of broken access control. The category also had the highest number of occurrences in the contributed data, illustrating how widespread these weaknesses have become.

What are the different types of access control?

Organizations use several access control models to determine how permissions are assigned and enforced.

Role-based access control

Role-based access control, or RBAC, assigns permissions according to a user’s role. An administrator may be able to manage accounts, for example, while a customer service representative can view customer information but cannot change system settings.

RBAC simplifies permission management, but roles must be narrowly defined and reviewed regularly to prevent unnecessary access.

Attribute-based access control

Attribute-based access control, or ABAC, evaluates attributes associated with the user, resource, action, and environment. Access may depend on factors such as department, device, location, data classification, or time of day.

ABAC offers more granular control than a strictly role-based model but can become complex if policies are not centrally managed.

Discretionary access control

Discretionary access control, or DAC, allows the owner of a resource to decide who can access it. It is flexible and common in file-sharing systems, but it may lead to inconsistent permissions or excessive access.

Mandatory access control

Mandatory access control, or MAC, uses centrally defined security classifications. Users and resources receive labels, and the system determines access according to strict policies. MAC is commonly associated with government, military, and other high-security environments.

Rule-based access control

Rule-based access control evaluates requests against predefined rules. A system might restrict access based on network location, device type, request characteristics, or operating hours. It can also be combined with RBAC or ABAC for additional protection.

Regardless of the model, organizations should follow the principles of least privilege and deny by default. Access should be granted only when explicitly required.

What are common examples of broken access control?

Common types of broken access control vulnerabilities include:

Insecure direct object references: Users can change an identifier to access another user’s data.
Broken object-level authorization: An API fails to confirm that the requester is authorized to access a specific object.
Broken function-level authorization: A regular user can invoke a function intended for administrators or another privileged role.
Horizontal privilege escalation: A user gains access to another user’s resources at the same permission level.
Vertical privilege escalation: A user gains permissions associated with a more privileged role.
Forced browsing: An attacker guesses or discovers the URL of a restricted page and accesses it directly.
Missing method-level authorization: An endpoint restricts one HTTP method but leaves others unprotected.
Token or metadata manipulation: An attacker alters a JWT, cookie, request header, or hidden field to change their privileges.
CORS misconfiguration: An application allows untrusted origins to access protected resources.
Path traversal: Improper path validation allows a user to access files outside an authorized directory.

How can organizations detect broken access control vulnerabilities?

Detecting access control problems requires testing whether every user, role, and service is limited to its intended resources and actions.

Map users, roles, resources, and permissions

Create an access control matrix that documents which users and roles can perform each action on each resource. This provides a baseline for identifying missing or excessive permissions.

Test authorization systematically

Test protected functions using unauthenticated, standard, privileged, and administrative accounts. Verify that users cannot access another user’s objects, call restricted functions, or change their own permission level.

Automated scanners can identify some exposed endpoints and predictable object references, but manual testing is often necessary because authorization rules depend on application-specific business logic.

Test APIs directly

Evaluate every API endpoint and HTTP method independently. Confirm that object ownership and permissions are checked for GET, POST, PUT, PATCH, and DELETE requests rather than assuming that authentication alone provides sufficient protection.

Manipulate request data

During authorized security testing, change object identifiers, headers, cookies, tokens, URLs, and request methods. Attempts to access restricted data should produce a consistent access-denied response.

Review server-side code

Use secure code reviews and static analysis to identify endpoints that lack authorization checks. Pay particular attention to new routes, administrative functions, APIs, microservices, and code paths that rely on client-provided role information.

Monitor access patterns

Log denied requests and watch for behavior such as sequential object enumeration, repeated access failures, unexpected administrative calls, or one account requesting a large number of unrelated records. These patterns may reveal active attempts to exploit authorization weaknesses.

What are the best practices for preventing broken access control?

Organizations can reduce access control risk with the following practices:

Deny access by default. Require an explicit authorization decision for every non-public resource.
Enforce authorization server-side. Never rely on hidden buttons, client-side JavaScript, or other browser-based controls to protect sensitive functions.
Apply least privilege. Give users and services only the permissions required to perform their responsibilities.
Centralize access control. Use consistent, reusable authorization components rather than implementing separate checks throughout the application.
Validate object ownership. Confirm that the authenticated user is authorized to access the requested record, not merely that the record exists.
Protect every endpoint and method. Apply authorization consistently across web pages, APIs, microservices, and all supported HTTP methods.
Avoid predictable identifiers as a primary defense. Random identifiers can make enumeration harder, but they do not replace an authorization check.
Secure sessions and tokens. Keep tokens short-lived, validate their signatures and claims, rotate refresh tokens where appropriate, and invalidate stateful sessions after logout.
Limit automated abuse. Apply rate limits to sensitive endpoints to reduce the speed and impact of object enumeration and other automated attacks.
Log and alert on access failures. Monitor repeated denials, unusual data access, and attempts to invoke privileged functionality.
Include authorization in testing. Add positive and negative access control tests to unit, integration, API, and regression test suites.
Review permissions regularly. Remove unused accounts, unnecessary roles, and outdated service permissions as applications and teams change.

How can Fastly help reduce the risk of broken access control attacks?

Preventing broken access control starts with properly designed, server-side authorization. No WAF can replace the application logic that determines whether a specific user is allowed to access a particular resource. Fastly can, however, provide an additional layer of protection and visibility around applications and APIs.

The Fastly Next-Gen WAF helps organizations inspect application and API traffic and detect malicious or anomalous requests before they reach protected services. Its SmartParse detection technology evaluates requests in context, while reporting and alerting provide Layer 7 visibility that can help security and development teams investigate suspicious activity.

Fastly can also help organizations:

Monitor for unexpected values and parameters sent to API endpoints
Detect and block malicious requests targeting web applications and APIs
Apply rate limits to sensitive endpoints to slow automated enumeration and abuse
Identify malicious bots attempting to exploit access control weaknesses at scale
Protect REST, GraphQL, SOAP, gRPC, and WebSocket APIs
Centralize security visibility across applications deployed in cloud, on-premises, containerized, and edge environments
Integrate security data with existing development and security workflows

Combined with secure authorization design, ongoing testing, logging, and least-privilege policies, Fastly’s application and API security capabilities can help organizations reduce the likelihood that access control weaknesses will be discovered and exploited.