A Complete Guide to Access Control Vulnerabilities

Introduction

A lot of people confuse access control vulnerabilities. Terms like BFLA, BOLA, BOPLA, IDOR, and Mass Assignment are often mixed together or used incorrectly. This creates even more confusion because each of these flaws has a different root cause and a different impact.

In this blog I want to break them down clearly. We will go through what each acronym means, why it matters, and how it differs from the others. The goal is not just to memorize definitions but to understand the mindset behind these vulnerabilities. That way you can recognize them in real applications instead of relying only on buzzwords.

Broken Access Control

Broken Access Control is not a single vulnerability. It is a broad category of issues that happen when an application does not correctly enforce restrictions on what users are allowed to do. Instead of one weakness, it includes many different flaws that let attackers go beyond their intended permissions.

The OWASP Top 10 groups a large number of problems under this category. In the 2021 edition it is listed as A01:2021 Broken Access Control, with more than thirty CWEs mapped to it. This shows both how common and how varied these issues can be.

Common access control vulnerabilities include:

Insecure Direct Object Reference (IDOR)

Insecure Direct Object Reference (IDOR) is an access control vulnerability that occurs when an application uses user-supplied input to directly access objects, such as database records or files, without properly verifying whether the user is authorized to access them.

Example:

Imagine a web application where users can view their profile by visiting a URL like:

https://example.com/profile?user_id=123

If the application does not check whether the logged-in user is actually allowed to view user_id=123, an attacker could simply change the number in the URL:

https://example.com/profile?user_id=124

This would let them see someone else's profile, because the application directly trusts the user_id parameter without enforcing proper authorization.

Broken Object Level Authorization (BOLA)

Broken Object Level Authorization (BOLA) is a vulnerability that happens when an API does not properly enforce access rules for its resources. In a system with BOLA, users may be able to access, modify, or delete data or objects that belong to other users because the API does not correctly check permissions.

Example:

Imagine an API for a banking application where users can view their account details by calling:

GET /api/accounts/123

If the API does not check whether the logged-in user actually owns account 123, a user could access someone else's account by changing the number:

GET /api/accounts/124

Similarly, if the API allows updating accounts without proper checks:

PUT /api/accounts/124

the user could modify another person's account information. This is a classic case of Broken Object Level Authorization.

Differences Between BOLA and IDOR

Most likely by now you are wondering aren't the BOLA and IDOR the same thing? In this section we will explain the difference, and also get a feel on how old and modern web applications work.

IDOR is usually discussed in the context of traditional web applications. These are websites where most actions happen through page requests in the browser, and users often interact with resources by clicking links or submitting forms. In traditional web applications, the server generates the full HTML page and sends it back to the browser.

Each click or form submission requests a new page from the server, which both fetches the data and formats it. Because URLs often directly reference objects, failing to check access properly can expose sensitive data. For example, changing user_id=123 in a profile page URL could let someone view another user's data.

BOLA is especially relevant for modern API-driven applications. In these applications, the frontend (what the user sees) and the backend (the server providing data) are separate and communicate via APIs. The frontend dynamically renders whatever data it receives from the API. Each API endpoint can give access to objects like user profiles, orders, or documents. If the API does not enforce proper authorization on these objects, users might access or modify data that does not belong to them.

To summarize, IDOR is about cases where objects are accessed directly without proper checks, like changing a URL or form parameter. BOLA is a broader issue in APIs, covering any situation where access rules for objects aren't enforced correctly, including viewing, editing, or deleting data that doesn't belong to the user.

In fact, IDOR can be considered a type of BOLA, an older example of object-level authorization failure in traditional web apps.

Broken Function Level Authorization (BFLA)

Broken Function Level Authorization (BFLA) is a vulnerability that occurs when an application does not properly enforce which functions or actions a user is allowed to perform.

This flaw often happens when applications rely only on the user interface to hide or disable certain features, but do not enforce proper authorization checks on the server. As a result, attackers can directly call restricted functions by crafting requests to endpoints that should be off-limits.

Example:

Imagine an application where only administrators should be able to delete users. The frontend interface hides the "Delete User" button for regular users. However, if the backend endpoint exists and does not enforce role-based checks, a regular user could still send a request like:

DELETE /api/users/124

If the server does not verify that the caller is an administrator, the request succeeds, and the attacker deletes another user's account.

This is a classic case of BFLA, the function (deleting accounts) was not protected with proper authorization, even though the interface suggested it was restricted.

Clarifications

If you have access to the certain function, and with that function you can access certain objects, like users or anything similar, that is the BOLA not BFLA.

