Home › Blog › Access control · Guide

BOLA and IDOR Explained: When Users Can Read Each Other's Data

Broken Object-Level Authorization, also known as IDOR, lets a user fetch data that belongs to someone else when the API only checks that the request is authenticated. The flaw appears when the system mixes up authentication with authorization, so the user can read another person's invoice or profile simply by changing an identifier in the request.

What BOLA and IDOR actually mean

BOLA is the modern name for a classic problem where an API confirms that a caller is logged in but fails to confirm that the caller is allowed to see the specific object requested. The older term IDOR describes the same issue in web applications, where a direct reference to a resource, such as an invoice number, can be guessed or altered to pull data belonging to another user. The root cause is a missing check that ties the object to the authenticated user’s identity.

When the check is missing, the system assumes that any authenticated request can access any object with a valid identifier. This creates a gap where a malicious user can enumerate identifiers, replace them in the request, and retrieve data that should be private. The problem is not about weak passwords or leaked tokens; it is about the server trusting the request without confirming that the resource belongs to the caller.

Concrete invoice example

Imagine an endpoint that returns an invoice when the caller supplies an invoice ID. The attacker learns that the identifier is predictable enough to try other values and extract data from many accounts.

In practice, the attacker can automate the swap, capture the response, and collect sensitive details such as amounts, dates, and client names. Because the API does not filter by the user’s ID, the response includes information that should never be visible to that caller.

Why authentication alone is insufficient

Authentication answers the question “who are you?” by confirming the user’s identity, typically through a token or session cookie. Authorization answers “what are you allowed to do?” and must be applied to every resource request. When an API mixes these two steps, it may grant access based solely on the fact that the request is authenticated, ignoring whether the resource belongs to that user.

The confusion often arises because developers assume that a logged‑in user can safely request any object as long as the object ID is valid. This assumption overlooks the fact that object identifiers are often sequential or otherwise guessable, making it trivial for an attacker to probe the system. Proper authorization requires an explicit check that the object’s owner matches the authenticated user before returning any data.

How to test for BOLA/IDOR

A practical test involves creating two separate user accounts and performing the same request with each account’s credentials. First, capture a request that successfully returns data for the first account. Then, replay that exact request while authenticated as the second account, keeping the original object identifier unchanged. If the response still contains the first account’s data, the API is exposing data across accounts.

The test can be expanded by modifying the identifier to values that belong to other users and observing the responses. Consistent success in retrieving data that does not belong to the current session confirms a BOLA or IDOR flaw. This manual approach does not require specialized tools; a simple HTTP client or browser developer tools are sufficient.

Effective fixes and best practices

The core fix is to enforce ownership checks on every object retrieval. On the server side, the query that fetches the invoice should include both the invoice identifier and the authenticated user’s identifier, ensuring that only records belonging to that user are returned. Database‑level row‑level security policies can also enforce this rule automatically, reducing the chance of accidental omission in application code.

Beyond the immediate fix, adopt a defense‑in‑depth mindset. Use non‑guessable identifiers such as UUIDs, but remember that obscurity is not a substitute for proper authorization. Implement automated tests that verify ownership checks for each endpoint, and incorporate code reviews that flag any direct object references without accompanying permission checks. Regularly audit APIs for this pattern to keep the system resilient against future regressions.