API1:2023 Broken Object Level Authorization


Welcome to the 2nd post in our weekly series on the new 2023 OWASP API Security Top-10 list, with a particular focus on security practitioners. This post will focus on API1:2023 Broken Object Level Authorization.

In this series we are taking an in-depth look at each category – the details, the impact and what you can do about it. To see previous posts you might have missed, click here.

TL;DR

The application behind the API fails to validate permissions for every call to every object. The attacker manipulates the object in the API call to gain access to data or functionality they shouldn’t have. 

The Details

To understand Broken Object Level Authorization (BOLA), you need to start with the concepts of authentication and authorization. Simply put, authentication is about confirming identity and authorization is about permissions for that confirmed identity to do something specific. When I log into an application, it’s authenticating me. When I try to do something in that application, it’s authorizing the identity with which I authenticated to do that thing. 

As we’re talking about APIs specifically, the concepts remain the same, but the details change a little. Authentication generally takes place at the beginning of a session and is persisted for that session. Once authenticated, the application should validate that the authenticated user has permission to carry out an operation each time the request to do so. In other words, the application should perform authorization at the object level. 

If the application doesn’t do so, then the authenticated user may be able to access objects they shouldn’t. In most cases, this is accomplished by manipulating the object included in the API call. For example, an API call to change a password may reference a user object by an ID. If changing that ID to another user results in a successful password change for that user, then the application is vulnerable to BOLA. 

What’s the Impact?

Obviously, attackers can use BOLA vulnerabilities to access data that should be restricted. They can also use them to execute an account takeover or elevate permissions. In reality, the impact is as variable as the capabilities of the application itself. If it’s a banking application, then there are obvious potential financial impacts. If the application stores sensitive information, then compromise of that information is possible.

What Can You Do About It?

Addressing BOLA ultimately requires changes to the application itself to adequately enforce object level authorization. In order to do so, however, you have to identify the issue first. Detection of BOLA vulnerabilities, both in development and in production, is the first step in mitigating the risk. Changing code and redeploying applications takes time, and comes with some risk as well. For cases where you either can’t fix the BOLA issues or where you can’t fix them right away, it’s important to have an inline API security tool that can identify and block BOLA attacks. 

How Wallarm Can Help

Wallarm offers BOLA protection as part of our Advanced API Security subscription. When enabled, Wallarm will identify API endpoints that are vulnerable to BOLA and actively protect them automatically. Additionally, the Wallarm platform allows users to create custom triggers to respond to BOLA attacks with specific actions or notifications beyond simply blocking the attack. 

Learn More

Come back next week as we dig into the details of another category of the new 2023 OWASP Top-10 API Security Risks list – or click here to see previous posts you might have missed.

In the meantime, here are some other resources which might help on your journey to end-to-end API security:

Protect Your APIs from OWASP API Security Top-10 Threats

Wallarm End-to-End API Security solution provides comprehensive protection against the OWASP API Security Top-10 threats. And in 2023, we’ve made it even easier for you!

The Wallarm 2023 OWASP API Security Top-10 Dashboard provides you with complete visibility into the security state of your APIs, easy identification of your most critical security risks, and ability to immediately apply protective measures.

API1:2023 Broken Object Level Authorization 1

If you are interested in learning more about how we can help you protect your APIs, please schedule a demo with one of our security experts today!



Source link