Subscribe to the Salt blog to learn about the latest developments in API Security

Blog Post


API5:2023 Broken Function Level Authorization (BFLA)

Stephanie Best
Jun 6, 2023

Authorization flaws are often the result of improperly implemented or misconfigured authorization. Implementing adequate authorization mechanisms is a complex task, since modern applications can contain many types of roles, groups, and user hierarchy such as sub-users and users with more than one role. This is further complicated with distributed application architectures and cloud-native design. Broken function level authorization (BFLA) shares some similarities to broken object level authorization (BOLA) in this regard.

Attackers can discover these flaws in APIs because API calls are structured and predictable, even in REST designs. This can be done in the absence of API documentation or schema definitions by reverse engineering client-side code and intercepting application traffic. Some API endpoints might also be exposed to regular, non-privileged users making them easier for attackers to discover.

These flaws can be exploited by sending legitimate API requests to an API endpoint that the attackers should not have access to or by intercepting and manipulating API requests originating from client applications. As an example, an attacker could change an HTTP method from GET to PUT. Alternatively, the attacker might also alter a query parameter or message body variable such as changing the string “users” to "admins" in an API request.

What is the difference between BOLA and BFLA?

Broken function level authorization (BFLA) can be considered a higher-level version of broken object level authorization (BOLA). The main difference is that, when exploiting a BFLA vulnerability, an attacker focuses on general API functions rather than individual API objects. The consequence of BFLA is that clients can access functionality beyond their intended access level, such as administrative functions.

Attackers will attempt to exploit both vulnerabilities when targeting APIs in order to escalate privileges horizontally or vertically.

Learn how to secure APIs in dev and runtime and enable a model of continuous improvement

Potential Impact of a Broken Function Level Authorization Attack

Broken function level authorization (BFLA) has been identified as the fifth most critical threat to APIs in the OWASP API Security Top 10, and for good reason. In fact, attackers exploiting broken function level authorization vulnerabilities can gain access to unauthorized resources, take over another user’s account, create/delete accounts, or escalate privileges to gain administrative access.

What Does a BFLA Attack Look like?

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.

Real World Example: New Relic Synthetics

In 2018, cyber researcher Jon Bottarini found that a restricted user could make changes to alerts on New Relic Synthetics monitors without the proper permissions to do so. In fact, they could make changes with no permissions at all because of the privilege escalation weakness that was present in the product at that time. Exploitation involved submitting a legitimate request to an API endpoint that was otherwise not visible to the restricted user.

As part of his security research, Bottarini captured traffic of a privileged session using an intercepting proxy tool, Portswigger Burp Suite. This traffic included a POST request to an API endpoint and function that creates alerts on Synthetics monitors. He found that you could trap a GET request from the non-privileged session, retain the tokens and cookies for that restricted user, and alter the remainder of the trapped request to resemble the privileged POST request. This manipulation of API traffic to access functionality not visible in the UI (at all or to that user and their permissions) is a common technique attackers use to exploit function level authorization weaknesses and escalate privileges.

Why Existing Tools Fail to Protect your APIs Against BFLA

Traditional security controls like WAFs and API gateways lack the context of API activity and therefore do not know that the attacker in the first example above should not be able to send a DELETE method. This API call would be seen as legitimate and would pass through these security controls.

WAFs and API gateways sometimes support explicit, statically defined message filters, often referred to as a positive security approach. However, these approaches can inhibit or break business functionality, and most organizations find them difficult to operationalize at scale. Restricting HTTP methods is also an easier task than restricting API parameters and values, the latter of which requires deeper subject matter expertise on the design of the API.

The activity in the New Relic example above would be missed by WAFs and API gateways for the same reason. These security controls would not know that the 3rd party applications should no longer have access to the deprecated or restricted API functions. Tuning the controls would have required appropriate knowledge transfer between development, operations, and security teams to implement an appropriate static filter in the appropriate proxy within the overall enterprise architecture.

How to Protect your APIs from Broken Function Level Authorization Vulnerabilities

API security solutions must be able to continuously baseline typical HTTP access patterns per API endpoint and per user. With this baseline, API security solutions can identify calls with unexpected parameters or HTTP methods sent to specific API endpoints such as in the first example above.

It is critical that an API security tool is capable of baselining continuously, as APIs may go through a high rate of change as a result of modern development and release practices. API security solutions must be able to identify and prevent attackers or unauthorized users from accessing administrative level capabilities or unauthorized functionality.

To learn more about how Salt can help defend your organization from API risks, you can connect with a rep or schedule a personalized demo.


Salt Security Blog

Sign up for the Salt Newsletter for the latest resources and blog posts.

June 18, 2024

Salt Labs
Research Team

Salt Labs

Increasing API Traffic, Proliferating Attack Activity and Lack of Maturity: Key Findings from Salt Security’s 2024 State of API Security Report

The latest Salt Security State of API Security Report is out now, and we’re thrilled to give a little sneak peek of its contents.

Read more

June 12, 2024

Elad Hoffer
Head of Product R/T Protection


Salt Security Leading the Way in AI-Driven API Security for Next-Generation Threat Protection and Attacker Insights

Learn how the recent introduction of advanced LLM-driven attacker insights further solidifies Salt's position as a leader in API security solutions.

Read more

June 7, 2024

Eric Schwake
Head of Product Marketing

A Salt Security Perspective on the 2024 Gartner® Market Guide for API Protection

Salt Security's API Protection Platform is AI-infused and designed to address the challenges outlined in the Gartner report.

Read more

Download this guide for advice on evaluating key capabilities in API Security

Learn everything you need to know to keep your APIs secure

Get the guide