OWASP API1:2019 — What Is Broken Object Level Authorization and Why It’s Important

The number one biggest API security risk is broken object level authorization, according to OWASP. So, what is broken object level authorization and why is it such a big problem?

Why Is Object Level Authorization So Critical?

One of the wonderful, powerful benefits of APIs is that they allow lots of microservices to be exposed easily. This improves code quality and allows dev teams to build new functionality, troubleshoot issues, and improve application quality much quicker.

However, as APIs moved from being available to internal users only; to internal and external users; to directly by customers and customer applications, there was a huge expansion in what an individual user should be able to do, and what they should be blocked from accomplishing. This only makes sense. If you only have one small team of internal developer users, it may be just fine to allow them to access detailed information in API calls, including financial and transactional information about all users.

Of course, as APIs are used by external parties and applications, we must enforce strict authorization so that a customer can only see their own data. It would be really bad if one customer could see another customer’s purchase history or financial transactions. What would be even worse, though, is if an external party could see the data of all customers by calling the API, one customer ID at a time.

That’s exactly what happens with object level authorization is broken. First, an external user logs in with their own, valid credentials. Next, they replace their own user ID with another user ID. And finally, they call the service to retrieve data about that second user ID. Of course, attackers won’t stop with just one replacement ID, they will continue to swap IDs and call additional records, exfiltrating loads of customer data along the way.

How to Enforce Object Level Authorization

API calls must be configured to check permissions every time they run. That way, the API will double check who is calling it; what information the caller is requesting; and then can make a decision about whether the requested payload should be delivered.

But often, API developers simply skip this step. It can happen for a lot of reasons, but the most common cases are that an internal API is converted to internal and external, without additional security configurations applied; or when a developer updates an API to add some new functionality (e.g. improved resiliency or new functions), they inadvertently introduce a regression that removes the authorization check.

Another tactic to make data exfiltration more difficult for bad actors is to make sure that your IDs are not automatically sequenced when they are generated. If my user ID is 123456, and the next user’s ID is 123457, then it’s easy to run a script that automatically increments each data call, which can result in lots of data being stolen very quickly.

Lots of Data Breaches Come From Broken Authorization

In May 2021, security researchers announced that Peloton’s API had a massive security breach, caused by this very issue. Once a regular Peloton customer logged in, they could replace their user ID with another user ID, and download a surprisingly large volume of data about other users, including the user’s age, gender, weight, location, workout statistics, and if it was the user’s birthday.

Once a bad actor knows this much detail about a Peloton user, it becomes easy for them to spoof Peloton to steal financial data through email or even on the phone. In addition, this could be considered a breach of personal health information, which carries separate fines for Peloton.

Other common risks with this type of breach include directly accessing customers’ financial information or PII like their name and email address.

How to Monitor for Broken Object Level Authorization

The typical path to test for this vulnerability is to build a series of QA tests, to ensure that there is authorization enforcement on every API call. This approach is very cumbersome and slows down development dramatically, which is why it is often not done effectively.

A better approach is to run a check and validation against an authorization checker, which can dynamically probe to ensure that authorizations are checked on every call, and raise an alert if there is an issue.

Not every developer has the bandwidth to be a security and privacy expert, which is why many teams use tools to help them validate new commits.

Originally published at bycontxt.com on Oct 7, 2022.