REST APIs and Authorization Failures
Modern applications are built on REST APIs. When you open a banking app, a streaming service, or a project management tool, almost every action — loading your dashboard, retrieving your invoices, updating your profile — is backed by an API call that looks something like this:
GET /api/v1/users/42/orders
Authorization: Bearer eyJhbGci...The number 42 is your user ID. The server uses it to look up your orders in the database. The Authorization header carries your JSON Web Token (JWT), which proves to the server that you are logged in.
Here is the problem: proving that you are logged in is not the same as proving you are allowed to access a particular object.
The Peloton API Vulnerability (2021)
In May 2021, security researcher Jan Masters reported that Peloton's API returned detailed private user data — including age, weight, workout history, location, and gender — for any user ID, without requiring any authentication at all on certain endpoints. An attacker simply had to change the ID in the URL:
GET /api/v1/users/1/profile → returns user 1's private data
GET /api/v1/users/2/profile → returns user 2's private dataThis is a textbook example of Broken Object Level Authorization (BOLA), also known historically as Insecure Direct Object Reference (IDOR). Peloton had approximately 4 million active subscribers at the time. The vulnerability was publicly disclosed in May 2021.
What Is BOLA?
BOLA occurs when a server:
- Accepts an object ID from the client (in a URL path, query string, or request body).
- Returns or modifies the corresponding object.
- But fails to verify that the requesting user is actually permitted to access that specific object.
The server may verify that your JWT is valid — that is, it checks you are logged in — but it does not check whether you own or have been granted access to user ID 1's data.
BOLA is listed as API1:2023 in the OWASP API Security Top 10, making it the single most critical API security risk today.
What You Will Do
In the interactive panel on the right side of the screen you will find a simulated HTTP request builder. You will send requests to a mock REST API, observe how the server responds when you change the user ID in the URL, and identify the authorization failure yourself. The goal is to develop the instinct that every security professional and developer needs: always ask — does the server actually check ownership?