Top Changes in the OWASP API Security Top 10 2023RC
The OWASP API project has recently decided to refresh the popular API Security Top 10 threat map. The team at Salt Security has always been actively involved in this project, having been a key contributor to the initial creation of the list. And we continue to be deeply involved in the thinking process, data gathering, and brainstorming in updating it.
As of the writing of this post, the final version of API Security Top 10 2023 has not been officially released. However, an initial release candidate has already been published. In this post, we wanted to share some of the motivations behind this new API Security Top 10 mapping and share our perspective as well as some data we can provide to support these decisions.
We encourage the entire security community to explore the new release candidate further – this is your opportunity to share your thoughts, comments, and even objections to the project.
OWASP API Security Top 10 2023 — What Did Not Change
API1:2023 Broken Object Level Authorization (BOLA)
The BOLA attack vector has kept its respectable first place in the mapping, and rightfully so.
BOLA attacks remained the go-to attack vector when it came to API attacks.
The main reason BOLA remains at the highest rank is the complex and diverse authorization mechanisms (or lack thereof) across all forms of APIs. While some API frameworks allow better control of authorization, others do not. In a blazing-fast development environment, it becomes very difficult to oversee every authorization issue and inspect each object's access to ensure only its allowed users can access it.
On the other hand, since authorization is in the very heart of every system, a failure in authorization can have a devastating impact when implemented incorrectly, as we can see in this recent example where researchers found several BOLA vulnerabilities in online services provided by various automotive manufacturers. In this example, attackers could have used a BOLA vulnerability to take over any Ferrari owner's online account and perform any actions on his or her behalf.
API2:2023 Broken Authentication
Immediately following BOLA and authorization issues come authentication issues, which have kept their place as the number 2 ranked attack vector.
In authentication cases — as opposed to authorization cases — many more standard (and less standard) options exist to perform the function. Due to the sensitivity of the authentication flow, any minor issue in this process might have severe impacts in terms of security, and each authentication method introduces its own set of possible issues, making their protection a very complex task.
One such example can be seen in recent research published by Salt Labs, in which an improper social login functionality in booking.com led to the potential for account takeover attacks to any of the site’s millions of users.
API4:2023 Unrestricted Resource Consumption
While the category name might have changed a bit, as did some of the descriptions, this category remains the same overall.
Resources are the heart and soul of any API, without which an API will remain just an empty shell. And while you can't live without resources, living with them poses a security risk. 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.
The popularity of these attacks is mainly derived from the fact that executing such an attack is often quite simple — sometimes it could be as easy as simply uploading a big file to a file upload endpoint. On the other hand, a successful attack can very quickly lead to a DoS situation, which might be exactly the effect an attacker would like to achieve, whether as an attack on its own or to create a smoke screen for other types of attacks.
A very popular example of such attacks is DDoS attacks targeting APIs. These attacks are usually very noisy and so are brought to public attention regularly. One recent example shows how Poland’s key tax portal was rendered unavailable to Polish citizens due to an attack of this category.
API5:2023 Broken Function Level Authorization
This category remained at its 2019 ranking and is still one of the most popular attack methods for APIs.
The source of this issue can vary, and it can be the result of a lack of proper documentation for APIs (which is very common amongst all API practitioners) as well as fast development cycles using CI/CD and similar methodologies.
The attack occurs when a specific API endpoint has an adjacent endpoint using a different HTTP method (REST), an undocumented mutation (GraphQL), or even a different encoding. These “hidden” endpoints hold specific functionalities that were often not supposed to be exposed to the public.
In case such functionality can be found useful as part of an attack, attackers may perform unknown or unprivileged actions that will aid their attack. One example of such a case is a Reddit vulnerability, allowing users to bypass all ad content restrictions using a “hidden” PATCH endpoint that allows ad approval without any Reddit consent.
API7:2023 Security Misconfigurations
Misconfigurations remain at its rank as the seventh most popular API attack vector.
Of course, security misconfigurations are a much broader category that is valid for many topics other than APIs. However, since APIs are often designed on top of the underlying infrastructure, it may be a simple HTTP server or a shiny API Gateway. These infrastructure components must be configured appropriately. Any mistake in this configuration might compromise the entire API and all its endpoints.
One very simple yet common scenario would be the lack of proper SSL definition for an API, causing all requests to be sent over HTTP instead of HTTPS, which would allow for man-in-the-middle attack vectors to occur.
A recent vulnerability found by the Wiz security research team shows how severe these security issues can be. At a certain point within the attack chain, the researchers could gain access to the internal IBM cloud k8s API, which allowed them to escalate their attack further and finally to read and modify the data stored in its tenant's PostgreSQL database.
API9:2023 Improper Inventory Management
With the high number of APIs that are being exposed for many companies, and the number of new API endpoints that are being published frequently, the challenge of organizing, monitoring, discovering, and gaining more visibility into published APIs becomes a very big issue, and one that many organizations find difficult to properly address.
Some very common attack scenarios related to this category will be 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 of this category, 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. The company has set aside A$140M to cover the costs of this breach.
OWASP API Security Top 10 2023 — What Did Change
API3:2023 Broken Object Property Level Authorization
This new category deals with Object Properties level authorization as opposed to Object level authorization (API-1).
The main idea behind this new category is that even though a specific API can enforce sufficient object-level authorization security measures, it might still not be enough. Often, the authorization needs to be even more granular and include the objects and their properties. It is very common to find an API object having one public property and one private one, and these different access levels must also be addressed.
From a more logistical point of view, while this category is new, it combines two older 2019 categories into one. These categories include “Excessive Data Exposure” and “Mass Assignment,” which fit this new definition well.
The recent case of an incident reported by Twitter showcases the risk this category poses for even the biggest and well-reviewed services. In this case, an attacker could have enumerated existing Twitter users by providing their email addresses or phone numbers and examining the returned error response. In the case of an existing user, a specific error message property is changed in a deterministic way, allowing this enumeration process to occur.
API6:2023 Server-Side Request Forgery (SSRF)
A new and very appropriate category that has been added to the 2023 API Top 10 list is Server Side Request Forgery (“SSRF”).
SSRF happens when a user-controlled URL is passed over an API and is 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, and the risk for the environment becomes real.
SSRFs can come in many different types and flavors. Some common scenarios can include:
- The back-end server connects to an external attacker-controlled domain, and while doing so, it may expose internal credentials that can be used to escalate an attack.
- The back-end server connects to its loopback interface on various TCP ports, allowing an attacker to perform port scan service discovery on the back-end server itself.
- The back-end server connects to other internal services that would otherwise not be accessible to the attacker, enlarging the available attack surface and opening the door for additional chained attack vectors.
Recent research published by Salt Labs highlights the risks embedded within SSRF attacks. In this research, our Salt Lab researchers were able to gain access to the internal network resources of a giant Lego-owned website, thus potentially compromising the entire perimeter defense mechanisms supported by this famous web service.
API8:2023 Lack of Protection from Automated Threats
This new category focuses on a new and prevalent type of API attack that mainly addresses scenarios in which business logic flows are abused to allow malicious behavior.
While prevalent, these attacks are notoriously hard to detect and protect against.
In this attack category, the attack itself is a derivative of the sum of a set of requests, in which each individual request is entirely legitimate. Only when looking at the sum of API requests with regard to the specific business logic context does the attack reveal itself.
This category appears across all business sectors, and each attack will be entirely unique for each environment and each business logic. Detecting these attacks can happen only by looking at the overall user/request flows – inspecting each request individually will never reveal the attack.
This recently published research shows how researchers could abuse URL shortener services and their business logic by performing an automated attack. By performing this attack, the researchers could take over accounts of companies using the URL shortener service.
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. This category is not new; a large part of it was included in the OWASP API-8 2019 (Injection) section, in which many types of injection-based attacks could be carried out over APIs.
This new 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.
Perhaps the best, most recent, and most relevant example for this category would be the notorious Log4Shell attack, which sent severe waves across the entire Internet, allowing users to run arbitrary code on almost every web service using the very popular Log4j logging library, using a simply executed JNDI injection technique.
The second issue is closely related but 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.
A third party usually writes integrations, often containing a large amount of codebase, and it is often very complex to understand the code’s inner workings. However, applying them to your own service often takes just a few clicks or a few lines of code.
A very risky situation can arise where a service contains large amounts of unverified code — unverified from a security perspective. Some or all of this code directly interacts with the core service logic. This risk is a notorious attack surface and is one of the top go-to places for attackers to look for when hunting for vulnerabilities.
Although not exclusive to this category, API-based supply-chain attacks serve as a good example of this category's danger. In this recent research, security researchers uncovered a malicious campaign executed through the compromise of third-party WordPress and Magento plugins, affecting any implementation choosing to use this third-party integration without proper security validations.
Summary
While these changes to the API Security Top 10 list are still in comment mode, we expect the final version to be fairly similar to this version. We’re proud to see so much of the Salt input reflected in the verbiage, ranking, and examples in the current draft. We will keep you updated as the process moves forward, and we look forward to working through the industry’s broader comments and using them to strengthen this foundational security framework.
To learn more about how Salt can help defend your organization from API risks, you can connect with a rep or schedule a personalized demo.
