Broken Function Level Authorization
Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers gain access to other users’ resources and/or administrative functions.
– OWASP API Security Top 10 2019 Report
What does this mean?
A broken function-level authorization essentially refers to a permission IDOR, whereby a regular user can carry out an administrator-level task. The broken function-level authorization refers to the user hierarchical permissions system being incomplete or broken. APIs that involve complex permissions and user roles that can span the hierarchy in different ways are more prone to having broken function-level authorizations.
What are the symptoms of this bug, and the potential impact?
This is particularly common with enterprise applications with a high number of different roles, with different permissions and access requirements. By using freely available tools, an attacker can perform this attack at scale. Automating the ability to successfully carry out an action that requires administrative privileges using a regular user’s account is evidence of a broken function-level authorization. Generally, if a user can access administrator-only endpoints or use sensitive functionalities (with a large impact) by simply changing the value of a method (e.g. HTML), then the API is vulnerable as its function-level authorizations are broken.
For example, while a teacher should be able to change the grade of a student, the student shouldn’t be able to, or while IT staff should be able to provision new accounts, a teacher and student should not.
How can an API be protected from broken function level authorizations?
OWASP strongly suggests having “a consistent and easy to analyze authorization module that is invoked from all your business functions. Frequently, such protection is provided by one or more components external to the application code.” In addition, the general access policy should be centered around having all users on an “access denied” baseline and granting authorizations to the relevant user accounts, as opposed to giving everyone access as a general rule and issuing an “access denied” status to a few users.