Get a Demo

OWASP API Security Top 10 - Broken Function Level Authorization

Broken Function Level Authorization is the 5th API Security issue in the list of OWASP API Top 10 Security threats. For other blogs in this series, please refer to the below link:


Broken Function Level Authorization relates to the security issues arising due to improper validation of the authorization level of the user of an API and the function that it is intended to perform. At a very high level, APIs have performed the following  basic functionalities around data called CRUD  (Create, Read, Update and Delete). These functions encompass various resources and as per business logic, the execution of the CRUD functionalities via APIs is governed by authorization, role, and scope of the users using the API. As an example, consider an application with an API that allows the creation and updating of a user account and role. The user authorized to call such an API must have an admin role. Vulnerable implementation of the API which lets a user with a standard role, create new users and/or change the role of users to an admin,  resulting in a Broken Function Level Authorization security issue. This security issue is common with modern applications implementing improper checks due to the prevalence of several types of roles, scopes, and/or groups leading to a complex user access hierarchy.


Here is another example where this security issue manifests. Let’s say a third party user can view their user information in an application with an API “/api/user/{user_id}” by utilizing the GET method. The POST method on the same API can be abused to update the details about the user. Failure to implement the right access control check  by limiting the scope of the API user to  appropriate verbs, results in a broken functionality.


Note that both Broken Function Level Authorization (API5) security issue and Broken Object Level Authorization (API1), are related to access control and involve authentication & authorization modules as protection mechanisms. It is to be noted that while API5 attempts to explain about the access control at functionality level, API1 focuses on how the objects transacted within the API request-response should be protected. APIs tend to expose endpoints that handle object identifiers and allowing the enumeration of these object identifiers by unauthorized clients leads to API1. With API1, the attacker tends to use the same API where as in case of API5, the API structure will slightly change or the attacker might have to use a guessed/found API to access the forbidden functionality, as indicated through the example scenarios above. For more information on Broken Object Level Authorization (API1) security issues, please refer to this blog in OWASP API Top 10 series.


Now, let us go through a couple of real world attacks that can be categorized as Broken Function Level Authorization (API5) security issues.

NewRelic DELETE Filterset Settings by Normal user Vulnerability

NewRelic is a cloud-based software to help website and application owners track the performances of their services. A vulnerability researcher disclosed many vulnerabilities in NewRelic Infrastructure monitoring application and by exploiting one of these vulnerabilities, a normal user created by the admin was able to delete the filtersets created by the admin user. In NewRelic infrastructure monitoring, multiple filters can be created with respect to different parameters and these filters can be combined into a filter set to organize hosts based on criteria that is most useful for the user. Following endpoint is used to create the filterset. 


Any other user with restricted privileges invited by the admin to join a team where filtersets are already present can simply delete an admin’s filter by clicking the trash icon or by launching the above API with DELETE method. 


The application does not ensure that a user with only restricted settings is able to delete filters of other users or a filter of an admin.

Harbor Enables Privilege Escalation from Zero to Admin

Another example involves Harbor, a widely popular cloud native registry that stores, signs, and scans container images for vulnerabilities. The Broken Function Level Authorization vulnerability allows attackers to take over Harbor registries by sending a malicious API call. The API in discussion here is “/api/users”: by sending a POST request the API enables registration of the new users. To create a normal user, the API would look like below with sample payload:


POST /api/users HTTP/1.1



”realname”:”no name”,



However, the issue arises if the same API is called with the payload having an additional parameter “has_admin_role” and setting its value to ‘True’ which leads to a new user registered with admin privileges. 

POST /api/users HTTP/1.1



”realname”:”no name”,




Protection Mechanisms 

Any protection mechanism starts with a good API design for your business logic. Consider what needs to be protected and implement logical separation of functionality while designing the API paths and exposing various resources. Assess your API specification for any deviations from standard RESTful practices.


Choose an appropriate authentication and authorization module which will cater to all of your business needs. These modules should deny all access by default, requiring explicit grants to specific roles for access to every function. OAuth 2.0 has a great mechanism that limits an application’s access to a user’s account. An application can request one or more scopes. This information is then presented to the user and, upon his consent, the access token is issued to the application limited to the scopes granted.


We recommend using security products which report anomalous behavior that involve multiple complex machine learning models. As an example, a user created with non-admin privileges performing admin activities immediately can be caught if the model tracks for user creation APIs with different roles.


Vulnerabilities of this type can also be found by focusing on API testing during the development process. In this case, test cases should be developed with a focus on the  business logic.


If you would like to understand how CloudVector can help protect against OWASP API Top 10, please feel free to reach out at

Sekhar Chintaginjala is an experienced information security researcher who brings 15+ years of hands-on knowledge to the CloudVector team. He has proven expertise in the area of vulnerability research, security content development and leading teams for large global companies. At CloudVector, Sekhar is a member of the Security Research team and also leads efforts for new feature development that help protect from API abuses.