OWASP API Security Top 10: Upcoming Changes You Need To Know About

Since 2019, OWASP has published the OWASP API Security Top 10. This list of top 10 risks is used to help organizations identify, assess, and remediate security issues in their web APIs. Recently, they announced the first release candidate for the updated 2023 list, which is now available for review.

In this article, I would like to share with you the coming changes and discuss some steps you can take to ensure your API hacking methodology takes these into consideration. I will include links to the newest changes (at the time of this writing), so you can review the changes for yourself.

Let’s get right to it!

A Quick Review Of The Changes

I think a simple table is the best way to review the top 10 list changes quickly. Check this out:

	2019	2023
API01	Broken Object Level Authorization	Broken Object Level Authorization
API02	Broken User Authentication	Broken Authentication
API03	Excessive Data Exposure	Broken Object Property Level Authorization
API04	Lack of Resources & Rate Limiting	Unrestricted Resource Consumption
API05	Broken Function Level Authorization	Broken Function Level Authorization
API06	Mass Assignment	Server Side Request Forgery
API07	Security Misconfiguration	Security Misconfiguration
API08	Injection	Lack of Protection from Automated Threats
API09	Improper Assets Management	Improper Inventory Management
API10	Insufficient Logging & Monitoring	Unsafe Consumption of APIs

As you can see, while a lot has stayed the same, a lot has changed. Things like logging & monitoring have dropped off, but SSRF and unsafe consumption of APIs are being added. It’s pretty interesting to check out the commits on GitHub and see the comments on thinking and motivations around the changes.

But I digress. Let’s dig into the new top 10 in more detail, one by one, and discuss how this might impact your API security testing.

API01: Broken Object Level Authorization

The most significant risk, and still number one, is broken object level authorization (BOLA). This simply means that authorization checks still plague APIs today.

The main takeaway is that you should ensure your application has proper authentication, authorization, and session management in place. Also, you’ll need to test for any potential vulnerabilities that can bypass these checks (such as access control flaws).

API02: Broken Authentication

Notice how the word “User” is being dropped from the title in the latest edits for Broken Authentication? While the second highest risk is still focused on authentication, it is no longer just about the user. It now includes a discussion about microservices and the fact that machine and service principals may just as easily be in the mix with APIs.

The main takeaway is that proper authentication and authorization are vital in protecting an API like the first item on the list. It’s important to test the logic and look for ways to abuse or bypass it.

API03: Broken Object Property Level Authorization

This is the first really interesting change to the new list. The threat being covered is how attackers can exploit API endpoints that are vulnerable to authorization issues by reading or changing values of object properties that they are not supposed to access.

Sound familiar? It’s basically combining the old top 10 list items for Excess Data Exposure and Mass Assignment together into a single item. And that makes sense. Excess Data Exposure was really about exposing properties in a read operation, while Mass Assignment was about changing properties in a write operation.

Both were referencing broken authorization issues on object properties. So now Broken Object Property Level Authorization has become a thing. Let’s start calling it BOPLA going forward.

I like this move. As more and more developer frameworks (de)serialize objects blindly, there are many interesting ways we can taint and extract data properties in ways the developer did not intend. This is ripe for abusing logic flaws and weaker access control.

So your tests for Excess Data Exposure and Mass Assignment are still valid. You will just move the test cases into the workflow for BOPLA testing.

API04: Unrestricted Resource Consumption

So this item is interesting. The title was changed from “Lack of Resources & Rate Limiting” to “Unrestricted Resource Consumption.”

The guidance is still referencing that threat actors can abuse API endpoints due to a lack of rate limiting. But now it also includes verbiage around the fact that due to the lack of monitoring, or improper monitoring, malicious activity passes unnoticed. With Insufficient Logging & Monitoring being removed from the new list (more on that later), it’s starting to be called out elsewhere.

