What Is Broken Access Control? Types, Examples, Warning Signs, and Prevention

Broken access control is a security weakness that allows a user to view information, use a function, or perform an action beyond the permissions assigned to their account.

Authentication confirms who the user is. Access control determines what that authenticated—or unauthenticated, user is allowed to do.

When access-control rules are missing, inconsistent, incorrectly implemented, or enforced only in the browser, an attacker may gain unauthorized access without stealing another person’s password.

A successful attack may allow someone to:

• Read another user’s private information
• Change or delete another account’s data
• Access administrative functions
• Increase their own privileges
• Download confidential documents
• Approve transactions
• Change security settings
• Access another organization’s records
• Call restricted API endpoints
• Take control of the application

Broken Access Control remains the number-one risk in the OWASP Top 10:2025. OWASP reports that it had the highest number of occurrences in the contributed testing data and included weaknesses affecting every tested application. OWASP’s Broken Access Control guidance explains the category and its impact.

What Is Access Control?

Access control is the collection of rules that decides whether a person, service, device, or process can perform a requested action on a resource.

An access-control decision normally considers:

• Who is making the request
• Whether the requester is authenticated
• Which resource is being requested
• Which action is being attempted
• Who owns the resource
• The requester’s role
• The organization or tenant involved
• The resource’s current state
• The time and location of the request
• Other security or business conditions

For example, a customer may be allowed to view their own invoices but not another customer’s invoices. A support employee may view account information but not change payment details. An administrator may manage users but still require additional approval to delete an organization.

A secure application enforces these decisions on the server for every protected request.

How Does Broken Access Control Work?

A typical broken access-control attack follows this pattern:

1. The user signs in or accesses a public application.
2. The application provides a link, object identifier, API route, or client-side function.
3. The user changes the request or directly calls another endpoint.
4. The server fails to verify whether the user has permission for the requested resource or action.
5. The application processes the request.
6. The user receives unauthorized data or performs a restricted action.

The attacker may simply change:

• A record identifier
• A username
• An account number
• A URL path
• A request method
• A hidden form value
• An API field
• A tenant identifier
• A role value
• A workflow state

The request may be technically valid. The failure is that the server does not enforce the correct authorization rule.

Why Is Broken Access Control Dangerous?

Access control protects the boundaries between users, administrators, organizations, services, and sensitive operations.

When those boundaries fail, an attacker may not need malware or a complex exploit. They can use the application’s legitimate functions in an unauthorized way.

Potential consequences include:

• Exposure of personal information
• Financial fraud
• Account takeover
• Administrative compromise
• Data modification or deletion
• Confidential-document theft
• Cross-tenant data exposure
• Privacy violations
• Regulatory penalties
• Business disruption
• Creation of unauthorized accounts
• Disabling security controls
• Theft of intellectual property
• Complete application compromise

The impact depends on which resources and functions the attacker can reach.

Common Types of Broken Access Control

Horizontal Privilege Escalation

Horizontal privilege escalation occurs when one user accesses resources belonging to another user with a similar permission level.

Examples include:

• One customer viewing another customer’s order
• One employee reading another employee’s payslip
• One patient accessing another patient’s medical record
• One student changing another student’s submission
• One organization viewing another tenant’s invoices

The attacker does not become an administrator. They cross the boundary between peer accounts.

Vertical Privilege Escalation

Vertical privilege escalation occurs when a lower-privileged user gains access to functions reserved for a more powerful role.

For example, a regular user may be able to:

• Open an administrator dashboard
• Create or delete accounts
• Change account roles
• Access audit logs
• Modify system configuration
• Approve refunds
• Export all customer records
• Disable multi-factor authentication

Vertical escalation moves the attacker upward through the application’s permission hierarchy.

Insecure Direct Object Reference

An Insecure Direct Object Reference, or IDOR, occurs when an application exposes an identifier for an object but fails to verify whether the current user may access that object.

Objects may include:

• User profiles
• Documents
• Messages
• Orders
• Invoices
• Projects
• Support tickets
• Medical records
• Payment methods
• Uploaded files

An identifier can be numeric, random-looking, or encoded. Making it difficult to guess does not replace authorization.

The server must verify ownership or another appropriate permission for every requested object.

Broken Object-Level Authorization

Broken Object-Level Authorization, or BOLA, is a term frequently used in API security.

It describes an API that accepts an object identifier but does not correctly verify whether the requesting user may access or modify that object.

BOLA and IDOR often describe the same underlying authorization failure, although BOLA is commonly discussed in the context of APIs.

Broken Function-Level Authorization

Broken Function-Level Authorization, or BFLA, allows a user to call a function reserved for another role.

