1: Broken object level authorisation
4: Lack of resources & rate limiting
5: Broken function level Authorization
10: Insufficient logging & monitoring
Broken function level authorization (BFLA) can be considered a higher level version of BOLA. This is because it’s focussed on general functions rather than individual objects. The consequence of BFLA is that clients can access functionality beyond their intended access level, such as administrative functions.
To prevent BFLA, client requests must be authorised correctly. This involves validating client permissions against the resources it’s requested. Requests from clients with insufficient permissions must be rejected.
OWASP summary
| Threat agents/attack vectors | Security weakness | Impacts |
| API specific : Exploitability 3 | Prevalence 2 : Detectability 1 | Technical 2 : Business specific |
| Exploitation requires the attacker to send legitimate API calls to the API endpoint that they should not have access to. These endpoints might be exposed to anonymous users or regular, non-privileged users. It’s easier to discover these flaws in APIs since APIs are more structured, and the way to access certain functions is more predictable (e.g., replacing the HTTP method from GET to PUT, or changing the “users” string in the URL to “admins”). | Authorization checks for a function or resource are usually managed via configuration, and sometimes at the code level. Implementing proper checks can be a confusing task, since modern applications can contain many types of roles or groups and complex user hierarchy (e.g., sub-users, users with more than one role). | Such flaws allow attackers to access unauthorized functionality. Administrative functions are key targets for this type of attack. |
Source: OWASP broken function level authorization
APIM context
BFLA falls well within the remit of APIM. As such, it’s common for APIM systems to offer various methods for managing access to HTTP methods and paths. This is often covered through the concept of access control lists, sometimes referred to as policies, which define access rights to APIs and the resources contained within them. These policies can often be bundled together, functioning as a form of role-based access control.
API gateways can make authorisation decisions based on a client’s access rights and the resource they requested. For example, if a client is granted only HTTP GETaccess to an endpoint, any DELETE requests they send will be rejected by the Gateway. Furthermore, the Gateway should provide the client with a reason for the rejection by returning an HTTP 401 Unauthorized status code in the response.
In order to effectively guard against BFLA, API owners must invest sufficient time and planning into the design and application of their security policies. Only once the correct policies are in place and allocated correctly will an API Gateway be able to mitigate the threat of BFLA. This is a continual process, which needs to operate in tandem with the API development cycle – when API endpoints change, so must the policies which protect them.
Tyk approach
Tyk has several areas that can assist with BFLA:
- Policies: Policies are predefined sets of rules which grant access to particular APIs. These can include path-based permissions, which restrict access to particular paths and methods within an API. Clients can be assigned one or more policies which the Gateway will validate when it receives a request.
- Access control plugins: Tyk has plugins that control access to API endpoints. They are known as whitelist and blacklist, and can be configured via the endpoint designer of an API definition. Both plugins grant and deny access to API paths and methods, but do so in different ways, which makes them mutually exclusive. When the whitelist plugin is used, only the paths and methods marked as whitelist are allowed, all other paths and methods are blocked. The reverse is true for the blacklist plugin, only the paths and methods marked as blacklist are blocked, all other paths and methods are allowed.
