A01:2025 – Broken Access Control

Overview

Broken Access Control is ranked as the number one risk in the OWASP Top 10:2025, and for good reason. Unlike many technical vulnerabilities, access control issues are rarely caused by exotic exploits or advanced tooling. They are usually the result of logic failures in how an application decides who can do what.

Access control is present in almost every part of a web application. Any time a user views data, modifies a resource, performs an action, or interacts with an API, an access control decision is being made. When those decisions are incorrect, inconsistent, or missing, attackers can simply step outside the boundaries the application assumes exist.

What makes broken access control especially dangerous is how easy it is to exploit. In many cases, an attacker does not need to break authentication, bypass encryption, or exploit memory corruption. They only need to modify a request, change an identifier, replay an action, or directly access an endpoint that was never meant to be exposed.

In modern web applications, access control failures commonly appear because:

• Authorization checks are enforced only in the frontend

• Backend APIs assume the client behaves correctly

• Permissions are checked in some endpoints but not others

• Business logic does not validate ownership of resources

• Roles or privileges are overly permissive by default

From an attacker’s perspective, broken access control turns the application itself into an attack surface. Instead of exploiting the system, the attacker simply uses it in ways the developers did not anticipate.

According to the OWASP Top 10:2025 data, broken access control affects virtually all tested applications in some form. This does not mean every application is fully compromised, but it does mean that access control weaknesses are widespread, often subtle, and frequently missed during development and testing.

Another critical aspect of this category is that it overlaps with multiple security domains. Broken access control is tightly connected to:

• Authentication logic

• Session management

• API security

• Logging and accountability

• Business workflows

For that reason, access control cannot be treated as a single feature or a one-time implementation. It must be designed, enforced, and validated consistently across the entire application, including all server-side endpoints and APIs.

In the context of the OWASP Top 10:2025, Broken Access Control also absorbs risks that were previously treated separately, such as Server-Side Request Forgery (SSRF). This reinforces the idea that access control is not only about users and roles, but also about what the application itself is allowed to access on behalf of a request.

Ultimately, broken access control is not a tooling problem. It is a design and enforcement problem. Strong authentication does not help if authorization is weak. Secure encryption does not matter if users can access data they should never see. The application must assume that every request is potentially malicious and enforce access decisions accordingly.

This section focuses on understanding how access control is supposed to work, how it commonly fails, and how those failures are exploited in real-world web applications.

What Is Access Control?

Access control is a security mechanism used to define who is allowed to access a resource and what actions they are allowed to perform on that resource.

In the context of web applications, access control answers questions such as:

• Can this user view this data?

• Can this user modify or delete this resource?

• Can this request trigger an administrative action?

• Can this API call be executed by this identity?

Every time an application processes a request, an access control decision should be made. Sometimes this decision is explicit and visible, but in many cases it is implicit, assumed, or spread across different layers of the application.

The primary goal of access control is to protect sensitive resources and ensure they are only accessible to authorized users or systems. These resources can include:

• Files and directories

• Database records

• User accounts

• Administrative panels

• API endpoints

• Business-critical actions (payments, refunds, approvals, etc.)

If access control is implemented correctly, users can only operate within the boundaries of their permissions. If it is implemented incorrectly, those boundaries become blurred or disappear entirely.

Access Control in Web Applications

In web applications, access control is typically enforced on the server side, where it cannot be manipulated by the client. The browser, mobile app, or API consumer should never be trusted to enforce authorization rules.

However, in practice, access control logic is often:

• Scattered across controllers, services, and APIs

• Implemented inconsistently between endpoints

• Partially enforced in the frontend

• Missing for certain HTTP methods (POST, PUT, DELETE)

• Based on assumptions rather than explicit checks

This is one of the main reasons why broken access control is so prevalent.

An application may appear secure from a user interface perspective, while the backend still exposes functionality that can be accessed directly by crafting requests.

Why Access Control Is Hard to Get Right

Access control is deceptively simple in theory, but difficult in practice.

Some of the challenges include:

• Applications grow over time, adding new endpoints and features

• Business logic becomes more complex

• Roles and permissions evolve

• APIs are reused across multiple clients

• Developers assume “this endpoint will never be called directly”

As a result, access control logic often becomes:

• Duplicated

• Inconsistent

• Hard to audit

• Easy to bypass

Unlike input validation or encryption, access control flaws are usually not syntax errors. They are logic errors, which makes them harder to detect automatically and easier to overlook during development.

Trust Boundaries and Access Control

A key concept in access control is the trust boundary.

