Submit support requests and browse self-service resources.
Olaf van Gorp
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.
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 BOLAWatch the webinar below to learn how to mitigate security and compliance risks.
Watch the webinar below to learn how to mitigate security and compliance risks.
So, how do you prevent broken object level authorization? Here are the basic steps.
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.
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 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:
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
Explore additional resources:
Technical Sales, Akana
Olaf has over 20 years’ experience with software development and architecture, helping organizations such as Compuware and Capgemini solve enterprise-level integration and governance issues. Olaf has supported the technical sales for Akana API management since 2014, diving deep into security challenges as well as issues specific to financial services, such as PSD2 and Open Banking.