Another interesting change is the inclusion of GraphQL batch transactions, which allows OWASP to highlight how a number of operations can be performed in a single API client request through the newer approach to queries, significantly abusing potential resource usage. 

API05: Broken Function Level Authorization

So BFLA continues to be in the middle of the list. Not much has changed other than OWASP calling out that detection relies on proper logging and monitoring.

I think that is a common theme among the items on the new list. Logging and monitoring are an important part of pretty much everything in an API. When it’s missing, you just don’t know what is going on. And that includes authorization issues at the function level.

API06: Server Side Request Forgery

I wasn’t surprised when I saw that Server Side Request Forgery (SSRF) was added to the newly updated API Security Top 10 list. SSRF is one of the more fun vulnerabilities to find in an API.

Last year when I wrote about doing out-of-band application security testing (OAST) with Burp Collaborator several of you reached out to thank me for discussing using OAST for SSRF, as you were dealing with this sort of issue when testing some of your own APIs.

So it’s apparent that other API hackers are detecting SSRF issues in their testing. Seems like a nice and timely addition to the list.

API07: Security Misconfiguration

Not surprisingly, Security Misconfiguration is still on the list and in the 7th spot. Little has changed in the guidance for this item other than explaining that an API might be vulnerable if there are discrepancies in how servers process incoming requests in the HTTP server chain.

This is the first time we see the idea of API gateways and WAFs being thought about when discussing security misconfiguration. We’ve known it’s important for a long time; it’s finally started to get called out, albeit indirectly.

API08: Lack of Protection from Automated Threats

So this new item surprised me when I first heard it was being added. Mostly because it replaces the old Injection category. But when you think about it, Lack of Protection from Automated Threats is more common than we would like to admit.

I’m told Taylor Swift fans can attest to that when TicketMaster’s APIs were abused and ultimately fell down, and then other resale sites ended up raking in the dough.

In essence, this new category focuses on calling out that an API endpoint is vulnerable if it exposes business-sensitive functionality and allows an attacker to harm the business by accessing it in an excessively automated manner.

Time to build out those advanced cluster bomb Intruder payloads in BurpSuite and see what you can do in your test plan!

API09: Improper Inventory Management

Notice how API09 changed the word “Assets” to “Inventory.” It aligns more with how we typically think of versioned endpoints.

There was some explanation refactoring that went into discussing this class of vulnerability. An introduction to documentation and data blindspots for APIs clarifies how to detect if an API is vulnerable, which is good to see.

API10: Unsafe Consumption of APIs

Last but certainly not least was a huge change for the tenth spot in the OWASP API Security Top 10 list.

Insufficient Logging & Monitoring is being replaced with Unsafe Consumption of APIs. This is an interesting choice.

The new category is focused on the fact that developers tend to trust data received from third-party APIs more than user input. Because of this, they tend to adopt weaker security standards, for instance, regarding input validation and sanitization.

This really is about delegated and blind trust in data coming from external systems. If an attacker can breach the third-party service, they could pollute the API that consumes it.

Conclusion

It’s exciting to see the OWASP API Security Top 10 project progress. It’s a good reminder that APIs can be just as vulnerable as web applications, so remember them when you are doing your security testing.

These new changes will make it easier for developers and testers alike to identify issues that should be addressed in their API security strategies. Hopefully, this will result in fewer security breaches and more secure APIs!

For more details on these changes and other news, be sure to check out the official project page here.

Like keeping up with what is going on in the API hacking world? Make sure you download my free ebook on the Ultimate Guide to API Hacking Resources, and automatically get added to the API Hacker’s Inner Circle newsletter.

The post OWASP API Security Top 10: Upcoming Changes You Need To Know About appeared first on Dana Epp's Blog.

*** This is a Security Bloggers Network syndicated blog from Dana Epp's Blog authored by Dana Epp. Read the original post at: https://danaepp.com/owasp-api-security-top-10-upcoming-changes-you-need-to-know-about