The application may hide the function in the interface while leaving the underlying endpoint accessible.

Potentially exposed functions include:

• Creating users
• Changing permissions
• Issuing refunds
• Deleting records
• Exporting data
• Viewing administrative reports
• Modifying application settings
• Approving transactions

Hiding a button does not prevent a user from sending the request directly.

Missing Access Control

Some endpoints have no authorization check at all.

This may happen with:

• Newly added APIs
• Legacy routes
• Internal tools
• Mobile endpoints
• Background functions
• Administrative pages
• File downloads
• Debug features
• Alternate request methods

Developers may assume that a network firewall, hidden URL, or frontend route protects the function. These assumptions frequently fail.

Client-Side Access Control

A client-side access-control failure occurs when the application depends on browser code, mobile application logic, hidden fields, or disabled buttons to enforce permissions.

The user controls the client and can modify requests.

Authorization must be enforced by the server. Client-side controls may improve the interface, but they are not security boundaries.

Parameter-Based Access Control

Some applications accept security-sensitive properties directly from the client.

Examples include:

• role
• isAdmin
• approved
• accountOwner
• tenant
• paid
• permissionLevel

If users can modify these values, they may grant themselves access or change protected business state.

Security decisions should come from trusted server-side records.

Forced Browsing

Forced browsing involves directly requesting a page or endpoint that is not linked in the user interface.

An attacker may discover:

• Administrative URLs
• Backup files
• Internal reports
• Old application routes
• Debug pages
• Export functions
• Hidden APIs

An unlisted resource is not automatically protected. Every sensitive route requires authentication and authorization.

Method-Based Access-Control Bypass

An application may protect one HTTP method but not another.

For example, authorization might be correctly enforced for a normal update route but missing from an alternative method, legacy endpoint, or bulk operation.

Security rules should cover every supported operation, including:

• GET
• POST
• PUT
• PATCH
• DELETE
• File upload
• Batch processing
• GraphQL operations
• WebSocket messages

Multi-Step Workflow Bypass

Some sensitive actions occur through a sequence of pages or API calls.

An attacker may skip:

• Identity verification
• Payment confirmation
• Manager approval
• Terms acceptance
• Security review
• Transaction confirmation

The final operation must independently verify that all required earlier steps were completed by the correct user for the same transaction.

Cross-Tenant Access

Multi-tenant applications serve multiple companies, teams, or customers through shared infrastructure.

A cross-tenant authorization failure lets a user in one tenant access another tenant’s:

• Users
• Documents
• Reports
• Settings
• API keys
• Billing data
• Projects
• Integrations

Tenant isolation must be enforced in every query, cache key, file path, background job, search index, and administrative tool.

Metadata and Field-Level Exposure

A user may be authorized to access an object but not every field within it.

For example, a public profile response should not necessarily contain:

• Internal user IDs
• Password-reset data
• Private email addresses
• Administrative notes
• Security flags
• Payment information
• Authentication secrets

APIs should return only fields the requester is authorized to see.

Unauthorized File Access

File-download and document-preview functions may fail to verify ownership.

Even if the file path is safe, the application must still confirm that the current user may access the requested document.

File authorization should not rely on:

• An unguessable URL
• A hidden link
• A random filename
• A temporary interface state
• The absence of directory listings

Mass Assignment

Mass assignment occurs when an application automatically copies request fields into an internal object.

If the object contains security-sensitive properties, a user may modify fields that were never intended to be exposed.

The application should use narrowly defined input models and explicitly select which properties can be changed.

Cross-Origin Authorization Failures

Misconfigured CORS, permissive messaging, insecure cross-origin communication, or missing CSRF protections can sometimes allow another site to interact with a user’s authenticated account.

These mechanisms do not replace normal access control. The server must still enforce identity, intent, and authorization for every action.

What Causes Broken Access Control?

The root cause is usually missing or inconsistent server-side authorization.

Common development problems include:

• Trusting the user interface
• Hiding links instead of protecting endpoints
• Failing to check object ownership
• Using client-supplied roles
• Applying authorization only during login
• Assuming internal APIs are trusted
• Duplicating permission logic across controllers
• Forgetting alternative request methods
• Missing tenant filters
• Using default-allow rules
• Relying on secret URLs
• Confusing authentication with authorization
• Failing to test every role
• Applying authorization after data retrieval
• Trusting cached permission decisions too long
• Inconsistent rules across microservices
• Using excessive service permissions
• Failing to protect administrative functions
• Incorrect cloud-storage permissions

Access control must be designed as a system-wide policy rather than added separately to individual buttons and pages.

