OWASP Top 10 API Security Risks | 2023 Edition is finally here!

OWASP Top 10 API Security Risks | 2023 Edition is finally here!

Find out what is new and what has changed compared to the 2019 Edition in this blog post.

Today is the official release of the OWASP Top 10 API Security Risks | 2023 Edition and I am excited to see OWASP continue to create awareness around API security and the risks they are facing. I am proud to contribute to the new list with my insights into API security.

With billions of humans interacting online, interfacing directly with APIs and relaying their (privacy) data through APIs, it has become a necessity to protect API endpoints with the same level of protection, developers are giving our network, infrastructure and data.

For instance, I recently worked with a streaming service who were inadvertently giving away its services for free .... more on that later.

So what has changed in the 2023 edition compared to the 2019 edition?

Both lists still have an important top 10 security risks to look out for when developing and managing API endpoints but efforts have been made to combine and tighten up both lists.

Directly quoting the release notes of 2023: "The OWASP API Security Top 10 2023 is a forward-looking awareness document for a fast pace industry. It does not replace other TOP 10s. In this edition:

  • We've combined Excessive Data Exposure and Mass Assignment focusing on the common root cause: object property level authorization validation failures.

  • We've put more emphasis on resource consumption, over-focusing on the pace they are exhausted.

  • We've created a new category "Unrestricted Access to Sensitive Business Flows" to address new threats, including most of those that can be mitigated using rate limiting.

  • We added "Unsafe Consumption of APIs" to address something we've started seeing: attackers have started looking for a target's integrated services to compromise those, instead of hitting the APIs of their target directly. This is the right time to start creating awareness about this increasing risk."

I think these changes are definitely for the better and allow for more focus on the ongoing threats that we are seeing as an industry on API attacks.

Broken Object Property Level Authorization (BOPLA)

The newly minted third category: API3:2023: Broken Object Property Level Authorization combines the Excessive Data Exposure and Mass Assignment from the 2019 lists and aims to make developers more aware of exactly what is described on the label, broken object property level authorization.

API endpoints make use of API objects and each API object has API properties attached to them. In a simplified banking API example, my account with my bank is treated as an API object and the properties are my name, my account ID but also my balance.

Broken Object Property Level Authorization (or BOPLA) aims to make developers aware that we give the right authorization/access control to each of these properties.

If the API allows me to change my account properties in a web application that makes an underlying PUT request to change for instance my name or my telephone number, it should be explicitly specified that only those properties can be changed.

Attackers will be looking at ways to replicate this PUT request and try to change other properties such as account balance. Being able to easily add $1mn to my account is of course a tremendously oversimplified example but should get the message across on the risks and why this category is the third category on the list!

Of course, the 2019 categories of Excessive Data Exposure and Mass Assignment are still relevant in 2023 as well. Reduce the number of API properties shared with users (or attackers) through GET/PUT/POST responses and ensure that properties have proper policies in place to which can be modified, when and by whom.

Unrestricted Resource Consumption

In response to API4:2023 Unrestricted Resource Consumption, API endpoints these days simply need to be available but just being available isn't everything. Implementing API gateway or load balancing controls is a good step in the right direction. But in recent years, we are seeing a huge shift in the 'economics of API usage'. Third-party providers such as Twitter or Reddit have started charging API usage to their developers and unrestricted resource consumption could lead to several financial complications.

API attackers could create unwanted API requests that consume these resources. For instance, in the airline industry, flight availability searches could trigger back-end or third-party systems that charge per lookup. Reducing the number of lookups in the front-end web application is only one layer of defense, but not limiting the API requests through proper authorization controls could lead to overconsumption and higher bills.

Unrestricted Access to Sensitive Business Flows

And to round it all out, this leads us to API6:2023 Unrestricted Access to Sensitive Business Flows, the most interesting new addition as it looks at more than just the technology of APIs. This category has finally written down what makes security so special; to think more like an attacker and see where potential gains can be.

The technology (the API) is just a way to execute the business logic and having ways of bypassing or altering this business logic through the technology is unwanted and could lead to situations.

I encourage you to take a look at the examples OWASP shared and think about your own business logic and how it can be prevented.

I had a conversation recently with API developers at a streaming service. This streaming service offered a free 30-day trial with sharing credit card information for new users to attract a new audience. However, the business logic was only looking at 'unique' email addresses for new sign-ups. A new email address could easily start a new trial using the same credit card information. This could lead to inevitably having users, creating a new account each month and continuing to use a service indefinitely for free. Gmail's + trick makes it even easier to exploit this.

More resources and a thank you!

There is more to be said about the OWASP API Security Top 10 | 2023 Edition and especially if this is your first time reading any of the OWASP API Top 10 lists, I encourage you to read through both if you are developing or managing APIs.

The new 2023 edition also comes with great advice for 'What's next for Developers' or 'What's next for DevOps'. There are tons of great resources for further education out there including the very helpful 'completely ridiculous API', an API that is broken on purpose to learn about these API risks in better detail.

I would be remiss in not sharing my free video series 'Fundamentals of API Security' I created which combines all the knowledge I have gained on API security in the last 5 years and aims at making API security more understandable and approachable. This video series is a great companion piece for the 2023 edition.

To round out this post, I wanted to congratulate OWASP and specifically those heading up the API Security Top 10 project, Erez Yallon, Inon Shkedy and Paulo Silva for all their great work on the 2023 edition. I also want to thank the other contributors and reviewers that made this list a reality.

acknowledgements

It is cool to see my name up there!

If there is anything I can do to help you with protecting your APIs, I am here to help! Feel free to reach out to me in the comments below or find me on LinkedIn or YouTube.