A trust boundary exists anywhere data, identity, or control crosses from:

• The client to the server

• One service to another

• One user context to another

Every time a trust boundary is crossed, access control must be explicitly enforced. If the application assumes that something is “already checked” elsewhere, that assumption becomes an attack opportunity.

Attackers specialize in finding these assumptions.

Access Control Is Not Authentication

A common misconception is treating authentication and access control as the same thing.

• Authentication answers: Who are you?

• Access control (authorization) answers: What are you allowed to do?

An application can have strong authentication and still be completely vulnerable if authorization is weak or missing. Many broken access control issues occur after the user is already authenticated.

This is why broken access control often leads to:

• Horizontal privilege escalation

• Vertical privilege escalation

• Abuse of legitimate functionality

Why Broken Access Control Is So Common

Broken access control remains the top risk because:

• It affects almost every application

• It is easy to introduce

• It is hard to test exhaustively

• It often survives code reviews and automated scans

From an attacker’s point of view, access control flaws are attractive because they usually:

• Do not require exploitation chains

• Do not trigger obvious errors

• Use legitimate application functionality

• Blend in with normal traffic

Transition to Access Control Models

To understand how access control fails, it is first necessary to understand how access control is commonly implemented.

Different systems use different access control models depending on their requirements, environment, and architecture. Each model has its own strengths, weaknesses, and typical failure patterns.

The next section introduces the most common access control models used in real-world systems.

Common Access Control Models

Access control can be implemented in different ways depending on the type of system, the sensitivity of the resources, and the security requirements of the organization. These approaches are commonly referred to as access control models.

Understanding these models is important because broken access control vulnerabilities often arise when:

• a model is poorly chosen for the use case

• the model is implemented inconsistently

• the system mixes multiple models without clear boundaries

Below are the most common access control models used in real-world systems.

Discretionary Access Control (DAC)

Discretionary Access Control (DAC) is a model where the owner of a resource decides who is allowed to access it and what actions they are allowed to perform.

In this model, access decisions are based on:

• user identity

• ownership

• permissions explicitly granted by the owner

DAC is commonly used in:

• operating systems

• file systems

• traditional permission-based environments

How DAC works in practice

If a user owns a file, directory, or resource, that user can decide:

• who else can read it

• who can modify it

• who can delete it

The system enforces these decisions, but it does not question whether granting access is a good idea.

Conceptual example

Imagine a castle where the king owns all the rooms. The king can hand out keys to anyone he wants, allowing them to open specific doors whenever they choose. The power to grant access lies entirely with the owner.

That is DAC: freedom and flexibility, but also risk.

Security implications

DAC is easy to manage, but it has clear weaknesses:

• users may grant access too broadly

• permissions can spread over time (privilege creep)

• malicious insiders can abuse granted permissions

Many access control failures in DAC systems are caused not by technical bypasses, but by over-permissioning.

Mandatory Access Control (MAC)

Mandatory Access Control (MAC) is a model where access to resources is governed by centralized, system-enforced policies. Users cannot modify access rules, even if they own the resource.

Access decisions are based on:

• security labels

• clearance levels

• predefined classification rules

MAC is typically used in:

• government systems

• military environments

• highly regulated infrastructures

How MAC works in practice

Each resource and user is assigned a classification level. Access is only granted if the rules allow it. There are no exceptions and no discretionary overrides.

Conceptual example

Picture a fortified military installation. Every room has a classification level, and every individual has a clearance level. No matter who you are or what your role is, if your clearance does not match the room’s classification, access is denied.

The rules are absolute.

Security implications

MAC provides very strong guarantees:

• access rules are consistent

• users cannot weaken security policies

• enforcement is strict

However, MAC systems:

• are rigid

• are complex to design

• are difficult to adapt to dynamic business logic

Because of this, MAC is rarely used directly in typical web applications, but its principles influence modern secure system design.

Role-Based Access Control (RBAC)

Role-Based Access Control (RBAC) is one of the most widely used models in web and enterprise applications.

In RBAC:

• users are assigned roles

• roles define permissions

• users inherit permissions from their roles

RBAC is commonly used in:

• corporate applications

• SaaS platforms

• internal tools

• administrative systems

How RBAC works in practice

Instead of assigning permissions to individual users, permissions are assigned to roles such as:

• admin

• manager

• employee

• support

Users are then assigned one or more roles.

Conceptual example

In a company, not everyone needs access to the same systems. Managers may approve requests, administrators manage users, and employees access only their own data. Access is granted based on role, not on individual identity.

Security implications

