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. (https://owasp.org/API-Security/editions/2023/en/0x11-t10/)
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.
API6:2023 – Unrestricted Access to Sensitive Business Flows
API7:2019 Security Misconfiguration
API7:2023RC Security Misconfiguration
API7:2023 – Server Side Request Forgery
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.
The BOPLA vulnerability is apparent when allowing a user to access an object using an API endpoint, without validating that the user has access to the specific object properties they are trying to access.
New on the 2023 list and somewhat borrowed from the existing OWASP Top 10 2021 is API6:2023RC Server-Side Request Forgery (https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/).
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.
Stay tuned for a whitepaper on how the Noname API Security Platform addresses the 2023 OWASP API Top 10.
*** This is a Security Bloggers Network syndicated blog from Noname API Security Blog authored by Filip Verloy. Read the original post at: https://nonamesecurity.com/blog/updated-owasp-api-security-top-10