Securing the Gates: Mastering BOLA and BFLA in API Security

7 min read

January 28, 2024

Exploring API Security: A Practical Guide to Uncovering Vulnerabilities
Securing the Gates: Mastering BOLA and BFLA in API Security

Table of contents


Welcome to our ongoing exploration of API security, a journey into the heart of digital safeguards. In this chapter, we turn the spotlight on two pivotal yet often underappreciated vulnerabilities: Broken Object Level Authorization (BOLA) and Broken Function Level Authorization (BFLA). Building on our insights from JWT, we'll dive deeper, unraveling the complexities of BOLA and BFLA. Join me as we dissect these vulnerabilities through a blend of theoretical insights and practical demonstrations using OWASP's crAPI. Whether you're a seasoned developer or a budding security enthusiast, this chapter promises to enrich your understanding and equip you with the tools to enhance your API defenses.

Understanding Broken Object Level Authorization (BOLA)

Let's dive into the world of BOLA - a sneaky security flaw that's like a wolf in sheep's clothing in the realm of API security. Imagine a club bouncer who forgets to check IDs; that's BOLA for you. It lets uninvited guests sneak into places they shouldn't be. Now, think about this: If you were to assess an API you are familiar with, where do you think BOLA vulnerabilities might exist? How would these vulnerabilities impact the overall security of the application?

What Exactly is BOLA?

Think of BOLA as a digital loophole. It's when an app is a bit too trusting, letting users peek into data that's not meant for their eyes. This is especially risky when we're talking about sensitive info like personal or financial data.

How Does BOLA Sneak Up?

BOLA is like leaving your car unlocked with the keys inside. It happens when APIs don't ask, "Hey, should you really be here?" when users request access to specific data. The main culprits? Not being strict enough with permissions and forgetting to double-check if a user should access certain info.

The Ripple Effect of BOLA

Imagine if someone could read your diary or access your bank details - scary, right? That's the kind of drama BOLA can cause. It can lead to privacy nightmares, data theft, and even let hackers play puppeteer with other people's accounts.

Spotting BOLA in the Wild

Finding BOLA requires playing detective - scrutinizing how APIs handle access to data. It's about testing every nook and cranny, using different user hats, and seeing if you can sneak a peek at data that's supposed to be off-limits.

A Practical Exploration of BOLA with OWASP crAPI

Our journey through crAPI starts with a familiar task after logging in: adding vehicles to our dashboard. Simply click "Click Here," and an email wings its way to you via Mailhog. To peek at this email, just head over to Mailhog's web interface. It's easy - type http://[ip of crapi]:8025/ into your browser, and you're in!

Link to add vehicle
Vehicle details

What's next? That 'refresh info' button on our new vehicle is more than just a button - it's a gateway to hidden data, revealing not just the car's location but also an intriguing endpoint identifier.

Car added
Car ID

Here, we introduce "Firefox Containers," a nifty Firefox extension that allows for multiple browser sessions in isolated tabs. This means we can log into different user accounts simultaneously without logging out, perfect for testing authorization without the hassle of juggling multiple browsers or incognito windows.

Firefox Multi-Account Containers – Get this Extension for 🦊 Firefox (en-US)
Download Firefox Multi-Account Containers for Firefox. Firefox Multi-Account Containers lets you keep parts of your online life separated into color-coded tabs. Cookies are separated by container, allowing you to use the web with multiple accounts and integrate Mozilla VPN for an extra layer of priv…
Firefox's containers with two different users

By intercepting the vehicle data refresh request in Burp and altering the car identifier, we step into another user's shoes, viewing their car data. This is BOLA in action, a clear demonstration of why proper authorization checks are crucial.

Change of identifier

Breaking Down Broken Function Level Authorization (BFLA)

Following our exploration of BOLA, we now pivot to another crucial aspect of API security vulnerabilities: Broken Function Level Authorization (BFLA). BFLA is akin to having a master key in the wrong hands. It occurs when users are able to execute functions that are out of bounds for their access level, potentially leading to severe security breaches. Reflect for a moment: Why do you think securing each function within an API is crucial, and how might overlooking this lead to significant security risks?

Understanding BFLA

Broken Function Level Authorization (BFLA) is a vulnerability where users gain unauthorized access to functions within an API. It's like someone having a key to rooms they're not supposed to enter. In an API context, this means users can perform actions or access functionalities that should be restricted, often due to insufficient validation of user permissions at the function level.

How BFLA Manifests in APIs

BFLA often shows up in scenarios where API endpoints handle sensitive operations - like changing user roles, accessing administrative features, or modifying critical data. These endpoints, if not properly secured, become weak links, allowing users to execute functions beyond their permission scope. It's a subtle flaw, as it doesn't block access entirely but allows unauthorized actions within allowed sessions.

The Consequences of Ignoring BFLA

The impact of overlooking BFLA can be profound. It ranges from data breaches, where sensitive information is altered or stolen, to complete system compromises. In the worst cases, BFLA can enable attackers to escalate their privileges within the system, potentially gaining administrative control. This highlights why ensuring function-level security is as crucial as securing the data objects themselves.

Identifying BFLA in Practice

We begin our BFLA journey where we left off - navigating the user profile. Among various options, the video upload feature catches our eye as a potential vulnerability hotspot.

Profile of the user

Upon uploading a video, a unique ID is generated, a seemingly mundane but crucial detail in our investigation.

Request uploading video

Our curiosity leads us to experiment with video modifications. Changing the video's name, we notice the request includes a "videoName" parameter, revealing the video's details and the endpoint's ID.

Rename the video
Request to change the name

Next, we switch gears and upload a video as a different user, using Firefox Containers for seamless session management, observing the new video's ID.

Request to upload a video of the other user

Returning to our original user, we play with the newfound ID, first attempting a straightforward ID swap in the request endpoint, which, as seen in the image, doesn't yield the desired result.

Change of ID in the request

Exploring further, we recall techniques from previous chapters, like tweaking the JWT. However, this path also hits a dead end, with the token flagged as invalid.

User change at JWT

We then test adding the ID directly to the request body, a method to be explored in future chapters, which unfortunately doesn't work here.

We add parameter to the request

Our journey takes an interesting turn when we experiment with different request methods. Switching to DELETE, we unearth a clue - a response indicating that this action is reserved for administrators.

Change request method

Despite various attempts, including changing the API version, our breakthrough comes when we replace 'user' with 'admin' in the request. This subtle yet powerful change allows us to delete another user's video, successfully exposing the BFLA vulnerability.

We change the endpoint version
We change from "user" to "admin"
Unable to access the video because it is deleted


As we wrap up our exploration of BOLA and BFLA in API security, I can't help but reflect on how these vulnerabilities highlight the intricate challenges we face in safeguarding our digital world. It's a journey that requires not just technical expertise, but also a keen sense of vigilance and responsibility.

Key Takeaways:

  • BOLA's Challenge: The necessity for robust permission checks to prevent unauthorized data access.
  • The Intricacies of BFLA: The importance of securing each function within an API to prevent unauthorized actions.
  • Practical Insights: Our hands-on experience with OWASP's crAPI illuminated these vulnerabilities in a real-world context.

Looking forward, I'm excited to guide you through our next topics: Mass Assignment and the potential vulnerabilities in resetting another user's password. These areas are crucial in our continuous endeavor to understand and strengthen API security.


Botón Anterior
Decoding JWT: Unveiling Vulnerabilities in API Security

Previous chapter

API Security Under the Microscope: Unmasking Mass Assignment and Broken User Authentication

Next chapter