API5:2019 Broken Function Level Authorization: The What, Impact, Sample Exploit, and Prevention Methods

APIs are great for accessing specific functions and features, but what happens when they allow unauthorized access?

Imagine a social media platform where users can share posts. To enable users to access posts, the platform provides an API that allows GET requests to retrieve posts by specifying the user ID and post ID.

GET/api/v2.1/user/1438/posts?id=40.

The API will return the 40th post for user id 1438.

As these are public forums, any user can submit GET requests to access posts. However, POST and DELETE requests to modify/ edit/ delete that particular post can only be submitted and performed by user 1438.

However, what if the API allows any user to edit/ modify/ delete posts of other users? Then, it is a classic case of broken function level authorization (BFLA).

Broken function level authorization is an OWASP Top 10 API 2019 security risk, ranked 5th.

What is Function Level Authorization? 

Before delving into what API5 broken function level authorization is, we need to understand the concept of function level authorization in APIs.

Function level authorization is a security mechanism used in software applications and APIs to control access to specific functions or actions based on the user’s level of privilege or authorization. It is a granular form of access control that ensures that users can only perform actions or access resources they are authorized to, based on their role or permission level.

For example, a financial API/ app may have different user permission levels based on their roles, such as a teller, manager, or administrator. Each role may have access to different functions or actions within the application, such as viewing customer data, processing transactions, or changing account settings.

Function-level authorization enforces access controls at the function level so that verifications and permission checks protect each function or action. If the user doesn’t have the required permission level, the access is denied, and the action is blocked.

By implementing function-level authorization, applications can ensure that only authorized users can access sensitive data and functions, reducing the risk of data breaches, unauthorized access, and other security threats.

What Is API5:2019 Broken Function Level Authorization? 

Broken function level authorization refers to an application programming interface (API) vulnerability that allows unauthorized access to certain functions or features that should be restricted based on the user’s role or permissions. In other words, it is when hierarchical permission systems in APIs are broken or missing.

When the function level authorization API is broken, attackers can bypass the security controls and access restricted functions or actions they cannot perform. This can lead to various security risks, such as unauthorized data access, modification, deletion, and privilege escalation attacks.

Broken Function Level Authorization vs. Broken Object Level Authorization 

BFLA is similar to broken object-level authorization (BOLA); both result from improper/ inadequate authorization mechanisms for validating user requests to the API. In both cases, attackers gain unauthorized access to resources, data, etc., and/or can engage in account takeovers, privilege escalation, or other malicious activities.

The main point of difference is that BFLA targets function while BOLA targets objects that the APIs interact with.

Broken object-level authorization vulnerabilities expose object identifiers that allow unauthorized users to access or modify objects they should not have access. These vulnerabilities are weak access controls, flawed authentication mechanisms, or inadequate user input validation.

// Insecure API endpoint to update an order
app.put('/api/orders/:id', function(req, res) {
// Extract order ID from request parameters
const orderId = req.params.id;
// Extract order data from request body
const orderData = req.body;
// Update order in the database
db.updateOrder(orderId, orderData);
// Send response to client
res.send('Order updated successfully');
});


In the example above, the API endpoint allows any user to update an order by specifying the order ID in the request parameters and providing the updated order data in the request body. However, there’s no check to verify if the user has the appropriate authorization to update the order. This could lead to unauthorized access to sensitive information, such as modifying other users’ orders.

On the other hand, broken function-level authorization vulnerabilities enable unauthorized users to access or execute functions they should not have access to. These vulnerabilities include weak access controls, lack of authorization checks, and lack of input validation.

// Insecure API endpoint to delete an order
app.delete('/api/orders/:id', function(req, res) {
// Extract order ID from request parameters
const orderId = req.params.id;
// Delete order from the database
db.deleteOrder(orderId);
// Send response to client
res.send('Order deleted successfully');
});

In the example above, the API endpoint allows any user to delete an order by specifying the order ID in the request parameters. However, there’s no check to verify if the user has the appropriate authorization to delete the order. This could lead to unauthorized access to sensitive information, such as deleting other users’ orders.

Both vulnerabilities can be fixed by implementing proper authorization checks and validating the user’s permissions before granting access to resources or functions.

What Causes BFLA Vulnerabilities? 

1. Insufficient or weak access controls