What Is the Difference Between Authentication and Authorization?

Authentication answers: “Who are you?”

Authorization answers: “What are you allowed to do?”

A user may be properly authenticated and still exploit broken access control.

For example, a customer can sign in with their own legitimate password and then access another customer’s invoice because the application does not verify ownership.

Strong passwords and multi-factor authentication do not correct missing authorization checks.

What Is the Difference Between Broken Access Control and IDOR?

Broken access control is the broader category.

IDOR is one common type of broken access control involving direct references to objects.

Other access-control failures include:

• Administrative function exposure
• Cross-tenant access
• Workflow bypass
• Client-side authorization
• Missing field-level restrictions
• Role manipulation

Every IDOR is an access-control problem, but not every access-control problem is an IDOR.

What Is the Difference Between Broken Access Control and Authentication Bypass?

An authentication bypass allows an attacker to access the application without successfully proving their identity.

Broken access control often occurs after the user has authenticated, although it may also expose functions to unauthenticated visitors.

The two vulnerabilities can produce similar results but fail at different stages of the security process.

What Is the Difference Between Broken Access Control and Privilege Escalation?

Privilege escalation describes one possible result of broken access control.

Vertical privilege escalation gives the attacker a more powerful role or administrative capability. Horizontal privilege escalation crosses from one user’s resources to another’s.

Broken access control also includes unauthorized actions that do not permanently change the attacker’s formal role.

What Is the Difference Between Broken Access Control and Security Misconfiguration?

A security misconfiguration involves unsafe settings in applications, servers, cloud services, frameworks, or infrastructure.

Broken access control involves incorrect enforcement of permissions.

The categories can overlap. For example, a publicly accessible cloud-storage bucket may result from a permission misconfiguration and expose data through broken access control.

Warning Signs of Broken Access Control

Users and security teams may notice:

• Users accessing records they do not own
• Requests for sequential object identifiers
• Regular accounts calling administrative endpoints
• Cross-tenant data in API responses
• Sensitive fields returned unnecessarily
• Role changes without an approved administrator
• Direct requests to hidden pages
• Authorization failures followed by successful alternative requests
• Different HTTP methods producing different permission results
• Large-scale downloading by one account
• Unusual file access
• Users skipping approval steps
• Changes to security settings by unauthorized accounts
• Permission decisions based on request parameters
• Access from expired or revoked sessions
• Internal service accounts retrieving unrelated data
• Repeated requests for objects across many accounts

A single failed authorization request may be accidental. Repeated attempts across identifiers, roles, tenants, or endpoints require investigation.

How Can Developers Prevent Broken Access Control?

Deny Access by Default

Every protected resource should be unavailable unless a policy explicitly permits access.

A default-deny approach prevents new routes and functions from becoming public simply because a developer forgot to add a rule.

Enforce Authorization on the Server

The server must make every security decision.

Do not rely on:

• Hidden buttons
• Disabled form fields
• Client-side route guards
• Mobile application logic
• Obscure URLs
• JavaScript checks
• Read-only interface controls

The user controls the client and can send requests independently.

Check Authorization on Every Request

Authorization should be verified each time a user attempts to:

• Read an object
• Create a resource
• Modify a record
• Delete information
• Download a file
• Call an API
• Change a setting
• Perform an administrative action
• Advance a workflow
• Approve a transaction

Do not assume that permission granted on a previous page automatically applies to the next action.

Centralize Authorization Logic

Use a consistent authorization service, framework, middleware layer, or policy engine.

Centralization reduces:

• Missing checks
• Conflicting rules
• Duplicated logic
• Framework-specific differences
• Inconsistent error handling

The enforcement point should still have enough context to evaluate the user, action, resource, tenant, and current state.

Check Object Ownership

For every object-level request, confirm the relationship between the requester and the resource.

Do not retrieve an object by its ID alone and assume possession of the identifier proves authorization.

Where practical, scope the query to the current user or tenant so unauthorized records are never returned from storage.

Enforce Tenant Isolation

Every tenant-aware data operation should include the correct tenant boundary.

This includes:

• Database queries
• Cache keys
• Search indexes
• Object storage
• File paths
• Analytics
• Background jobs
• Event streams
• Exports
• Administrative tools

Tenant identifiers supplied by the client should be checked against trusted session or identity information.

Use Least Privilege

Users and services should receive only the permissions needed for their roles.

Limit:

• Database permissions
• Cloud roles
• API scopes
• Filesystem access
• Administrative functions
• Queue permissions
• Storage access
• Internal-network access

Least privilege reduces the impact of both application errors and compromised accounts.

Choose an Appropriate Access-Control Model