Also, if you have access to the function that enables you to update your profile, delete it or whatever, and with that function you update or delete someones else's profile, that is the BOLA not BFLA.

Those cases doesn't fall into BFLA, because in those examples, every single time we said "if you have access to the function...". Basically you are supposed to have those functions, but with them you edited or accessed objects that aren't connected to you, so that's BOLA.

Mass Assignment

You may be wondering why didn't we continue with the BOPLA since that Is the last one in the row. You will get it why once we explain mass assignment and excessive data exposure.

Mass Assignment is a vulnerability that happens when an application automatically takes user-supplied input and binds it directly to internal objects without filtering or validation.

In other words, the server blindly trusts data sent by the user, including fields that were never meant to be processed by the developer.

Identifying hidden parameters:

Often, you can spot fields that are vulnerable by inspecting API responses. For example, suppose a user can update their profile with:

PATCH /api/users/1

{
  "username": "user",
  "email": "user@example.com"
}

A GET request to fetch the same user object might return the following response:

{
  "id": 1,
  "name": "User",
  "email": "user@example.com",
  "isAdmin": false
}

This is the actual JSON data returned by the API. Here, isAdmin is a hidden field that exists internally but is not meant to be modified by regular users.

Exploiting Mass Assignment:

An attacker could attempt to include this hidden field in their PATCH request:

PATCH /api/users/1

{
  "username": "user",
  "email": "user@example.com",
  "isAdmin": true
}

If the server automatically binds the field without proper validation, the attacker could gain administrative privileges, even though the developer never intended isAdmin to be user-modifiable.

Mass Assignment vulnerabilities highlight the importance of explicitly defining which fields can be updated by users and filtering out everything else. Unlike BOLA or IDOR, this is not about accessing someone else's objects but about manipulating object fields that were never meant to be controlled externally.

Excessive Data Exposure

Excessive data exposure occurs when an API endpoint returns more information than necessary to satisfy a request. Instead of providing only the specific data that a client asked for, the API sends additional fields or objects that are not needed.

This often happens when the API provider assumes that the client will filter out unneeded data. For example, a request for a user's name might return not only the name but also their date of birth, email, phone number, and even information about other users.

When present, this vulnerability can inadvertently leak sensitive information and increase the risk of data breaches. Properly restricting the API response to only the necessary fields is essential to prevent this kind of exposure.

Example:

Imagine an API that returns user details:

{
  "id": 1,
  "name": "User",
  "email": "user@example.com",
  "phone": "555-1234",
  "dateOfBirth": "1990-01-01",
  "isAdmin": false,
  "friends": [
    {"id": 2, "name": "Jane Smith"},
    {"id": 3, "name": "Bob Johnson"}
  ]
}

Even though the client only needed the user's name and email, the API responds with phone number, date of birth, admin status, and information about other users.

This is excessive data exposure, because sensitive or unnecessary information is returned. Notice that the isAdmin field is included. This not only exposes sensitive information but could also serve as a potential test case for a Mass Assignment attack, which we discussed in the previous section of the blog.

Broken Object Property Level Authorization (BOPLA)

Now you will understand why did we waited for BOPLA.

BOPLA is a vulnerability that occurs when both excessive data exposure and Mass Assignment issues exist in the same system. Essentially, it is a combination of two problems:

When these two flaws occur together, an attacker can first discover hidden or sensitive fields from API responses and then attempt to modify them through Mass Assignment.

Example:

Suppose a GET request to /api/users/1 returns:

{
  "id": 1,
  "name": "User",
  "email": "user@example.com",
  "isAdmin": false
}

The isAdmin field can be exposed, but seeing it gives us valuable insight into how the application works, revealing which internal properties exist and providing clues on what we can try next.

Using this knowledge, an attacker could attempt a PATCH request:

PATCH /api/users/1

{
  "username": "user",
  "email": "user@example.com",
  "isAdmin": true
}

If the server blindly binds these inputs without validation, the attacker could elevate privileges.

BOPLA shows how data exposure combined with blind property updates can help an attacker both understand and exploit the internal structure of an application.

Conclusion

I hope this blog helped you better understand access control vulnerabilities. From my experience, many people regularly confuse terms like BFLA, BOLA, BOPLA, IDOR, and Mass Assignment. Each of these flaws has its own root cause and impact, so mixing them up can lead to misunderstandings when assessing or securing an application.

By clearly separating these concepts and walking through real examples, my goal is to give you a practical perspective. Recognizing the differences and how these issues manifest in real applications can make it easier to identify vulnerabilities and apply proper security measures in your own work.