Get the latest Gartner® insights on API Protection

Learn more

API5:2019 Broken Function Level Authorization

Michael IsbitskiMichael Isbitski
Feb 11, 2021


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 similarity to BOLA in this regard, though the target with BFLA is API functions as opposed to objects that APIs interact with as in the case of BOLA. Attackers will attempt to exploit both vulnerabilities when targeting APIs in order to escalate privileges horizontally or vertically. 

Attackers discover these flaws in APIs since 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.

Attackers can exploit these flaws by sending legitimate API requests to an API endpoint that they 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.

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

Potential Impact

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.


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 users can escalate privileges to add or modify alerts

In 2018 Jon Bottarini found that a restricted user could make changes to alerts on Synthetics monitors without the proper permissions to do so. In fact, they could make changes with no permissions at all as a result 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, Jon captured traffic of a privileged session using an intercepting proxy tool, Portswigger Burp Suite. In particular, this traffic included a POST request to an API endpoint and function that creates alerts on Synthethics 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 You

Traditional security controls like WAFs and API gateways lack context of API activity and therefore do not know that the attacker in the 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 Facebook 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 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 DELETE example above. It is critical that the solution 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 as in the Facebook example above.

Previous posts:

OWASP API Security Top 10 Explained

API1:2019 Broken Object Level Authorization

API2:2019 Broken User Authentication

API3:2019 Excessive Data Exposure

API4:2019 Lack of Resources & Rate Limiting

Next posts:

API6:2019 Mass Assignment

API7:2019 Security Misconfiguration

API8:2019 Injection

API9:2019 Improper Assets Management

API10:2019 Insufficient Logging & Monitoring

Go back to blog

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

Get the guide