This is one of the main reasons BFLA flaws occur in APIs. Proper, role-based access controls restrict access to specific functions or operations based on user roles and permissions. When these policies are improperly designed or implemented, unauthorized users can perform actions they should not have access to.

But designing and implementing such access controls in APIs is challenging because of the varied roles, groups, and hierarchies. APIs with a high number of roles, complex functions, varied permissions, and access requirements are particularly at a higher risk of broken function-level authorization flaws.

2. The inadequate separation between admin and general functions

When developers do not create proper separation between general API and administrative functions, unauthorized users can perform functions they otherwise shouldn’t. This could happen if the user functions are too complex and the developer is unable to create enough separation.

3. Poor design or implementation of authorization mechanisms

APIs may have flaws in their authorization mechanisms, such as missing or insufficient checks for user roles or permissions or using predictable or easily guessable tokens or session IDs.

4. Lack of proper input validation

APIs may not properly validate user input or parameters, which can lead to attackers manipulating authorization tokens or session IDs.

5. Flaws in session management

APIs may have vulnerabilities in their session management mechanisms, such as weak session IDs or session fixation attacks, enabling attackers to hijack sessions and bypass authorization checks.

6. Inadequate security testing

APIs may not undergo regular security testing to identify and address vulnerabilities, including BFLA flaws.

How do BFLA Attacks Work? 

API5:2019 broken function level authorization attacks begin with attackers gaining illegitimate access to APIs. This is done using phishing scams or impersonating a legitimate user. Then, the attacker uses scanning tools to find BFLA flaws in APIs. So, they will look for permissions to access resources directly, broken authorization checks, etc.

With RESTful APIs, where calls are predictable and structured, discovering BFLA flaws is much easier. Even when API documentation and schema definitions don’t exist, attackers can simply reverse engineer client-side code and intercept API traffic. Some API endpoints may also be exposed to regular users, enabling attackers to discover flaws more easily.

Once the flaws are discovered, attackers send legitimate API requests to the endpoints they shouldn’t otherwise have access. Or they may intercept API requests from client apps and modify them to do their bidding. For instance, they could change a GET request to a PUT/ DELETE request or alter the query parameter or message body, changing the user to admin in the API request.

Now, the attacker will have privileges and permissions to do their bidding and wreak havoc.

Real-Life Instances 

1. Uber 2016

Uber faced a data breach where hackers stole the personal information of over 57 million users and drivers, including names, email addresses, and phone numbers. The breach was caused by a vulnerability in Uber’s API, which allowed unauthorized access to the company’s database. The attackers bypassed the function-level authorization controls, obtained authentication tokens, and gained access to sensitive user data.

2. Amazon Web Services 2017

A researcher discovered a vulnerability in Amazon Web Services (AWS) API that allowed attackers to access other AWS users’ sensitive data, including authentication tokens, passwords, and private keys. The vulnerability was caused by an issue in the company’s implementation of the Simple Storage Service (S3) API, which allowed attackers to exploit certain configuration settings and bypass authorization checks.

3. Instagram 2018

Instagram disclosed a vulnerability in its API that allowed attackers to access millions of user data, including names, email addresses, and phone numbers. The flaw was caused by an issue in the company’s “Download Your Data” feature, which allowed users to download a copy of their data. Using this broken function level authorization flaw, attackers could bypass authorization checks, gaining illegitimate access to user data.

4. GitHub 2020

GitHub faced a security incident where attackers could steal over 1000 private repositories. The incident was caused by a vulnerability in GitHub’s API, which allowed attackers to bypass the function-level authorization controls and gain access to sensitive repositories.

Check out our blog on the most notorious hacks in history that fall under OWASP Top 10!

Why is API5:2019 Broken Function Level Authorization So Dangerous? 

Broken function level authorization has remained in the same position in the OWASP API Top 10 2023.  It indicates that it remains a critical security risk for APIs. This highlights the importance of addressing this vulnerability and implementing appropriate security controls to protect against it.

1. Growing Prevalence of BLFA Attacks 

The prevalence of broken function-level authorization vulnerabilities in APIs is underscored by numerous real-world examples of data breaches and security incidents caused by this vulnerability. Organizations like Facebook, Uber, and Instagram have all experienced BFLA vulnerabilities that have exposed sensitive user data. As per OWASP, BFLA has a prevalence score of 2, meaning it is a common API security risk.