RBAC is scalable and manageable, but it introduces its own risks:

• roles may become too broad

• users may accumulate multiple roles over time

• permissions may not be removed when responsibilities change

Many broken access control issues occur when RBAC checks are implemented in some endpoints but forgotten in others, or when roles are assumed rather than explicitly verified.

Attribute-Based Access Control (ABAC)

Attribute-Based Access Control (ABAC) is a more flexible and dynamic model where access decisions are based on attributes rather than fixed roles.

Attributes can include:

• user attributes (role, department, risk score)

• resource attributes (owner, classification)

• environmental attributes (time, location, device)

• request context (IP, authentication strength)

ABAC is commonly used in:

• cloud environments

• Zero Trust architectures

• modern API-driven systems

How ABAC works in practice

Instead of asking “what role does this user have?”, ABAC asks:

• who is the user?

• what resource is being accessed?

• under what conditions is the request made?

Access is granted only if all required conditions are satisfied.

Conceptual example

Think of a smart, adaptive security system. It checks who you are, where you are, what device you are using, and when you are requesting access. If anything does not match the policy, access is denied.

Security implications

ABAC is powerful but complex:

• policies can be difficult to reason about

• logic errors are easy to introduce

• misconfigured attributes can silently weaken security

In ABAC systems, broken access control often appears as unexpected combinations of attributes that were never considered during design.

Mixing Access Control Models

In real-world applications, it is common to see multiple access control models used together.

For example:

• RBAC for general permissions

• ABAC for contextual restrictions

• DAC-like behavior for user-owned resources

When models are mixed without clear boundaries, access control logic becomes harder to reason about, test, and enforce consistently. This complexity is a frequent root cause of broken access control vulnerabilities.

Why Access Control Models Matter for OWASP A01

Broken Access Control is not tied to a single model. It can appear in any access control model if:

• checks are missing

• assumptions are wrong

• enforcement is inconsistent

• logic is flawed

Understanding these models helps identify:

• where access decisions should happen

• what assumptions developers may be making

• how attackers think about bypassing controls

Common Broken Access Control Scenarios

Broken access control vulnerabilities appear when an application fails to properly restrict what users are allowed to access or modify. These failures are usually not caused by advanced exploitation techniques, but by missing or incorrect authorization logic.

Below are some of the most common broken access control scenarios observed in real-world web applications.

Horizontal Privilege Escalation

Horizontal privilege escalation occurs when an attacker can access resources or data belonging to another user with the same privilege level.

In this scenario, the attacker does not gain new privileges, but instead abuses the application’s failure to verify resource ownership.

A common example is when an application uses a user-controlled identifier to reference resources, such as a user ID or account number, without verifying that the authenticated user actually owns that resource.

For example, an application may expose a URL like:

https://example.com/app/account?user_id=1023

If the application does not check ownership, an attacker can simply change the identifier:

https://example.com/app/account?user_id=1024

If access is granted, the attacker can view or modify another user’s data.

Horizontal privilege escalation is extremely common in:

• APIs

• REST endpoints

• Object-based URLs

• Mobile and SPA backends

Vertical Privilege Escalation

Vertical privilege escalation occurs when an attacker can access resources or functions intended for users with higher privileges.

This typically happens when:

• role checks are missing

• privilege checks are enforced only in the UI

• backend endpoints trust client-provided parameters

For example, a regular user may discover an administrative endpoint such as:

https://example.com/admin/deleteUser

If the application does not enforce server-side authorization checks, the attacker may be able to execute administrative actions simply by sending a crafted request.

Vertical privilege escalation often leads to:

• full application compromise

• administrative access

• data destruction or manipulation

Insufficient Access Control Checks

Insufficient access control checks occur when authorization logic is:

• missing

• inconsistently applied

• implemented only in certain paths

A common pattern is when access checks are performed when rendering the frontend, but not enforced on the backend.

For example:

• A button is hidden in the UI for unauthorized users

• The backend API still allows the action if called directly

Attackers routinely bypass frontend restrictions by:

• intercepting requests

• replaying them manually

• modifying parameters

• calling APIs directly

If the backend does not validate permissions on every request, access control is effectively broken.

Insecure Direct Object References (IDOR)

Insecure Direct Object References (IDOR) occur when an application exposes internal object identifiers and fails to verify whether the user is authorized to access the referenced object.

These identifiers are often:

• sequential

• predictable

• easily guessable

Examples include:

• user IDs

• order numbers

• invoice IDs

• file names

For instance:

https://example.com/api/invoices/INV-2025-001