Common access-control models include:

• Role-Based Access Control (RBAC): Permissions are assigned through roles.
• Attribute-Based Access Control (ABAC): Decisions use attributes of the user, resource, action, and environment.
• Relationship-Based Access Control (ReBAC): Decisions depend on relationships such as owner, editor, teammate, or organization member.

OWASP recommends considering attribute- and relationship-based controls when simple roles cannot express the application’s authorization requirements. OWASP’s Authorization Cheat Sheet provides detailed design guidance.

Do Not Trust Client-Supplied Security Properties

Roles, tenant membership, ownership, payment state, and administrative status should come from trusted server-side records.

The client may request an operation, but it should not declare that the operation is authorized.

Use Indirect Object References Carefully

Opaque or random identifiers reduce easy enumeration, but they are not an authorization control.

Use them together with server-side ownership and permission checks.

A leaked random identifier should not grant access to the underlying resource.

Protect Administrative Functions

Administrative endpoints should require:

• Strong authentication
• Explicit role checks
• Appropriate session assurance
• Reauthentication for sensitive changes
• Transaction-specific authorization where needed
• Detailed audit logging
• Rate limits
• Network restrictions when appropriate

Administrative actions should not be exposed through alternative unprotected routes.

Validate Workflow State

For multi-step transactions, verify that:

• Required steps were completed
• They were completed by the correct user
• They apply to the current transaction
• Approval remains valid
• Security-sensitive details have not changed
• The final action is still authorized

Do not rely on a client-supplied field indicating that approval occurred.

Protect Static Files and Cloud Storage

Sensitive files should not be placed in publicly accessible directories or buckets.

Use server-controlled access or carefully scoped signed URLs with:

• Short expiration
• Correct resource scope
• Appropriate HTTP method
• Intended user or audience where possible
• No excessive permissions

Storage permissions should be reviewed independently of application authorization.

Apply Field-Level Authorization

Return only information the requester needs and is allowed to see.

Use separate response models for:

• Public users
• Customers
• Support personnel
• Managers
• Administrators

Avoid serializing complete internal objects into API responses.

Prevent Mass Assignment

Define exactly which request fields can update an object.

Use dedicated input models instead of accepting every matching property from the client.

Sensitive fields should be assigned only through trusted server-side logic.

Invalidate Authorization Caches Correctly

Applications may cache roles and permission decisions for performance.

Invalidate or shorten the lifetime of cached authorization data when:

• A user’s role changes
• Organization membership ends
• An account is suspended
• A resource changes ownership
• A policy is updated
• A session is revoked

A removed permission should not remain effective because of stale cache data.

Log Access-Control Events

Record:

• Denied access attempts
• Role changes
• Administrative actions
• Cross-tenant requests
• Ownership changes
• Security-setting changes
• Bulk exports
• Permission-policy updates
• Sensitive file downloads

Logs should include enough context for investigation without exposing secrets.

Fail Securely

If the authorization service, database, policy engine, or identity provider fails, protected access should normally be denied.

An error must not silently become approval.

The application should return a controlled response and alert the appropriate operations team.

Why URL Hiding Does Not Provide Access Control

A URL is not secret merely because the application does not display it.

Attackers may discover endpoints through:

• Browser history
• JavaScript files
• API documentation
• Mobile application code
• Search engines
• Logs
• Error messages
• Old links
• Network traffic
• Automated content discovery

Every sensitive endpoint must enforce its own authorization rules.

Are Random Object IDs Enough?

No.

Random identifiers make large-scale guessing more difficult, but they do not prove permission.

An identifier can be leaked through:

• Browser history
• Shared links
• Referrer data
• Logs
• Screenshots
• Emails
• Analytics
• Another compromised account

Always check whether the current requester is authorized to access the referenced object.

Can CORS Prevent Broken Access Control?

No.

Cross-Origin Resource Sharing, or CORS, controls which browser origins may read certain cross-origin responses and send particular requests.

It does not determine whether the authenticated user may access a specific object or function.

A restrictive CORS policy is useful, but every API endpoint still needs authentication and authorization.

Can a Web Application Firewall Prevent Broken Access Control?

A WAF may block obvious requests for administrative paths, unusual methods, or automated object enumeration.

It usually cannot understand:

• Object ownership
• Tenant membership
• Business relationships
• Workflow state
• User responsibilities
• Field-level permissions

Broken access control must be fixed in application and service authorization logic.

How Should Access Control Be Tested?

Testing must be performed only with explicit authorization.

A security assessment should create an authorization matrix covering:

• User roles
• Resources
• Actions
• Ownership
• Tenant membership
• Workflow states
• Authentication levels

