As the pioneer in API security, Salt Security worked closely with the Open Web Application Security Project (OWASP) to help identify, define, and educate the security community about API security threats. In fact, Salt was a key contributor to the original OWASP API Security Top 10 list, released in 2019.

The OWASP API Security Top 10 list has had a tremendous impact on the industry, increasing awareness and educating organizations on the fastest-growing API security threats. Given the significance of this list, Salt has been actively involved in the foundation’s updated 2023 mapping. We are thrilled to see the publication of the initial release candidate, which can be viewed here.

Below is my quick take on the new list and updates:

• API1:2023 – Broken Object Level Authorization (BOLA)

Not surprisingly, BOLA retains first place for API attacks in the OWASP API Security mapping. APIs’ complex and diverse authorization mechanisms make it difficult to oversee every authorization issue and oversee each object’s access for authorization. But failure to enforce authorization at the object level can lead to data exfiltration and account takeover (ATO). Researchers recently uncovered several BOLA vulnerabilities affecting multiple automotive manufacturers, including the potential takeover of Ferrari owners’ online accounts.

• API2:2023 – Broken Authentication

Broken authentication remains the second highest ranked attack vector. With many ways to perform authentication and the sensitivity of the authentication flow, any minor issue can impact security, opening up the door for attackers to gain unauthorized access to applications.

Improper social login functionality in Booking.com (now remediated) provides an example of this vulnerability, which could have led to potential ATO attacks.

• API3: 2023 – Broken Object Property Level Authorization

API3, a new category, combines two 2019 categories: “Excessive Data Exposure” and “Mass Assignment.” Despite the ability for a specific API to enforce object-level authorization security measures, they may not be sufficient. Often, authorization needs to be even more granular and include the objects and their properties. A recent incident reported by Twitter showcases this risk, where attackers could have enumerated Twitter users by providing their email addresses or phone numbers and examining the returned error response. 

• API4:2023 Unrestricted Resource Consumption

This category remains the same overall. Consumption of resources can quickly lead to many flavors of DoS scenarios, whether the server is processing huge files (thus consuming its CPU resources), excessive traffic (which consumes networking resources), or any other type of resource consumption. Executing this type of an attack can be as easy as simply uploading a big file to a file upload endpoint. A successful attack can very quickly lead to a DoS situation, such as DDoS attacks targeting APIs. One recent example shows how Poland’s key tax portal was rendered unavailable to Polish citizens.

• API5:2023 Broken Function Level Authorization

At number five, this category remains one of the most popular attack methods for APIs. When authorization is not properly implemented, unauthorized users can execute API functions such as adding, updating, or deleting a customer record or a user role. The cause could stem from a lack of proper API documentation, as well as fast development cycles using CI/CD and similar methodologies. A 2022 Reddit vulnerability provides an example, where users could bypass all ad content restrictions using a “hidden” PATCH endpoint allowing ad approval without Reddit consent.

API6:2023 Server-Side Request Forgery (SSRF)

Server Side Request Forgery (“SSRF”) represents a new and much-needed category. 

SSRF happens when a user-controlled URL is passed over an API and honored and processed by the back-end server. If the back-end server attempts to connect to the user-supplied URL, the door for SSRF is immediately open. SSRFs can come in many different types and flavors. Recent research published by Salt Labs highlights the risks embedded within SSRF attacks, showing how researchers could gain access to the internal network resources of a giant Lego-owned website.

API7:2023 Security Misconfigurations

This category remains as the seventh most popular API attack vector. A wide range of security misconfigurations can negatively impact API security. APIs are often designed on top of the underlying infrastructure. One mistake in configuration could compromise the entire API and all its endpoints. A recent vulnerability found by the Wiz security research team shows the severity of these security issues. 

API8:2023 Lack of Protection from Automated Threats

This new category focuses on a prevalent type of API attack that mainly addresses scenarios in which business logic flows are abused to allow malicious behavior. Detecting these attacks can happen only by looking at the overall user/request flows – inspecting each request individually will never reveal the attack, so detection is quite challenging. Recently published research shows how researchers could abuse URL shortener services and their business logic by performing an automated attack. 

API9:2023 Improper Inventory Management

Common attack scenarios related to this category include scenarios in which an attacker can find a “weak” endpoint or API and abuse it. Examples of weak endpoints include testing or development APIs that are mistakenly exposed to the public and might not include all the security measures incorporated into the production APIs. The Optus breach is a perfect example, in which Optus, the second largest telecom company in Australia, exposed more than 11.2 million customer records with dozens of PIIs due to a “forgotten” API exposed to the public.

API10:2023 Unsafe Consumption of APIs

The new unsafe consumption category contains a mix of two common API issues. One of these issues is addressing the consumption of API data itself, a large part which was included in the OWASP API8 2019 (Injection) section.

The 2023 category broadens this type of attack to include attacks that are not explicitly injection-related, such as de-serialization issues, some flavors of de-sync attacks, and so on. The shared root cause for all these attacks is that the back-end service is too permissive when accepting user-controlled input carried over APIs and sometimes even blindly uses them without applying any proper validations. The most relevant example for this category would be the notorious Log4Shell attack. 

The second issue deals with another attack that abuses a weak link in almost every modern system design – integration. Integrations could include any third-party service or functionality embedded into the API implementation or in their supporting back-end services. API-based supply-chain attacks serve as a good example of this category's danger.