The OWASP (Open Worldwide Application Security Project) foundation is the authoritative figure when it comes to improving software security. Although the project has a strong focus on application security, the current OWASP Top 10 Web Application list does not encompass all of the challenges that modern web applications have today. The advent of APIs is changing the security landscape, which prompted the creation of the OWASP API Top 10 list in December 2019.

While traditional web applications process data on the server side and have them rendered client-side, modern API-based applications rely on the user interface to utilize APIs for facilitating data transfer and changes from the backend servers. Naturally, relying on APIs for facilitating said data transfers/changes results in the exposure of application logic and sensitive data such as PII. This ends up creating a much wider attack surface and makes APIs a now more preferred target for attackers especially given that many businesses have zero-to-little knowledge of their own APIs.

This list for the OWASP Top 10 API 2023 is out now and can be found on OWASP’s website or below.

The Differences You Need to Know

Below are the biggest differences found in the OWASP API Security Top 10 2023 and what to expect from them.

API3:2023 - Broken Object Property Level Authorization
API3:2023 - Broken Object Property Level Authorization now includes both API3:2019 - Excessive Data Exposure and API6:2019 - Mass Assignment. Both strategies are focused on manipulating API endpoints to gain access to sensitive data that the user is unauthorized to access or to gain privilege escalation. Attackers can easily figure out hidden and sensitive properties through fuzzing and evaluating API responses.

To mitigate this, you can validate whether a user should have access to an object property whenever they are accessing objects via the API endpoint. Developers should also avoid using generic methods and instead cherry-pick the specific object properties that need to be returned.

API4:2023 - Unrestricted Resource Consumption
API4:2019 - Lack of Resources & Rate Limiting has been reclassified to API4:2023 - Unrestricted Resource Consumption. The change occurred because some APIs require stricter policies depending on what data they share. Many APIs are being exhausted by third-party services continuously calling these APIs for large amounts of data.

To ensure system performance is not affected, you can apply strict policies. Consider using a solution that makes it easy to limit CPU, memory, number of restarts, and processes by using containers/serverless code (Lambdas). Developers can also define and enforce the maximum size of data on all incoming parameters and payloads.

API6:2023 - Unrestricted Access to Sensitive Business Flows
API6:2023 - Unrestricted Access to Sensitive Business Flows is a new addition in place of API6:2019 - Mass Assignment, which has been rolled into API3:2023 - Broken Object Level Authorization. This occurs where an attacker is able to find and automate access to sensitive business flows. This can lead to business-specific impacts, such as preventing legitimate users from purchasing a product, taking up reservations on a calendar and blocking available dates for real customers, or automating a purchasing process to buy up all the inventory and reselling it for a higher price.

Due to the nature of these kinds of vulnerabilities, protection needs to be viewed from two layers. From the business side, you must identify the business flows that would harm the business if they were to be abused in an automated fashion. From the engineering side, a proper defense mechanism needs to be implemented to mitigate the risk without impeding the use of the business flows. Some defenses would include using Captcha, detecting non-human behaviors, device fingerprinting, and IP blocking.

API7:2023 – Server Side Request Forgery
API7:2023 - Server Side Request Forgery has taken the place of API7:2019 - Security Misconfiguration (which has been moved down to API8:2023). This often occurs when APIs are fetching a remote resource without validating the user-supplied URL. Attackers can leverage server side request forgeries (SSRF) to access internal services and perform unauthorized actions being taken. SSRF vulnerabilities can also lead to command execution or be used as a scapegoat for performing malicious actions.

Some forms of preventions would include using allow lists, disabling redirection, validating and sanitizing all client input data, and isolating the resource fetching mechanism in your network.

API10:2023 - Unsafe Consumption of APIs
API10:2023 - Unsafe Consumption of APIs has replaced API10:2019 - Insufficient Logging & Monitoring. This refers to the exploitation of APIs/services that were integrated with a target API. Impact varies, but the integrated APIs can lead to data exfiltration and denial-of-service attacks.

When evaluating service providers, it is important to assess their API security posture. Prevention of unsafe consumption includes validating and sanitizing data received from integrated APIs before using it. Use an allow list to determine a number of safe locations that the integrated APIs can redirect you to. Lastly, make sure that all API communications happen over a secure communication channel.

Key Takeaways
As businesses modernize their applications, APIs have begun to take the spotlight for attackers. Proper management of API assets will set up the foundations for organizations to get proper oversight of their APIs. To stay ahead of the curve against attackers, organizations need to perform security assessments based off the new OWASP Top 10 API 2023 guidelines.