Broken Object Level Authorization
Continuing our series examining the OWASP Top 10 API Risks, in this blog post we will dig into Broken Object Level Authorization – what it is, how to prevent, and how the Akana platform provides an out-of-the-box solution to address this vulnerability.
What is Broken Object Level Authorization?
APIs expose endpoints that handle object identifiers, which creates a wide attack surface Level Access Control issue. By manipulating the ID of an object that is sent within a request, attackers can exploit API endpoints that are vulnerable to broken object level authorization.
Also called Broken Object Level Access Control, this risk is put on the top of the recent API Security Top 10 vulnerabilities - and rightfully so. In many cases, APIs provide rather direct access to specific resources, the REST protocol offering convenient ways to do so - in fact, it is essentially what REST is all about. Unfortunately, this approach does not prevent users to request for access to resources that they are not entitled to. This is not necessarily the result of a conscious action with malign intent; it could even be the result of a typo in the URL.
How to Prevent Broken Object Level Authorization
Regardless, from an API security perspective we should always seek to avoid any user gaining access to data or functionality for which (s)he has not been granted explicit permission.
Obviously, the conclusion as to whether a particular user is entitled to access a specific resource should ultimately be validated in the business or data access tier. Reaching this conclusion may involve significant business logic. Obviously, that does not mean that additional steps to secure access should not be taken earlier in the process. For starters, resource entitlements will typically already be enforced in the client application. To ensure that only authenticated and authorized clients can access a particular API already closes the door to a significant extent. In other words, the API resource will only be accessible when a valid token is presented by the client. When this token is associated with a scope, like in the case of OAuth2.0, resource authorization is more fine-grained.
Some actions can be taken at the level of the (published) API interface. For example, the API Product can be configured so as not to expose any ‘vulnerable’ parameters at all; for example, all input is given through the request payload (and only translated to a request that explicitly identifies the resource in the API Gateway - this assumes the downstream resource endpoint is not publicly accessible / only accessible through the Gateway.
The payload itself can be subject to rigorous security, in particular by means of signing and encryption. When this is done using official certificates, the message can be deemed authentic when valid (signature valid, etc.) as long as the certificate is not compromised. For example, the message can be secured through the use of JWS/JWE (which represents Financial API-level security).
Again, the final check on entitlement should be made in the business/ data access tier. Nevertheless, it may be clear from the above that measures can be taken at the level of the API Gateway, that will not close the door entirely but will already considerable narrow the gap (or: the window for malicious attack).
The Akana Solution
Below is a list of some of the most applicable security policies that are available out-of-the-box with Akana, that can be applied to your APIs to mitigate the BOLA vulnerability:
- HTTP Security Policy (for example, validating a client certificate)
- OAuth Policy (validate OAuth2.0 access tokens, preferably in JWS/JWE format)
- Application Security Policy (for clients that do not yet support OAuth, for example; authorization is ensured through encrypted Authorization header)
- JOSE Security Policy (to validate JSON Web Token signature, encryption)
Find out how easy it is to create, secure, publish, and manage APIs with the Akana API management platform. Start your free 30-day trial today.