Broken Object Level Authorization vulnerabilities are known to be the most common flaws you will run into when testing APIs. BOLA held the top spot in the original 2019 edition of OWASP’s API Security Top 10 list. And it is still the number one vulnerability listed in the recently published OWASP API Security Top 10 (2023).
A BOLA happens when an API fails to check that a user requesting access to a given object is authorized to do so. In the present case, an object will generally be a set of data that belongs to a registered user (think username, password, e-mail address, physical address, account number, account balance, etc).
If user A can access and maybe even modify user B’s data then you have uncovered a BOLA vuln. Of course, this doesn’t apply to users with special permission, such as admins who have access to other users’s data by design.
Simply put, you can consider exploiting a BOLA as a form of identity theft.
Spotting a BOLA
To find a BOLA, look for endpoints that include a user id as a parameter.
This can be in the URL itself:
https://target.com/api1/user/09876
It can be in request headers:
Authorization: Bearer wIyeO8SH4b4q3Mn7QvbItSBnBswu3OSrHLGdaJ9tH64
It can be in the request body itself:
{"user_id": 45278}
You will generally need two user accounts to test the vuln. Log into the API as user A, make sure you have created a set of data. This may have been done when you registered the user, or maybe using an Update Profile request.
Then log in as user B. Replace your user id by that of user A, send the query and see what comes back.
If user B can access user A’s data, this is a BOLA and this vulnerability needs to be fixed.
However, to exploit a BOLA in a real life situation, you will need to obtain or guess a third party user’s id, which may not always be easy. So exploiting a BOLA will generally require leveraging another vulnerability upstream, such as a Broken Object Property Level Authorization (BOPLA) that will reveal sensitive data (the user id structure in the present case), or an Unrestricted Resource Consumption vuln that would allow you to fuzz other user id’s.
Thankfully for attackers, API vulnerabilities often fly in formation.
What to see this in action? Here we go…
Fuzzing for user id’s
Here, I am using the ParaBank vulnerable online banking application and API as a demonstrator (I have a full walkthrough that you can access here).
I started by creating a new user in the web app. Then I turned to the API’s supplied endpoint collection loaded in Postman and I used the login request to log my user in.
In the response body, I could see my user id displayed as the value of the id field: 12434.
I then used an endpoint called Get Customer Details to list my details (below, I proxied the request into Burp Suite for clarity).
So we know user id’s are five digit numbers.
I then used FFUF to fuzz the API for other registered users’ id’s.
This returned two id’s in addition to my own.
Back in Burp Suite, I swapped my user id in the URL path for one of those discovered above.
Once I sent the request, I got another user’s details. This is a textbook example of a BOLA.
Using another endpoint with this same user’s id, I was also able to list my new friend John’s account references and account balance (see the full walkthrough for details).
Playing with URL paths
In some case, finding a BOLA will be easier than that and you won’t even have to worry about finding user id’s.
Here’s an example using the Damn Vulnerable Web Services application and API (you can install it from here).
The web app has a section where users can write personal notes, that can either be public or private. Only public notes should be viewable by other users.
I first logged into the web app as a user I registered and called Tim. I created two private notes, one of them being a reminder for a party at a friend’s.
I then logged out and logged back in as another user I called Andrew. As Andrew, I created two notes : one private note with a to-do list and one public note with details of an upcoming flight.
Clicking on the Display All Public Notes button only brings up Andrew’s public note. So the web app seems to be doing its job correctly.
How about the API?
I switched to Burp Suite and logged in as Andrew. In Burp Repeater I then sent a request to an endpoint that lists the user’s notes. Here we get the details of Andrew’s two notes.
Let’s get creative with the URL. We can see in the response body above that Andrew’s notes are numbered 3 and 4. So I added a slash and a number to the URL and sent the request.
In the response above, we can see that I got back note number 2, which happens to be one of Tim’s secret notes, that Andrew should not have access to. Here again, we have a BOLA.
Andrew now has the details of Saturday’s party and can show up at Sally’s uninvited.
Let’s hope at least he brings wine…
As a closing note, if you want to dig deeper into BOLA and into the OWASP API Security Top 10 list, I very much suggest you check out Corey Ball’s free OWASP API Security Top 10 and Beyond! course at the APISec University.