/api/invoices/12345

If ownership or authorization is not validated, attackers can enumerate identifiers and access sensitive data belonging to other users.

IDOR vulnerabilities are one of the most common and impactful forms of broken access control and are explicitly highlighted in OWASP A01:2025.

Why These Scenarios Matter

These scenarios demonstrate that broken access control is not a single vulnerability, but a class of failures caused by incorrect assumptions about trust, identity, and ownership.

Attackers do not need to exploit the system; they simply use the application in unintended ways.

Why Broken Access Control Is So Dangerous

Broken access control is dangerous because it attacks the core trust assumptions of an application. Instead of breaking cryptography, bypassing authentication, or exploiting low-level bugs, an attacker simply abuses what the application already allows.

From an offensive perspective, access control vulnerabilities are powerful because:

• they usually require no exploit chain

• they work even with valid authentication

• they often go undetected for long periods

• they blend into legitimate application behavior

In many real-world attacks, the application is not “hacked” in the traditional sense. The attacker logs in, sends normal-looking requests, and slowly steps outside the boundaries the developers assumed were enforced.

Broken access control also scales extremely well for attackers. Once a flaw is identified:

• it can often be automated

• it can impact many users

• it can expose large amounts of data

• it can lead directly to full compromise

Another reason this category is so critical is that access control failures often cascade. A single missing check can lead to:

• horizontal escalation → data exposure

• vertical escalation → admin access

• admin access → configuration changes

• configuration changes → full system compromise

In modern applications, broken access control frequently impacts APIs, which are often less protected and less visible than traditional web interfaces. When access control fails at the API layer, attackers can bypass the entire frontend and interact directly with sensitive backend functionality.

Ultimately, broken access control is dangerous because it breaks the fundamental rule of security: users should only be able to do what they are explicitly allowed to do — nothing more.

Prevention and Best Practices (High-Level)

From a defensive standpoint, broken access control is best prevented through design discipline, not last-minute fixes. From an offensive mindset, these best practices define what to look for when testing.

At a high level, effective access control requires:

Deny by Default

Access should be explicitly granted, not implicitly allowed. If an endpoint, action, or resource does not clearly require authorization, it will eventually be abused.

Attackers actively look for:

• endpoints without role checks

• APIs that assume authentication equals authorization

• features that were added without updating access rules

Server-Side Enforcement Everywhere

Access control must be enforced on the server, for every request, regardless of:

• HTTP method

• endpoint type

• client (browser, mobile, API)

From an attacker’s perspective, any control enforced only in the frontend does not exist.

Centralized Authorization Logic

Authorization logic scattered across controllers, services, and endpoints is hard to audit and easy to bypass.

Centralized enforcement:

• reduces inconsistencies

• makes testing easier

• reduces the chance of forgotten checks

When access logic is duplicated, attackers will eventually find the one place where it was forgotten.

Ownership Validation

Any time an application references a resource by ID, it must validate:

• who owns it

• who is allowed to access it

• under what conditions

From an offensive perspective, ID-based access is always suspicious until proven otherwise.

Logging and Alerting of Access Failures

Failed access attempts are often early indicators of:

• privilege escalation attempts

• IDOR enumeration

• automated abuse

Without logging and alerting, access control failures may remain invisible even while active exploitation is taking place.

Testing Perspective (Pentesting Mindset)

From a pentesting perspective, broken access control is about thinking like the application, then deliberately breaking its assumptions.

The goal is not to guess passwords or inject payloads, but to answer one question repeatedly:

“What does the application assume I am not allowed to do?”

Start With a Legitimate User

Most access control testing begins after authentication. A low-privileged user is often more valuable than no user at all.

Attackers and testers alike ask:

• What endpoints can I see?

• What actions can I trigger?

• What data do I receive?

Then they try to go slightly beyond that.

Manipulate Requests, Not the UI

The UI is not the target — the backend is.

Typical offensive techniques include:

• modifying IDs in requests

• replaying requests with different parameters

• changing HTTP methods

• calling endpoints directly

• removing or adding JSON fields

• reusing tokens across contexts

If the backend trusts the client, it will fail.

Think in Terms of Roles and Ownership

For every request, a tester should ask:

• What role is expected here?

• Is that role actually enforced?

• Is ownership validated?

• Can I access this as another user?

This mindset quickly reveals horizontal and vertical escalation paths.

Look for Inconsistencies

Access control is rarely broken everywhere — it is broken somewhere.

Common places to focus:

• APIs vs UI

• GET vs POST vs DELETE

• legacy endpoints

