What Is Broken Object Level Authorization?

Broken object level authorization is among the OWASP top 10 API risks. In this blog, you'll learn 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?

Broken object level authorization is a security vulnerability that occurs when an application does not correctly confirm that the user making the request has the required privileges. This is a common error, as APIs expose endpoints that handle object identifiers. 

This creates a wide attack surface level access C=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. This vulnerability is also called broken object level access control. 

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 from requesting 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.

Mitigate Security Risks Like BOLA

Watch the webinar below to learn how to mitigate security and compliance risks.

How to Prevent Broken Object Level Authorization

So, how do you prevent broken object level authorization? Here are the basic steps. 

1. Ensure That Only Authorized Users Get Access

The most important step is to ensure that a particular user is entitled to access a specific resource. This should ultimately be validated in the business or data access tier.

Of course, there's a lot more to it than that. Reaching this conclusion may involve significant business logic.

For starters, resource entitlements will typically already be enforced in the client application. This ensures that only authenticated and authorized clients can access a particular API. And this 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.

2. Configure the API Product Properly

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. 

3. Strengthen Security With Encryption

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).

Prevent Broken Object Level Authorization With Akana

The best way to prevent broken object level authorization is to choose the right API platform, like Akana. 

In fact, Akana comes with out-of-the-box security policies that can be applied to your APIs to mitigate the BOLA vulnerability, including:

• 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).
• Malicious Pattern Detection Policy (to ensure a message does not contain malicious content, e.g. JavaScript or SQL injection — even though the sender is deemed benign).
• JOSE Security Policy (to validate JSON Web Token signature, encryption).

Get Started with Akana

Find out how easy it is to strengthen security and accelerate time-to-market with the Akana API management platform. 

Try akana ▶️ WATCH A DEMO FIRST

👉 Become an Expert

Explore additional resources:

• API Basics
• API Security Best Practices