Beyond the Basics: A Deep Dive into OWASP API Security Top 10’s Necessary Overhaul

Application Programming Interfaces (APIs) are integral to our digital ecosystem, acting as the glue that connects applications and services on our mobile phones, cars, and internet-enabled devices. They act as the gateway to these processes and systems, and it’s this access that makes them so attractive to cybercriminals. But how APIs function also makes them fairly unique when it comes to security.

Unlike applications a human typically accesses, APIs are made for machine-to-machine communication and respond to API calls to exchange data. It’s this call pattern that attackers look to exploit, and unless the API is monitored using behaviour analytics the chances are the attack will go undetected. This is because most solutions, such as Web Application Firewalls (WAFs), look for signature-based attacks or monitor for spikes in network traffic typically associated with automated attacks rather than focusing on the API per se.

API security is among the most unique types of security, leading to the creation of the OWASP API Security Project and the subsequent release of the OWASP API Security Top 10 in 2019. It’s since become the go-to resource for those tasked with developing and maintaining API, from developers to security teams, as it outlines the most prevalent tactics, techniques, and procedures (TTPs) used by attackers. Earlier this year, the list was revised and updated because, as the Group acknowledges, a lot has changed in API security, with the sector having matured considerably over the past five years.

Attack patterns

Attackers have become much more adept at targeting APIs and are quick to pivot from one technique to another or combine attack types. We first noticed this last year when Trinity attacks emerged, which saw Broken User Authentication combined with Excessive Data Exposure and Improper Assets Management. Although a relatively small number (100 million) of attacks were registered to adopt this technique, it indicated a new level of sophistication.

This evolution in attacks, as well as some API protocols gaining more traction than others and changes in defence, has driven the need for the Top 10 to be updated. Utilising public data and the results from bug bounty programs, as well as input from API specialists including vendors such as us, the new version contains several significant changes. 

A seemingly new category, for example, Broken Object Property Level Authorisation (API1) (BOLA), combines two of the previous categories: Excessive Data Exposure and Mass Assignment. This change emphasises the importance of proper authorisation so that APIs are designed so that only authorised users can access or modify specific properties.

Another new addition is The Unrestricted Resource Consumption (API4). This highlights the importance of managing the resources required to satisfy API requests, an issue that is particularly relevant in cloud computing, where resources are billed per usage. Unrestricted resource consumption can lead to increased operational costs, with attackers effectively bankrupting victims, and can even result in Denial of Service (DoS) if not properly managed.

Abusing APIs

Business Logic Abuse has long been a prime attack method that sees the functionality of the API turned and used against it either excessively or in an automated manner. The Unrestricted Access to Sensitive Business Flows (API6) category directly addresses this issue and encourages the implementation of appropriate rate limiting and abuse prevention mechanisms to stop attack automation from being utilised against it.

Previously, API6 was classed as Mass Assignment, but both are talking about taking advantage of objects and their properties within the application flow. Examples given on the OWASP API Security Project page are for a ride-share app in both cases, which sees the exploitation of backend systems. But something subtle about the renaming makes the 2023 version seem like something that needs to be fixed rather than being nebulous and confusing. The name change effectively establishes a call to action and is a good call by the Project leaders. 

Another change is Improper Inventory Management (API9), highlighting the importance of maintaining a proper inventory of hosts and deployed API versions. As microservices architectures and API-first approaches become more prevalent, keeping track of all deployed APIs becomes a significant challenge. In most cases, organisations significantly underestimate the number of APIs they have deployed, leading to shadow APIs slipping beneath the security radar. So, this category helpfully emphasises the need for keeping track of APIs, their governance and lifecycle management.

Finally, the new Unsafe Consumption of APIs (API10) category highlights the risks associated with trusting data received from third-party APIs. Developers often inherently rely on third-party APIs, as they do internal APIs, leading to weaker security controls and exposing the business to supply chain attacks. This category encourages developers to treat third-party API data with the same level of scrutiny as user input.

What’s been omitted

However, it’s also telling which categories have been replaced. The OWASP API Security Project authors state that Injection, which was previously API8, has now been removed not because it isn’t a threat but because it is not unique to APIs. The new list aims to encapsulate security risks specific to APIs and build awareness around API security issues. Injection attacks or vulnerable and outdated components are still an issue, but such risks are generic and don’t behave differently in an API context.

Similarly, Excessive Data Exposure, API3, has been taken off the list. It’s been replaced with Broken Object Property Level Authorisation (API3) because this is the natural next step resulting from sensitive data exposure. But again, it isn’t a direct replacement because many items in the list involve sensitive data exposure; it’s simply a move away from too generic a term.

If we look at a typical attack pattern, the progress can effectively be mapped to the Top 10. Many breaches start with an API that the victim organisation is unaware of, which would be API9 in the new list. The API is then found to return some user data which would be API1 and the attacker then goes on to attack automation, using a bot to try to exploit this as fast as possible which comes under API6 and completes the attack chain.  

The new Top 10 is not a radical departure from the original version, but it moves the conversation on. It makes the TTPs much more API-specific and suggests an urgency that may have been previously lacking. There’s more emphasis on the importance of proper authorisation at both the object and function levels, managing resource consumption, protecting sensitive business flows, and maintaining a proper inventory. It also introduces the concept of unsafe consumption of third-party APIs, highlighting the risks of trusting data from external sources.

As dependency on APIs increases and sustained attacks escalate, the list will prove invaluable to all those involved in API development, management, and security. Does it create arbitrary distinctions between TTPs, and is a top 10 the best format to present this information in? That’s debatable. But it certainly raises the profile of these attacks and makes API security more accessible to the mainstream, and that has to be a good thing.