The Risks of Broken Function Level Authorization(BFLA) and How to Mitigate Them with an API Gateway


API Gateway Blog Calendar
  June 12, 2023
Api Gateway Tag
  API Gateway

Securing APIs from Misconfiguration Attacks. Best practices and mitigation strategies


APIs are used everywhere to access backend services and sensitive information such as bank details, health reports, financial data, company sensitive information, etc. This makes APIs that are vulnerable or exposed, open to create an attack surface and raises the risk of API attacks that could cause serious disruption. If you are aware of the technology bubble of API security, you must have heard about the OWASP API security project. It consists of the top 10 vulnerabilities that threaten APIs, and Broken Function Level Authorization (BFLA) is one of them.


What is a Broken Function Level Authorization Attack?

Most organizations offer various access levels to employees in different departments like documentation, marketing, development and more. The possibility of broken function-level authorization (BFLA) increases when access control is improperly handled at the API level.

Basically, BFLA occurs when APIs have a bug in their hierarchical authorization mechanisms. The attacker aims to modify API calls to gain unauthorized access to higher levels, like the administration level, and then performs administration tasks like adding, modifying, or deleting data.

Let's understand the BFLA Attack by the following scenario: Consider an example of API which fetches user information as shown below :


Protect against broken function level authorization (BFLA) using miniorange Xecure API Gateway

If an attacker tries to modify the method to delete and change the user keyword in the path to admin, the attacker gains access to the admin role and can perform a delete action.


Protect against broken function level authorization (BFLA) using miniorange Xecure API Gateway

Due to the lack of API access control handling on the server side, the attack was succesful.

Example of a BFLA Attack

Let's say there is an online banking application that allows users to transfer funds between their accounts. The application has different levels of authorization, where regular users can only transfer funds within their own accounts, while administrators can transfer funds between any accounts.

In this scenario, a BFLA vulnerability exists if the application fails to check the user's role or privileges before processing a fund transfer request. For instance, if a regular user tries to transfer funds from one account to another that does not belong to them, the application should deny the request. However, due to the broken function level authorization, the application might overlook this check, allowing the unauthorized transaction to proceed.

An attacker could exploit this vulnerability by manipulating the request parameters or intercepting the request using a proxy tool. By changing the target account number to another user's account, they can trick the application into transferring funds from the victim's account to their own.


How to Prevent a BFLA Attack?

To mitigate BFLA vulnerabilities, it is essential to implement robust authorization checks at every function or feature level, ensuring that users are properly authenticated and authorized for the actions they attempt to perform. An API Gateway can help with this.

The following features of an API gateway can help prevent Broken Function Level Authorization attacks :

  • Centralized Authorization: Every request to the backend passes through the API gateway. We can enforce authorization logic or policies at the gateway level. So across all API endpoints, you can guarantee reliable and consistent enforcement.

  • Access Control Policies: In the gateway, you can define different fine-grained action control policies. Users can also define role-based access control so each role has limited permission to access the resources which ultimately helps to prevent unauthorized access.

  • Rate Limiting: API gateway rate limit functionality permits a limited number of requests from clients simultaneously, thus preventing overuse of the function and assisting in the analysis of odd patterns in API calls.