Practical API Security with the OWASP Top Ten

API security is on everyone’s mind: after all, APIs always open up network-accessible interfaces that previously may not have been exposed. Making sure that this is not creating new risks means that securing APIs is an essential aspect of API management from the beginning.

NOTE: This blog refers to an earlier edition of the OWASP Top 10 API Security Risks. The latest update is covered in depth in this new blog, updated in 2024. 

In this episode of “Getting APIs to Work,” I speak with Isabelle Mauny, Field CTO and co-founder of 42Crunch, about the OWASP Top Ten and how grouping them into three general categories helps to better understand the security risks. We also discuss the Parler API breach, and how to improve the way organizations approach API security.

API security has always also been a technical issue, but it starts much earlier than when just “securing an API.” It needs to be part of the general API mindset and of how an organization manages APIs throughout its lifecycle.

API security problems can create a huge risk and be very costly, but there is still a constant stream of news about API-related security issues. Starting the API security journey by looking at typical problems is an educational exercise.

The Top Ten

In order to help with identifying common issues, the Open Web Application Security Project (OWASP) initiated the OWASP API Security Project, which created the API Security Top Ten. These top ten represent the most common security issues with APIs:

• API1:2019 Broken Object Level Authorization
• API2:2019 Broken User Authentication
• API3:2019 Excessive Data Exposure
• API4:2019 Lack of Resources & Rate Limiting
• API5:2019 Broken Function Level Authorization
• API6:2019 Mass Assignment
• API7:2019 Security Misconfiguration
• API8:2019 Injection
• API9:2019 Improper Asset Management
• API10:2019 Insufficient Logging & Monitoring

API designers and developers should have at least a brief look at the top ten to understand what typical mistakes look like. This will help them avoid these mistakes. But it can also help to have a little more structured look at the categories of mistakes that are typically being made.

Categorizing the Top Ten

Isabelle Mauny frequently talks about the top ten and via apisecurity.io provides an overview of all top ten issues.

To make the issues a little easier to understand, they can be grouped. Mauny suggests the following categories:

• Authentication and Authorization (API1, API2, API4, API5)
• Data Protection (API3, API6, API8)
• Governance and Operations (API7, API9, API10)

Most API security breaches have more than one category and issue associated with them.

“It’s always a combination of things,” explains Mauny. “For example, you have a problem with authorization, and you don’t have rate limiting, and you don’t have any logging. So not only do you have that authorization problem, but you aren’t slowing people down, and you don’t see anything happening.”

What we learn from the Parler API breach

The Parler API breach had six of the top ten issues (covering all three categories), generally showing that these breaches are often caused by a general lack of awareness of API security and the OWASP top ten issues specifically. And it is a great case study in how risky it is to not incorporate API security into your design from the start.

Authentication and Authorization

The first issue the social network stumbled on was authentication:

“They didn’t have any, so the first problem was that APIs for all public posts on that social network were just completely open,” explains Mauny. “And we’ve seen that before, and in many cases, it’s linked to the problem of governance of the API: we leave stuff open.”

She points to another case where an Indian company had opened an API for the sake of doing load testing. They decided to not put any authentication for ease of writing the test script that would involve the APIs, but they then forgot about it and left it down.

“There’s a key point here, which is a false sense of what is public,” adds Mauny.

“In people’s heads, public means ‘I’ve created a development portal, I created my API, and I made my API available to the public.’ And that is very different: what they’re describing is open, but it’s not really public. The minute you expose something on the internet, it is public, and that’s a very common misconception.”

The next problem with Parler was that there was very limited authorization.

Mauny says this explains how hackers were able to take so much data: due to the issue of Broken Object Level Authorization (BOLA, or also sometimes referred to as IDOR: Insecure Direct Object References).

Data Protection

Mauny shares an example to illustrate how the vulnerability comes about:

“Isabelle has an account at a bank. I can use an API to connect to the bank. And once I have valid token to access to that bank, I can access my account, which is account 123. It just so happens that Erik is at the same bank and has account 456. I should never be able to access your bank account 456 if I know that number,” says Mauny.

And that’s exactly what happened with Parler:

• Every post on the social network had a sequential ID. All hackers had to do was write an engine that iterates increments by one and scoop up the data.
• Then, there was no rate limiting, so they weren’t stopped in their tracks.
• Finally, no one saw it happen.

There should always be monitoring in an organization that alerts you to unusual activity, like high access volume or certain access patterns.

Governance and Operations

The third main problem was misconfiguration.

In the wake of the 2021 US Capitol attack, many people on the social network tried to delete any trace of information they had posted. They went to the user interface and deleted sensitive posts.

The posts were no longer visible on the UI, but there was still plenty happening behind the scenes: rather than actually deleting the data, the posts were merely being flagged as deleted and removed from the UI: all that information was still there.

Not only was this information there, it also contained a lot of information that should not be visible directly, such as the geolocation of where the person had posted from. Ultimately, the app was exposing too much information, which leads to another common pitfall:

In a non API-based style application, all this filtering and rendering of data was done server-side. Here, developers removed a lot of that logic by moving it to the client side. But it can be completely defeated by simply going around the client. Now, none of that logic is executed, and hackers have access to the raw information.

“When you start doing design and architecture based on APIs, you have to be careful about where those enforcements and controls actually happen, and make sure they happen all the time on the server side and not on the client side, where they can be circumvented,” says Mauny.

Managing API Security

Security starts much earlier than when “securing an API” is relatively late in the development process. It should be part of the API design (for example, making sure that problematic data is not even exposed in the API to begin with) and therefore must be part of the general mindset and the process of how APIs are designed and developed.

To that end, an “API First” approach can help implement better API security practices. By developing API contracts and discussing this early on in the design and development process, API security issues can be uncovered and addressed before they arise.

Treating security as an important aspect throughout the API lifecycle will help make sure that it’s not just an afterthought, and that security is part of the picture for every API from the very beginning.

To go into this conversation in more detail, watch the full video.