2. Widening Attack Surface

APIs can have a broad attack surface, with multiple endpoints and functions that attackers can target. A BFLA vulnerability in an API can provide a single-entry point for attackers to access multiple functions and resources, allowing them to carry out sophisticated attacks.

With BFLA flaws, attackers can

• access, modify, and delete sensitive resources
• collect/ expose/ sell PII and other sensitive resources
• engage in data theft, identity theft, brand impersonation, extortion, and much more using stolen data
• take over user accounts
• create/delete accounts or data
• escalate privileges to achieve administrator access, then attack API and app.
• orchestrate denial of service attacks, etc.

3. Exploitability 

API5 broken function level authorization has an exploitability score of 3, which is easily exploitable. In APIs with complex roles, permissions, and access requirements, in particular, the possibility of these flaws is much higher, and so is the risk of exploitation. Further, attackers have several freely available tools and intelligent automation to perform BFLA attacks at scale.

4. Detectability 

BFLA vulnerabilities have a detectability score of 1, meaning they are difficult to detect. BFLA vulnerabilities are often caused by developers failing to implement proper access controls and authorization checks in their APIs. This can make it difficult to detect BFLA vulnerabilities during an API’s development and testing stages of an API, as the functionality and access controls may not be fully defined or understood.

How to Protect Yourself Against Broken Function Level Authorization? 

1. Enforce Strict Role-Based Access Controls 

Organizations must strictly enforce role-based access controls, defined granularly, to ensure users and user groups only have access to those functions, properties, and data as necessary. Feature restrictions and access controls must be defined for each user/ user group function.

2. Implement Zero Trust Policies 

Organizations must enforce the principle of least privileges, denying requests by default and requiring user authentication and authorization for sensitive functions. Remember that the onus of seeking permissions should not be on the clients; do not rely on clients to enforce admin access.

3. Authorization Must Be Designed Properly and Tested Adequately 

Organizations must properly design and adequately test their API and API endpoints for authorization to ensure no broken function-level authorization flaws.

4. Regular Security Assessments and Pen-testing 

Detecting broken function-level authorization flaws in APIs can be challenging, but it is not impossible. Through regular security assessments, source code review, dynamic analysis, API-specific intelligent scanning tools, and manual pen-testing by trusted experts, it is possible to detect these flaws before attackers do and secure them.

API pentesting can help uncover BFLA vulnerabilities by testing for function-level authorization issues. One such method is to try accessing privileged APIs with lower-privileged roles and verifying that unauthorized users are denied access.

Here is a comprehensive checklist of use cases to consider when conducting API penetration testing.

How AppTrana WAAP Helps?

Attackers develop BFLA attacks by gathering information through trial and error until they gain unauthorized access to data. AppTrana detects such unusual behavior and assigns risk scores to potentially harmless traffic. If the risk score of an entity exceeds a certain threshold, AppTrana blocks it. It prevents API attacks by identifying abnormal API activity on a specific endpoint.

The infinite API scanner can identify the endpoints of the API and test them for known security issues, including the OWASP API Top 10 vulnerabilities. In addition to flagging API vulnerabilities, our WAAP platform enables virtual patching of poorly constructed API endpoints.

For instance, we guarantee that API calls that execute administrative functions are preceded by a page load that enumerates such capabilities or a successful login to an administrative site.

Managed security services team can configure security rules to block requests to specific functions or URLs based on the user’s role or permissions. For example, if a user with a lower authorization level attempts to access a function reserved for privileged users, the WAF can block the request and prevent unauthorized access.

Here is a detailed blog on how security rules determine whether to allow, block, or log requested traffic based on matching criteria.

WAAP blocks requests that are not properly formed or contain suspicious values by validating parameters used in HTTP requests. This helps prevent broken function-level authorization attacks by blocking requests with modified parameters meant to bypass authorization checks.

WAAP can also provide detailed logs of all traffic, including blocked requests, which can be used for forensics during an attack. These logs can help identify the specific requests and parameters used in a broken function-level authorization. These details can then be used to create more robust security policies to prevent similar attacks from occurring in the future.

Stay tuned for more relevant and interesting security updates. Follow Indusface on Facebook, Twitter, and LinkedIn