Like most modern applications, APIs require extensive authorization controls to safeguard data and functionality. When authorization controls break down, sensitive data and critical functions become exposed, leading to potentially disastrous consequences. When precisely diagnosing authorization-related vulnerabilities, the OWASP API Security Top Ten outlines several variants. One such variant, Broken Function Level Authorization (BFLA), is an API vulnerability to which users can perform actions or use functions they shouldn't have access to. Imagine an attacker gaining unauthorized administrative privileges on your platform, the ability to view other users' private data, or disrupting core operations through a vulnerable API endpoint—that's the risk BFLA poses.
In this blog, we'll delve into what BFLA is, how it's exploited, and the essential strategies and security controls you must implement to protect your APIs. We'll also explore how modern DAST (Dynamic Application Security Testing) solutions, specifically designed to find BFLA vulnerabilities, can significantly enhance API security. Mainly, we will look at StackHawk and how its DAST platform can help you find and fix these issues before they can be exploited. First, let’s take a deeper look at the nuances of BLFA, beginning with a closer look at what it is.
What is Broken Function Level Authorization (BFLA)?
Broken Function-Level Authorization (BFLA) occurs when an application or API fails to enforce authorization controls at the function level properly. This means users can access functionality, perform actions, or retrieve data that should be restricted based on their role or permissions.
We can imagine this description through a simple example to bring it to what it looks like in the real world. In most cases, applications and the APIs that power them often have different functions for different user types. Regular users might have basic profile updating capabilities, while administrators likely have the power to delete accounts, modify system settings, or access sensitive data across users. BFLA vulnerabilities occur when the restrictions that govern who and how users can use APIs aren't correctly implemented. In the example above, a regular user may gain admin privileges, allowing them to delete users from the application even though they should not be allowed to have access to this unauthorized functionality. This would be a consequence of BFLA.
A BFLA usually involves a few steps to execute. Here is a simplified outline of how attacks often work:
Mapping the API: An attacker analyzes API requests and responses, observing how different functions and endpoints are structured within an application's APIs.
Identifying Authorization Gaps: Next, attackers look for patterns in how the API maps permissions to functions. For example, can the attacker access an admin function by changing a simple parameter in the API call?
Exploitation: Once a potential vulnerability is spotted, the attacker experiments by sending requests intended for higher-privileged users or restricted functions, testing if the API will wrongly grant them access. If they are successful, the BFLA vulnerability has been successfully exploited.
If you read the above description and thought, “That sounds a lot like Broken Object-Level Authorization (BOLA)!”, you’d be somewhat correct. Both are related but involve slight nuances, hence why they are listed as separate vulnerability types within the OWASP API Security Top Ten. Let’s take a closer look at their differences and similarities.
What Are The Differences Between BFLA vs. BOLA?
While BFLA (Broken Function Level Authorization) and BOLA (Broken Object Level Authorization) are both dangerous API vulnerabilities, understanding their distinctions is crucial for effective protection:
The core issue surrounding BOLA centers on an attacker's ability to access data objects to which they shouldn't have rights. This often involves manipulating direct object identifiers within API requests.
For instance, let’s say there is an endpoint such as [GET] /patient/:patientID that allows users to access data about their personal medical profile. The user can only access their profile and private medical details if authorization is set up correctly. However, without the authorization checks in place, an attacker could change the patientID in the URL to include the ID of other patients, granting them access to their profiles and exposing personal data. In this scenario, this would be considered a BOLA vulnerability
With BFLA, the way the attack is executed and the results can be slightly different. In the case of a BFLA vulnerability, the issue arises when an API doesn't correctly restrict who can use what functions. Attackers gain the ability to perform actions meant for higher-privileged roles that should only be available to users in the upper user hierarchy.
Using the previous example, let's say that there is a corresponding [POST] /patient/:patientID endpoint that allows doctors to update charts, medical history, and diagnosis in a patient's profile. If an attacker has successfully realized that they have access to the [GET] endpoint, they can easily change the HTTP method to [POST], add false information to the request, and if the proper checks aren't in place, update a patient's medical records on the system even though it is not a legitimate request.
For a quick reference to compare the two, here’s a more concise look:
Both attacks are similar but with different outcomes and slightly different execution paths. That being said, there are some overlaps. BFLA and BOLA stem from the failure to correctly implement authorization logic within the API, which could lead to unauthorized data access or account takeover. However, you can think of BOLA as a subset of BFLA. BFLA addresses a broader range of authorization issues, encompassing unauthorized object access and the misuse of various API functions. While closely linked, BFLA highlights that API authorization flaws can lead to unauthorized access to both data and actions that a user shouldn't be able to perform.
The Root Causes of BFLA
BFLA vulnerabilities typically stem from development practices prioritizing ease of implementation without considering authorization controls to safeguard data and functions. Let's take a quick look at the most common factors contributing to the appearance of BFLA vulnerabilities within APIs.
Over-reliance on Object Identifiers: When APIs use predictable object references (like sequential IDs or easily guessable strings), attackers can manipulate them with simple changes in API requests, opening the door to unauthorized data access.
Lack of Ownership and Permission Verification: APIs must consistently verify two things on every request: that the user attempting an action owns the object they're targeting and that the user has the necessary permissions for that action. Omitting these verifications increases the risk of a BFLA vulnerability.
Blind Trust in User Input: Any data a user provides, including object identifiers and function parameters, must be treated as raw and potentially malicious. Thorough input validation and sanitization are essential to prevent injection attempts designed to break the API's logic.
Insufficient Focus on Authorization: Security can sometimes become an afterthought in development. This can lead to inconsistent authorization across different API endpoints or a complete lack of protection for specific functions. Unfortunately, some developers may not be aware that these types of attacks are possible, so authorization mechanisms are not included in the APIs' design.
The Fallacy of Obscurity: Developers might wrongly assume that using long, hard-to-guess object identifiers (e.g., UUIDs) is sufficient. These identifiers are better than sequential ones; however, determined attackers will still find ways to discover or predict them. Security through obscurity should not be relied upon.
When boiled down, BFLA is simply a failure to explicitly and meticulously implement both object-level and function-level authorization checks within the API. Much of the time, convenience and a false sense of security are at the root of this vulnerability. The desire to move quickly must never override robust authorization mechanisms.
Examples of BFLA in Action
In addition to the example discussed in the previous section, there are quite a few other ways this vulnerability can manifest and be executed. Below, we will look at a few simple example attack scenarios where a BFLA vulnerability is being exploited.
Scenario #1: E-commerce Cart Manipulation
In our first example, imagine an online store where users can buy various items through a checkout. As part of the online stores API, users' shopping carts are managed through an API call that allows items to be added or removed from their cart. This API may look similar to this:
PUT /api/cart/items
{
"userID": 12345,
"items": [
{"productID": 67890, "quantity": 2, "price": 50.00},
... // other items
]
}If the API fails to verify that the userID matches the logged-in user, an attacker could modify other shoppers' carts. They could add expensive items, remove items to prevent purchase, or even alter prices at checkout. The result could upset customers and have an impact on operations and revenue.
Scenario #2: IoT Device Sabotage
Next, imagine a smart home system with API controls for various devices. These devices can be manipulated through a POST request and a specific action. An example of such an endpoint might look like this:
POST /api/devices/{deviceID}/action
{
"action": "turnOff",
... // additional settings
}If the device associated with the DeviceID is not verified to belong to the user initiating the request and the API doesn't carefully restrict actions based on user roles, unauthorized control becomes possible. If authorization checks aren’t properly implemented, an attacker could remotely turn off critical systems, lock users out of their homes, or create other disruptions within the smart home system.
Scenario #3: Leaky News Feed Manipulation
Lastly, imagine a news aggregator platform that users can use to get a customized news feed based on their preferences. In this case, there is an API to customize a user's news feed through a PATCH operation. This can set which news topics the user wants to see in their feed. Below is an example of what such an endpoint may look like.
PATCH /api/feed/preferences
{
"userID": 12345,
"topics": ["technology", "science"],
... // other preferences
}If the userID is not validated by ensuring the user who is making the change is, in fact, the user to whom the account belongs, an attacker could inject malicious news sources or remove trusted ones. The result is a manipulated news feed that manipulates the information a user sees. In the most severe cases, this is a potential vector for spreading misinformation.
The key takeaway from these examples is that BFLA vulnerabilities can manifest in various applications, from e-commerce to smart home systems and even news consumption platforms. If an API is used to access, create, or edit data, BFLA vulnerabilities could impact it. This is where prevention becomes an important part of building and maintaining APIs, and we will cover how to protect against BFLA in the next section.
Protecting Against BFLA
With the various ways BFLA can be exploited, securing your APIs against BFLA requires a proactive approach. Core to this is a strategy that embeds authorization into the core of your API development process. Here are key strategies to consider and implement when building APIs to be hardened against
Rethink Object Identifiers and Session Management: Avoid using simple, predictable object identifiers (like sequential numbers). Opt for more complex identifiers, like UUIDs, which are harder to guess. Implementing a session management system that associates object references with specific user sessions and their verified permissions may also make sense.
Meticulous Authorization Checks: Enforce authorization at every API endpoint. Verify the user's identity and roles, and cross-reference their permissions with the data or function they're attempting to access. This should be applied consistently across all business functions within your application.
Input Validation and Sanitization: Rigorously validate and sanitize any data provided by users, especially when used in object identifiers, function calls, or parameters. This defends against injection attacks aimed at subverting API logic.
Principle of Least Privilege: Grant users and system components the absolute minimum permissions required for their roles or tasks. This limits the potential damage if an account or component is compromised.
API Gateways: Centralize authorization mechanisms with an API gateway for a more consistent and scalable security approach. An API gateway can make it easier to implement authorization checks across your API endpoints that proxy through the gateway.
Administrative Function Protection: Ensure that administrative functions (both within administrative controllers and regular controllers) have authorization checks based on user roles and groups.
Regular Testing: Integrate security testing, including DAST solutions specifically designed to find BFLA vulnerabilities, into your development lifecycle to continuously verify the effectiveness of your authorization controls. A combination of automated and manual testing is the best way to ensure endpoints are entirely secure from BFLA attacks.
Based on the last point, it makes sense to explore how StackHawk can help developers implement automated testing using its DAST platform to identify and remedy BFLA vulnerabilities. Next, let's dig into how StackHawk works regarding BFLA detection.
How StackHawk Can Help Detect and Prevent BFLA
When it comes to traditional DAST solutions, BFLA detection is not one of the vulnerabilities they are capable of discovering. Luckily, StackHawk goes beyond traditional DAST solutions by actively testing for BFLA and IDOR vulnerabilities.
StackHawk is a modern, powerful DAST tool designed for developers to integrate application security testing seamlessly into their software development lifecycle. It is not just another security tool; it's a developer-first platform emphasizing automation, ease of use, and integration into existing development workflows.
At its core, StackHawk is built around empowering developers to take the lead in application security. It provides a suite of tools that make it easy to find, understand, and fix security vulnerabilities before they make it to production. One of the key components of StackHawk is HawkScan, a dynamic application security testing (DAST) tool that scans running applications and APIs to identify security vulnerabilities.
With StackHawk, developers and security teams can:
Automate Security Testing: Integrate security testing into CI/CD pipelines, ensuring every build is automatically scanned for vulnerabilities.
Identify and Fix Vulnerabilities: Receive detailed, actionable information about each vulnerability, including where it is in the application code and how to fix it.
Test in All Environments: Use StackHawk in various environments, including development, staging, and production, to catch security issues at any stage of the development process.
Customize Scans: Tailor scanning configurations to suit specific applications and environments, ensuring more relevant and accurate results.
By focusing on a developer-first approach to security testing and integrating smoothly into existing dev tools and practices, StackHawk demystifies application security, making it a more approachable and manageable part of the software development lifecycle. Next, we will look at exactly how simple it is to configure StackHawk to begin testing your applications for potential BFLA vulnerabilities.
Enabling BFLA Detection in HawkScan
Enabling BFLA detection in StackHawk is easy. Two ways to do this are using the "OpenAPI - Experimental" policy or customizing an existing policy. The "OpenAPI - Experimental" policy allows users to scan for the vulnerabilities outlined in the OWASP API Security Top 10.
To set HawkScan up with the "OpenAPI - Experimental" policy, you will log into StackHawk, go to the Applications screen, and click on the settings link for your application.
Next, on the Settings screen, under HawkScan Settings, click the Applied Policy dropdown and select the "OpenAPI - Experimental" policy.
At this point, you can then run HawkScan and begin detecting potential BFLA vulnerabilities. Another way to do this is to customize an existing policy to scan for BFLA vulnerabilities.
To demonstrate this, we can navigate to the same HawkScan Settings section we looked at above. We will select the "OpenAPI/REST API" policy from the Applied Policy dropdown.
Next, click the Edit Policy button right beside the dropdown.
On the next screen, under the Plugins and Tests section, click on the BFLA entry to enable HawkScan to perform tests for potential BFLA vulnerabilities.
Optionally, if you also want to enable IDOR testing, click the Passive Scan Plugins tab and then select IDOR.
Regardless of how you have enabled BFLA testing in HawkScan, your tests will include testing for potential BFLA vulnerabilities (and IDOR, if you enabled it)!
Conclusion
Understanding BFLA is an essential part of creating secure APIs. However, implementing the necessary authorization mechanisms to protect against these vulnerabilities in real-world applications can be challenging for developers. To ensure that BFLA prevention is applied to API endpoints, organizations should aim to empower developers with the right tools and knowledge to make security a foundational element of API design.
StackHawk does more than just help developers identify potential BFLA vulnerabilities in running applications. It helps bridge the gap between finding and fixing flaws, offering clear explanations and step-by-step remediation advice while integrating seamlessly into existing development workflows. StackHawk’s “shift-left” approach makes API security more accessible and promotes a culture of secure coding practices among developers.
With StackHawk, you can take a proactive approach to finding and fixing BFLA threats before they can hit production. Detect and address vulnerabilities early, safeguarding your APIs and the sensitive data they handle. Sign up for a 14-day free trial of StackHawk and experience the difference it makes in tackling BFLA risks and broader API security challenges outlined in the OWASP API Top 10.
