Back in the day, when we talked about web security, the first things that came to mind were SQL Injection and XSS. We’d set up a WAF, sanitize our inputs, and tell ourselves, 'Alright, we can sleep soundly tonight.' But the world has changed. Nobody relies on simple 8-character passwords anymore; everyone is chasing 16-20 character passphrases filled with characters that look like ancient hieroglyphs. But here’s the real deal: no matter how securely you lock the door, if there’s a 'logic flaw' in the architecture itself, an attacker won't bother with the door—they’ll just walk away with the entire wall.
Today, I want to talk to you about a topic that we’ve been getting a lot of mileage out of during our Red Team operations lately, and one where the defense side often slips up by thinking, 'Hey, we already put authorization there.' Let's talk API Security and its mischievous child: BOLA (Broken Object Level Authorization).
From Monolith to Microservices: What Changed?
Look, my friend, in the old days, everything happened on the server-side. A user would click a button, the server would calculate everything, render a finished HTML page, and send it back. Nowadays, 'Headless' architectures and SPAs (Single Page Applications) rule the world. The server now just flings raw data (usually in JSON format) through APIs. Your browser (React, Vue, Angular, etc.) handles the visuals and a chunk of the logic.
This is exactly where the danger begins. Moving some security controls to the 'client-side' leaves the backend API endpoints exposed. As an attacker, I don’t care about the fancy interface the browser shows me. I’m looking at the API requests scurrying around behind that interface.
BOLA (IDOR): 'What Happens If I Just Change One Number?'
BOLA, formerly known as IDOR (Insecure Direct Object Reference), is actually based on a very simple logic: 'I have the authority to see my own data, but can I look at someone else’s too?'
Imagine you're working on an e-commerce site called testCompany. When you open your own profile page, you notice the browser making a request like this in the background:
GET /api/v1/user/profile/1005 HTTP/1.1
Host: api.testcompany.com
Authorization: Bearer <your_token>
Here, 1005 is your user ID. A cybersecurity expert (or a curious attacker) immediately thinks: 'What if I change this 1005 to 1006?'
If the system only checks 'Is this user logged in?' (Authentication) but fails to check 'Is this user authorized to see data with ID 1006?' (Authorization), then it's game over. You’ve just accessed someone else’s private information.
A Scenario from the Field: The Danger of Mass Assignment
Now, let's raise the stakes a bit and talk about BOLA’s cousin: 'Mass Assignment.' This usually stems from the 'conveniences' that modern frameworks (Entity Framework, Hibernate, Eloquent, etc.) provide to developers. If a developer maps the entire JSON object coming from the user directly to the database model, they might be heading for a headache.
Let’s consider an example profile update request:
// Outgoing Request (Under Normal Conditions)
PATCH /api/v1/user/update/10