Back in the day, hacking a website meant blowing up a database with SQL Injection or stealing the admin panel via XSS. Times have changed. Hardly anyone is typing ' OR 1=1 -- into forms anymore (well, some still do, but they usually end up crying when they hit the WAF). Today’s real issue: logic errors. No one trusts 8-character passwords anymore, but how much do you trust those little ID parameters hidden inside your JSON packets—the ones you might have even forgotten to check?
As a Red Team Lead, I’m going to talk about that sneaky friend I encounter most often in the field, which causes headaches even for giants like 'testCompany': BOLA (Broken Object Level Authorization), also known as the modern and more handsome sibling of IDOR.
What’s the Deal? Where Did This BOLA Come From?
Actually, the story is quite simple. You have a web application; everything is modern. A front-end decorated with React, Vue, or Angular, and a smooth REST API running in the back. A user logs into the system and wants to see their own profile. The browser sends a request behind the scenes like this:
GET /api/v1/user/settings?id=1234
The server looks at it and says, 'Aha, this is Sedat. Is he logged in? Yes. Is his token valid? Yes. Okay then, let’s send the data for user ID 1234.' Right at that second, something is missing. The server checked if Sedat was logged in (Authentication), but it didn't ask if Sedat actually had the right (Authorization) to access the data for 1234.
If I change that 1234 to 1235 and see the private info of the guy at the next desk, congratulations; you’ve got a brand-new BOLA vulnerability on your hands.
Why Can't Automated Tools Catch This?
This is one of the most common questions: 'Sedat, we use a world-renowned vulnerability scanner, why didn't it find it?'
Because scanners don't understand what we call 'business logic.' When a scanner receives a '200 OK' for a request, it thinks everything is fine. However, inside that '200 OK' could be someone else's credit card number or home address that you shouldn't be seeing. This can only be noticed by a human eye (or a very well-structured Red Team scenario).
A Scenario from the Field: The testCompany Dashboard Incident
During a penetration test we recently conducted for 'testCompany', we came across the invoice download section of the app. The system looked very secure; JWTs flying everywhere, requests being signed, the works. But one endpoint caught my attention:
POST /api/export/invoice
Body: { "invoice_uuid": "inv_8822-1100", "user_context": "77" }
When I changed the user_context parameter to 78, the system didn't tell me 'Error! Unauthorized Access.' It just went ahead and sent the invoice for user 78 to my email as a PDF. This is exactly what we call 'Broken Authorization Control.' Assuming 'They already have a token, so the user_id in the token must be the same as the user_context in the body' while writing code is leaving security to chance.
Before We Tear the Code Apart: The Wrong Approach
Let’s write some 'scapegoat' code together. In the example below, using Node.js and Express...