Testing should verify:

• Unauthenticated access
• Horizontal access between users
• Vertical access between roles
• Cross-tenant access
• Alternate HTTP methods
• Hidden and legacy endpoints
• Mobile and API routes
• File downloads
• Bulk operations
• Field-level exposure
• Administrative functions
• Expired and revoked sessions
• Workflow bypass
• Changes after role removal

OWASP provides guidance for automating authorization tests through a permission matrix and incorporating them into application testing. OWASP’s Authorization Testing Automation Cheat Sheet describes this approach.

How Can Organizations Detect Access-Control Abuse?

Useful monitoring sources include:

• Application audit logs
• API gateway records
• Authentication events
• Database audit logs
• Cloud audit records
• File-access logs
• WAF events
• Data-loss prevention tools
• Storage access logs
• Administrator activity
• Identity-provider logs

High-value detections include:

• One account requesting many unrelated object IDs
• A user repeatedly crossing tenant boundaries
• Regular accounts calling administrator endpoints
• Sudden bulk downloads
• Role changes outside normal workflows
• Access after account suspension
• Repeated permission-denied events followed by success
• Security settings changed without reauthentication
• Service accounts accessing unrelated systems

What Should an Organization Do After Detecting Broken Access Control?

Restrict the Vulnerable Function

Disable the affected endpoint or temporarily limit it to trusted users.

Apply an authorization check at the server or gateway while the complete application fix is developed.

Preserve Evidence

Collect:

• Request logs
• Authentication activity
• Authorization decisions
• API gateway events
• Database queries
• File access
• Role changes
• Administrative actions
• Cloud audit records
• Export activity

Follow established incident-response and evidence-retention procedures.

Determine What Was Accessed

Investigators should identify:

• Affected accounts
• Exposed objects
• Accessed fields
• Modified or deleted records
• Administrative functions used
• Files downloaded
• Tenants affected
• Time period of exposure
• Whether access was automated
• Whether additional accounts were created

Revoke Unauthorized Access

Depending on the incident:

• Suspend suspicious accounts
• Revoke active sessions
• Remove unauthorized roles
• Disable exposed API keys
• Reverse permission changes
• Block affected endpoints
• Restrict compromised service accounts

Restore Affected Data

Reverse unauthorized changes where possible.

Restore deleted or modified information from trusted backups, and verify the integrity of related resources and audit records.

Notify Affected Users

If private or regulated information was exposed, follow the organization’s legal, contractual, and regulatory notification requirements.

Communications should explain what happened, what information was affected, and what users should do.

Correct the Root Cause

Implement centralized, server-side authorization based on:

• Trusted identity
• Object ownership
• Tenant boundary
• Required role or relationship
• Requested action
• Current business state

Review similar endpoints throughout the application rather than fixing only the reported route.

Monitor After Recovery

Continue watching for:

• Repeated unauthorized requests
• Use of exported data
• New account activity
• Reused sessions
• Further privilege escalation
• Cross-tenant access attempts
• Changes to permissions
• Related attacks against similar APIs

What Should a User Do After Unauthorized Account Activity?

If your account contains changes or activity you did not authorize:

1. Open the service through its official website or application.
2. Review recent sign-ins and account activity.
3. Change your password.
4. Sign out other sessions.
5. Enable multi-factor authentication.
6. Review account roles and connected applications.
7. Check recovery email addresses and phone numbers.
8. Reverse unauthorized changes where possible.
9. Contact the service provider.
10. Review financial or sensitive activity when relevant.

A password change cannot correct the provider’s broken access-control code, but it can protect the account if credentials were also exposed.

Does Multi-Factor Authentication Prevent Broken Access Control?

No.

MFA strengthens authentication, but broken access control affects authorization.

A legitimate user who completes MFA may still access another user’s information if the application does not enforce ownership.

MFA remains valuable for reducing account takeover, especially for administrative accounts.

Is Broken Access Control Only an API Problem?

No.

It can affect:

• Traditional websites
• Mobile applications
• Desktop software
• Cloud storage
• Microservices
• GraphQL
• WebSockets
• File systems
• Administrative tools
• Internet of Things devices

APIs receive particular attention because object identifiers and business functions are often exposed directly through endpoints.

Why Is Broken Access Control Ranked So Highly?

Broken access control protects nearly every meaningful action inside an application. One missed check can expose sensitive information or administrative functionality.

In the OWASP Top 10:2025, Broken Access Control maintains the number-one position. OWASP’s contributed data found it had the highest number of occurrences among the measured categories. OWASP Top 10:2025 identifies it as the leading web application security risk.