• new features

• edge cases and error paths

Inconsistent enforcement is one of the strongest signals of broken access control.

Assume Nothing Is Protected Unless Proven

From an offensive perspective, the safest assumption is:

“If I haven’t tested it, it’s probably broken.”

Access control testing is about systematic validation, not spot checks.

Hands-on Testing Checklist – Broken Access Control (A01:2025)

This checklist is designed to be used during active testing, not as a theoretical reference. Each item represents a question or action an attacker or pentester should consciously perform while interacting with the application.

The mindset is simple: never assume access control exists — verify it.

1

Authentication vs Authorization Separation

• Can I access functionality after authentication that I should not be authorized for?

• Does the application treat “logged in” as “authorized”?

• Are authorization checks clearly enforced server-side for every action?

• Can I reuse an authenticated session to access unrelated features?

Attacker mindset: “If I’m authenticated, what does the app assume I’m allowed to do?”

2

Horizontal Privilege Escalation (Same Role, Different User)

• Can I access another user’s data by changing an ID (user_id, account_id, order_id)?

• Are object identifiers predictable or sequential?

• Can I enumerate resources belonging to other users?

• Are ownership checks enforced consistently?

• Do APIs validate that the requested object belongs to the authenticated user?

Focus on: GET requests, list endpoints, detail views, download/export features.

3

Vertical Privilege Escalation (Role Bypass)

• Can a low-privileged user access admin or privileged endpoints?

• Are role checks enforced server-side or only in the UI?

• Can I change my role or privilege level via request manipulation?

• Are admin endpoints hidden but still accessible?

• Are role claims in tokens trusted without validation?

Red flags: Hidden buttons, disabled UI elements, commented-out frontend code.

4

Direct Endpoint Access (Force Browsing)

• Can I access protected endpoints directly without using the UI?

• Can I guess or discover endpoints via routing patterns?

• Are API routes exposed that are not linked anywhere?

• Can I access endpoints with different HTTP methods?

Try: GET → POST → PUT → DELETE on the same resource.

5

Insecure Direct Object References (IDOR)

• Are object references exposed directly in URLs or APIs?

• Are identifiers guessable, incremental, or reusable?

• Does the backend validate object ownership?

• Can I access files, invoices, reports, or documents I don’t own?

• Can I modify or delete objects belonging to others?

Common targets: Invoices, tickets, profiles, messages, documents, exports.

6

API-Specific Authorization Checks

• Are API endpoints protected independently of the frontend?

• Do APIs enforce the same access rules as the UI?

• Are mobile or SPA APIs more permissive?

• Can I replay API requests outside the application context?

• Are internal APIs exposed without proper authorization?

Assumption to break: “Only the frontend calls this API.”

7

Method and Verb Tampering

• Is access control enforced consistently across HTTP methods?

• Can I perform unauthorized actions using unexpected verbs?

• Does GET have stricter controls than POST or DELETE?

• Are method overrides supported or misconfigured?

Example: DELETE allowed even when GET is blocked.

8

Parameter and Payload Manipulation

• Can I add or remove parameters to bypass checks?

• Can I manipulate JSON fields related to role, user, or state?

• Are hidden fields trusted by the backend?

• Can I submit values that should be server-controlled?

Watch for: role, isAdmin, owner, status, approved, userId.

9

Token, Session, and Context Abuse

• Can I reuse tokens across users or roles?

• Are JWT claims validated or blindly trusted?

• Can I modify token payloads and retain access?

• Are sessions invalidated properly on role changes or logout?

• Can I use tokens outside their intended scope?

10

Business Logic and Workflow Abuse

• Can I skip steps in a workflow?

• Can I repeat actions that should be one-time only?

• Can I trigger actions out of sequence?

• Can I perform restricted actions through alternate flows?

Think: “What happens if I do step 3 before step 1?”

11

Error Handling and Edge Cases

• Do error messages reveal access control logic?

• Are access checks skipped during errors or exceptions?

• Can I trigger fail-open behavior?

• Are permissions checked consistently during failures?

12

Logging and Detection Gaps

• Are access control failures logged?

• Do repeated unauthorized attempts trigger alerts?

• Can I enumerate resources without detection?

• Does the application distinguish malicious vs normal behavior?

Offensive reality: If no alerts fire, exploitation can persist silently.

Final Attacker Mindset

Broken access control testing is not about breaking the system — it’s about walking past doors that were never locked.

If an application assumes:

• “users won’t try this”

• “the frontend prevents that”

• “this endpoint is internal”

That assumption is a potential finding.