Mitigating OWASP API Security Risk: Broken Function Level Authorization using F5 BIG-IP

Introduction

As APIs continue to play a key role in powering modern web and mobile applications, they have also become prime targets for attackers. APIs expose business logic and sensitive data. Without adequate security measures, they can introduce critical vulnerabilities into an organization’s infrastructure. One such vulnerability is Broken Function Level Authentication (BFLA). This vulnerability occurs when an API fails to enforce proper authorization checks for different functions or actions. This allows users to perform operations they are not allowed to execute.

What is Broken Function Level Authentication?

Broken Function Level Authentication arises when the server does not verify whether an authenticated user has the appropriate authorization to access or execute specific functions or endpoints. While authentication confirms who the user is, authorization determines what that user is allowed to do. In many vulnerable systems, these two concepts are not clearly separated or enforced.

Example Scenario:

A classic example of BFLA referred to involves an attacker altering the HTTP method of a legitimate request. Consider the following scenario:

GET /api/users/123

This request allows a user to view their profile data. However, if the application does not restrict access to administrative or sensitive operations, the user could simply change the HTTP method to:

DELETE /api/users/123

If the server processes this request without validating the user's privileges, it could result in the deletion of user data. This is an operation that should be reserved for administrators or system owners.

Attack Demonstration:

For this demonstration, we will see how we can exploit the BFLA vulnerability in ‘DVAPI’ application. This application is added as a pool member to BIG-IP and can be accessed via a virtual server. For more information, refer to how to add pool member.

This application has an endpoint /api/user/<username> to fetch information of a user

Now let's change the method from GET to DELETE and see if we can delete the user.

The fact that the user was deleted successfully suggests that the application fails to enforce appropriate authorization checks for individual functions, enabling users to carry out actions they are not authorized to perform. This behavior is indicative of Broken Function Level Authentication (BFLA) vulnerability.

Mitigation using BIG-IP Access Policy Manager (APM):

Login to BIG-IP console and navigate to Access >> API Protection >> Profile and create a new profile with the following configurations.

Name: name of the profile

Open API File: Upload the Open API i.e. swagger file of the application

DNS Resolver Mode: f5-aws-dns

Other configs are set to default values

After creating the profile, you will see all the endpoints of the application under ‘Paths’ section. APM automatically reads the endpoints from the swagger file that is been uploaded. If any endpoint is not listed or missing, we can add them manually by clicking the ‘Create’ button.

Now navigate to the Access Control tab > Per Request Policy and click on edit; a new tab opens showing the policy mapping as shown in below screenshot

To restrict access to the DELETE method for the /api/user/<username> endpoint, update the endings from 'Allow' to 'Reject' for that endpoint.

Note: This application has a separate endpoint /api/admin/<username> for admin users to delete a user, so even after blocking /api/user/<username> endpoint admin users will still be able to delete users

Now again, let’s try to delete the user and see what happens

The ‘403 Forbidden’ response was returned because of the APM policy explicitly rejecting DELETE requests to this endpoint. Using BIG-IP APM, we can define granular access control policies to allow or deny specific HTTP methods for each application endpoint.

Conclusion:

Broken Function Level Authorization (BFLA) is a critical API vulnerability where users can perform unauthorized actions such as creating, modifying, or deleting resources simply by manipulating HTTP methods or endpoint parameters. By using BIG-IP APM, we can effectively mitigate BFLA risks by enforcing granular access control policies to explicitly allow or deny specific HTTP methods like GET, POST, or DELETE for individual endpoints based on user roles and security requirements.