The Updated OWASP API Security Top 10 for 2023 is Here
The Open Web Application Security Project (OWASP) is a global non-profit organization dedicated to improving the security of software. The OWASP foundation first released a list of the top 10 security risks faced by APIs in 2019. After a couple of months of healthy debate on the release candidate we now have the finalized updated list for 2023.
Although 4 years is an extremely long time when it comes to computing, the fact remains that most organizations are still in the process of putting better API security controls in place to protect against the 2019 Top 10. Additionally, remember that the list contains ten categories of vulnerabilities, each category housing multiple vulnerabilities.
Comparing the lists, it is of little wonder that the 2023 RC one remains fairly close to the 2019 one, and the final version hasn’t significantly changed either. While #1 remains the same, the rest of the list has new language, new categories, and a shuffling of those that are still from the 2019 version.
| API1:2019 Broken Object Level Authorization | API1:2023RC Broken Object Level Authorization | API1:2023 – Broken Object Level Authorization |
| API2:2019 Broken User Authentication | API2:2023RC Broken Authentication | API2:2023 – Broken Authentication |
| API3:2019 Excessive Data Exposure | API3:2023RC Broken Object Property Level Authorization | API3:2023 – Broken Object Property Level Authorization |
| API4:2019 Lack of Resources & Rate Limiting | API4:2023RC Unrestricted Resource Consumption | API4:2023 – Unrestricted Resource Consumption |
| API5:2019 Broken Function Level Authorization | API5:2023RC Broken Function Level Authorization | API5:2023 – Broken Function Level Authorization |
| API6:2019 Mass Assignment | API6:2023RC Server Side Request Forgery | API6:2023 – Unrestricted Access to Sensitive Business Flows |
| API7:2019 Security Misconfiguration | API7:2023RC Security Misconfiguration | API7:2023 – Server Side Request Forgery |
| API8:2019 Injection | API8:2023RC Lack of Protection from Automated Threats | API8:2023 – Security Misconfiguration |
| API9:2019 Improper Assets Management | API9:2023RC Improper Assets Management | API9:2023 – Improper Inventory Management |
| API10:2019 Insufficient Logging & Monitoring | API10:2023RC Unsafe Consumption of APIs | API10:2023 – Unsafe Consumption of APIs |
Release Candidate Changes
As with the 2019 version, the 2023 release candidate still holds firm that business logic based attacks misusing authorization implementations (BOLA) remain the biggest risk category for APIs today and into the foreseeable future.
An API potentially serves many users and provides access to multiple pieces of data, frequently sensitive data. These different users and user types naturally have different data access policies, depending on the business need. From an API design and development perspective, it remains challenging to build an API that correctly enforces these granular authorization policies. We witness this daily as customers test their code using our Active Testing solution.
The new list also consolidates two existing categories under API3:2023RC BOPLA (Broken Object Property Level Authorization). In the 2019 list, they were separated out in:
- API3:2019 Excessive Data Exposure, whereby the API returns sensitive data to the client by design. This data is expected to be filtered on the client side before being presented to the user, but an attacker can easily sniff the traffic and see the sensitive data.
- API6:2019 Mass Assignment whereby the sensitivity of internal objects is misjudged, and the API endpoint automatically converts client parameters into internal object properties.
New on the 2023 list and somewhat borrowed from the existing OWASP Top 10 2021 is API6:2023RC Server-Side Request Forgery.
Server-Side Request Forgery (SSRF) flaws occur whenever an API fetches a remote resource without validating the user-supplied URL. It allows an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall or a VPN. Using modern concepts like Webhooks, file fetching from URLs, custom SSO, and URL previews, encourages developers to access an external resource based on user input, heightening the potential risk. Additionally, concepts like microservices based architectures expose control/management plane elements over HTTP using well known paths, making them an easier target.
API4:2023RC Unrestricted Resource Consumption borrows heavily from API4:2019 Lack of Resources & Rate Limiting, with a focus on protecting the available compute and storage resources to successfully serve legitimate API requests. By managing API limits around timeouts, processes, available memory, number of operations, etc., we can prevent an unfair distribution of resources.
API8:2023RC Lack of Protection from Automated Threats, these types of attacks have increased as commercial businesses move more and more to API based systems for eCommerce purposes. Traditional API Gateway and WAF based solutions like rate limiting fall short, as bot-net operators use more distributed approaches to launch their attacks. For these types of attacks, it remains paramount that we identify the malicious traffic and implement automated blocking actions to safeguard the API and allow normal business traffic to continue to flow.
Server-Side Request Forgery (SSRF) flaws occur whenever an API fetches a remote resource without validating the user-supplied URL. It allows an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall or a VPN. Using modern concepts like Webhooks, file fetching from URLs, custom SSO, and URL previews, encourages developers to access an external resource based on user input, heightening the potential risk. Additionally, concepts like microservices based architectures expose control/management plane elements over HTTP using well known paths, making them an easier target.
API4:2023RC Unrestricted Resource Consumption borrows heavily from API4:2019 Lack of Resources & Rate Limiting, with a focus on protecting the available compute and storage resources to successfully serve legitimate API requests. By managing API limits around timeouts, processes, available memory, number of operations, etc., we can prevent an unfair distribution of resources.
API8:2023RC Lack of Protection from Automated Threats, these types of attacks have increased as commercial businesses move more and more to API based systems for eCommerce purposes. Traditional API Gateway and WAF based solutions like rate limiting fall short, as bot-net operators use more distributed approaches to launch their attacks. For these types of attacks, it remains paramount that we identify the malicious traffic and implement automated blocking actions to safeguard the API and allow normal business traffic to continue to flow.
Final Version Changes
The “new’ ‘ category is API6:2023 Unrestricted Access to Sensitive Business Flows, which is a lack of understanding which business flow your newly created API exposes. Some business flows are more sensitive than others, in the sense that excessive access to them may harm the business. For example;
A ride-sharing app provides a referral program – users can invite their friends and gain credit for each friend who has joined the app. This credit can be later used as cash to book rides.
An attacker exploits this flow by writing a script to automate the registration process, with each new user adding credit to the attacker’s wallet.
The attacker can later enjoy free rides or sell the accounts with excessive credits for cash.
So identifying the user identity and limiting access or timed access would be a good way to mitigate this type of attack.
The previous API8:2023RC Lack of Protection from Automated Threats was dropped or subsumed by API6:2023 as it mostly addresses a similar issue.
API9:2023 Improper Inventory Management has replaced API9:2023RC Improper Assets Management and matched wonderfully well with the Noname Platform capabilities as it turns out.
How Noname Security Addresses the OWASP Top 10
Noname Security provides the option to view your API issues through the lens of both
the 2019 and 2023 versions. If you use the OWASP list as a guideline in prioritizing
vulnerabilities, it will be easier to link real life findings to the framework.
