👋Hey security enthusiasts! 🚀

Welcome back, to this blog which is the 24th part of our Hacking API series. In the previous blog, we covered BOPLA (Broken Object Property Level Authorization) and Mass Assignment — both critical vulnerabilities related to improper access control at the object property level.

📌 Today, we'll dive into another serious authorization vulnerability: Broken Function Level Authorization (BFLA). This flaw allows attackers to execute functions beyond their assigned privileges, leading to privilege escalation, lateral movement, and unauthorized actions.

None

🚨 What is Broken Function Level Authorization (BFLA)?

BFLA occurs when APIs fail to enforce proper access control on function-level actions. This means users can execute functions they shouldn't have permission for, such as: ✅ Performing administrative actions as a regular user. ✅ Manipulating resources of other users/groups at the same privilege level. ✅ Executing restricted API functions (e.g., deleting users, modifying roles).

Broken Function Level Authorization (BFLA) is a critical API security vulnerability where users can execute functions beyond their privileges due to improper access control mechanisms. It is an authorization problem related to actions, not just access to resources. This vulnerability can allow users to execute functions they shouldn't have permission for, such as: ✅ Performing unauthorized actions that belongs to higher privilege levels (privilege escalation). ✅ Manipulating resources of other users/groups at the same privilege level(lateral privilege misuse).

🛑 Key Characteristics of BFLA

1. Role or Privilege Escalation:

  • A user with limited access can perform administrative or other privileged actions they shouldn't be allowed to.
  • 📌Example: A regular user performing administrative tasks like deleting or modifying another user's account.

2. Lateral Functionality Access:

  • A user from one group accesses functionality meant for another group with similar privileges.
  • 📌Example: A partner user modifying resources of another partner group without authorization.

3. Action-Oriented Misuse:

  • Unlike BOLA (Broken Object Level Authorization), which deals with unauthorized access to resources (e.g., viewing another user's account), BFLA involves unauthorized execution of actions (e.g., transferring money, deleting data, or modifying privileges).

🔍 Why Does BFLA Occur?

1. No Role-Based Access Control (RBAC)

The API does not check whether the user is authorized for a specific function.

📌Example: 🔹If an API allows all users to access /admin/create-user, any user might execute this admin-only function.

2. Inconsistent Authorization Checks

Some API endpoints implement security, while others fail to enforce proper access control.

📌 Example: 🔹 DELETE /user/delete-account – properly protected. But, 🔹 POST /user/delete-other-user – unprotected. Attackers will find and exploit the unprotected function.

3. Exposing Sensitive API Functions

Some APIs unintentionally expose critical functions meant for internal use only.

📌 Example: 🔹If an API has POST /admin/reset-password open without authentication, any user could reset any account's password.

🎭 Techniques for Exploiting BFLA

🎯 1. Modifying API Requests

Attackers manipulate API parameters to execute unauthorized functions. 📌 Example:

PUT /user/role?role=admin

🚨 If accepted, a regular user becomes an admin!

🎯 2. Testing API Authorization Bypasses

Attackers directly test API endpoints to check if can they execute without permission. 📌 Example:

POST /admin/delete-user

If no authorization check exists, attackers can delete any user!

3. Manipulating HTTP Methods

  • If DELETE /user/999 is blocked, but PUT /user/999 is allowed, attackers abuse PUT requests to modify user data.

4. Exploiting Weak Session Handling

  • APIs that rely on session-based authentication can be exploited with stolen session tokens to execute admin-only functions.

🛠️ What Does a BFLA Attack Look Like?

🚨 Example Attack: Unauthorized Account Deletion

None

In the example above, the attacker has changed the method from POST to DELETE allowing them to delete the account associated with user_id=exampleId_100. Access to the DELETE method should have been restricted to users with administrative access but was allowed due to an inadequate authorization policy.

For more real-world examples, check out: 🔗 Example 1: BFLA Exploitation 🔗 Example 2: API BFLA Vulnerability

🔍 How is BFLA Different from BOLA?

In a BOLA (Broken Object Level Authorization) vulnerability, a user can modify another user's details if proper authorization checks are missing. This raises the question: Shouldn't this be classified as BFLA instead of BOLA?

Not quite! This scenario still falls under BOLA rather than BFLA (Broken Function Level Authorization).

❓Why This is BOLA?

  • The vulnerability occurs at the object level, meaning a user is modifying another user's data without proper authorization.
  • It involves direct access to an object (user data) rather than improper access to a restricted function or role-based action.

❗When Would It Be BFLA Instead?

If the attacker was accessing or performing a function they shouldn't have permission to use, then it would be BFLA.

For example:

None

Here, a regular user is accessing an admin-only function to create accounts, which falls under Broken Function Level Authorization (BFLA).

📌Key Difference: BOLA vs. BFLA

None

🛡️Preventing Broken Function Level Authorization (BFLA)

1. Implement a Centralized and Auditable Authorization Module

  • Keep authorization logic separate from business logic for consistency and easier audits.
  • Regularly review and update authorization rules to detect misconfigurations.

2. Enforce Authorization Checks on All Administrative and Sensitive Functions

  • Apply strict role verification for admin functions and privileged actions.
  • Restrict direct access to admin API endpoints to prevent unauthorized execution.

3. Adopt a "Deny by Default" Policy

  • Restrict all API functions by default and allow access only to designated roles.
  • Regularly review and refine access controls to prevent privilege creep.

4. Ensure Roles and Privileges Are Verified Before Granting Access

  • Validate user roles on every request before executing any function.
  • Prevent users from modifying their own roles to avoid privilege escalation.

5. Regularly Test API Endpoints for Authorization Vulnerabilities

  • Perform security audits and penetration testing to detect misconfigurations.
  • Use tools like Burp Suite and OWASP ZAP to simulate unauthorized API requests.

🎯References:

  1. Hacking APIs: Breaking Web Application Programming Interfaces by Corey Ball
  2. https://university.apisec.ai/products/api-penetration-testing/categories/2150251350/posts/2162155920
  3. https://salt.security/blog/api5-2023-broken-function-level-authorization
  4. https://www.stackhawk.com/blog/understanding-and-protecting-against-api5-broken-function-level-authorization/

🎉 That's it for this blog!

🚀 In the next blog, we will cover another critical vulnerability: Unrestricted Resource Consumption. Stay tuned for more API hacking insights! 🔥

Until then, happy hacking! 🔥

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Other Resources — https://drive.google.com/drive/folders/1BwqTCgRTnD7Esic4RK9rpUBUqGrjPqGX?usp=sharing

Connect me on Linkedin- https://www.linkedin.com/in/vishal-sharma-945647241/