OWASP Top 10 API Security Risks: The 2023 Edition Is Finally Here
Today’s application programming interfaces (APIs) enable flexible and rapid integration among virtually any software, device, or data source. APIs serve a broad range of functionality and provide a foundation for innovation and digital transformation.
APIs have also become the de facto standard for building and connecting modern applications, especially with the increasing move to microservices-based architectures. It is important to properly secure APIs because they serve as the digital glue among systems.
Each of these API calls can potentially open security holes and create privacy risks ranging from poor data validation, configuration errors, and flaws in implementation to a lack of integration between security components. This is important to note when addressing the vulnerabilities defined within the Open Web Application Security Project (OWASP) Top 10 API Security Risks.
On June 5, 2023, OWASP issued the first major update to their initial list, which was released in 2019. Let’s review the changes and see which key factors are influencing today’s API vulnerabilities so you can be better informed on your journey to secure your APIs.
OWASP Top 10 API Security Risks
OWASP is a nongovernmental organization that creates security awareness documents based on community feedback and expert assessment, including contributions from Akamai. These documents describe the most common types of vulnerabilities found in organizations today and are an excellent resource for anyone involved with APIs, from developers to CISOs.
OWASP publishes a separate Top 10 API Security Risks document in addition to their other Top 10 lists to emphasize that API security requires a unique approach. The OWASP API Security Project “focuses on strategies and solutions to understand and mitigate the unique vulnerabilities and security risks of … APIs.”
The differences
Let’s review what’s different between the 2019 and 2023 editions (Figure 1).
Fig. 1: The changes in the 2023 OWASP Top 10 API Security Risks
According to the 2023 release notes:
The OWASP Top 10 API Security Risks 2023 is a forward-looking awareness document for a fast-paced industry. It does not replace other Top 10s. In this edition:
- We've combined Excessive Data Exposure and Mass Assignment focusing on the common root cause: object property level authorization validation failures.
- We've put more emphasis on resource consumption, over-focusing on the pace they are exhausted.
- We've created a new category "Unrestricted Access to Sensitive Business Flows" to address new threats, including most of those that can be mitigated using rate limiting.
- We added "Unsafe Consumption of APIs" to address something we've started seeing: attackers have started looking for a target's integrated services to compromise those, instead of hitting the APIs of their target directly. This is the right time to start creating awareness about this increasing risk.
What’s new, what’s in, and what’s out
NEW | API3:2023 | Broken Object Property Level Authorization
OWASP combined the former categories of Excessive Data Exposure and Mass Assignment into the new Broken Object Property Level Authorization (BOPLA), focusing on the common root cause: object property level authorization validation failures.
The difference between Broken Object Property Level Authorization (BOLA) and BOPLA is that BOLA refers to a whole object, while BOPLA refers to a property inside an object (Figure 2).
Fig. 2: BOPLA refers to a property inside an object
Both OWASP and Akamai continue to see major risks on the object level, which explains why BOLA remains the first and most critical API security risk to be aware of.
However, diving one level deeper and looking at the object property level, there is additional risk of oversharing information or allowing for specific properties that can be modified or deleted when that should not be the case.
Being covered for BOLA doesn’t mean you are covered for BOPLA, and combining Mass Assignment and Excessive Data Exposure into a single category emphasizes the attention required by API developers for properties in an object.
This distinction is important for those who are choosing an API security product because they need to make sure that the product covers both types of attack.
IN | API6:2023 | Server Side Request Forgery
OWASP lowered the Injection security risk and, in doing so, removed it from the top 10 and paved the way for Server-Side Request Forgery (SSRF) to be added.
SSRF is a type of attack that exploits a vulnerability in a web application or API that allows an attacker to make unauthorized requests from the server to other internal or external systems.
Here are some potential reasons why OWASP chose to make this change:
- APIs are more vulnerable to SSRF attacks because they rely on modern technologies, such as Kubernetes and Docker, which rely on HTTPS API-based communication protocols.
- With technologies such as Webhooks, SSO integrations, and URL file fetching/redirects through API endpoints, there is an opportunity for threat actors to apply SSRF.
A deeper dive
For a deeper dive into SSRF attacks, read Mike Elissen’s article Your APIs Are Enabling Server-Side Request Forgery (SSRF) Attacks.
OUT | API8:2019 | Injection
Removing Injection attacks from the list was a bold and contentious move within the API security community, but there is a reduced threat from Injection attacks on API endpoints.
Injection is now is essentially part of API8:2023 | Security Misconfiguration. Proper security configuration should include web application and API protection mechanisms, which should scan and prevent injections by default.
GraphQL is growing as an API technology. It is, at its core, a querying language that could re-open the door to a rise in Injection attacks, so API developers who rely on GraphQL should continue to stay vigilant.
NEW | API4:2023 | Unrestricted Resource Consumption
The original list focused specifically on understanding the risk of resource consumption that leads to API endpoints becoming overwhelmed (and potentially unavailable) harming user experience.
API endpoints these days need to be available — but just being available isn't everything. Implementing API gateway, load balancing, or rate limiting controls is a step in the right direction.
In recent years, we are seeing a huge shift in the “economics of API usage.” This updated category takes aim at creating awareness of this aspect, which will continue to grow with third-party API integrations.
NEW | API6:2023 | Unrestricted Access to Sensitive Business Flows
Another new addition is API6:2023 Unrestricted Access to Sensitive Business Flows. This category has finally codified what makes security so special: to think more like a threat actor and see where potential gains can be.
The technology (the API) is just a way to execute the business logic, and having ways of bypassing or altering this business logic through the technology is unwanted and could lead to complications.
OWASP shared specific examples of how these complications can be prevented, but this security risk is very specific to the business logic that your API endpoints are supporting.
API developers: Example
Recently, Mike Elissen had a conversation with API developers at a streaming service. To attract a new audience, this streaming service offered a free 30-day trial for new users who shared their credit card information.
However, the business logic was only looking at unique email addresses for new sign-ups. A new email address could easily access a new trial using the same credit card information, which could lead to users who create new accounts each month, using the service for free indefinitely.
NEW | API10:2023 | Unsafe Consumption of APIs
As third-party API consumption is growing rapidly, APIs often have to integrate and communicate with different internal and external (third-party) services, sending and receiving data.
It is important to follow the “basic” rules of security in those cases, too, and it can be complicated for security products to detect vulnerabilities and proactively defend in this space.
OWASP includes a range of suggestions in their document, both general and API-specific, such as:
- Follow redirections carefully. Build this oversight into the business logic as well as add security solutions that are continuously monitoring and inspecting the traffic flows.
- Do not simply trust third-party APIs, even if they have a good reputation. Build defenses and limits into your application and API endpoints.
Akamai can help with API security
Organizations and their security vendors must work closely together, aligning across people, processes, and technologies to institute a solid defense against the security risks outlined in the OWASP Top 10 API Security Risks.
Akamai provides industry-leading security solutions, highly experienced experts, and the Akamai Connected Cloud, which gleans insight from millions of web application attacks, billions of bot requests, and trillions of API requests every single day. Akamai’s web application and API security solutions will help secure your organization against the most-advanced forms of web application, distributed denial-of-service, and API-based attacks.
Akamai + Neosec
The new OWASP release coincides with our recent acquisition of Neosec. Neosec’s API security solution will complement Akamai’s market-leading application and API security portfolio by dramatically extending Akamai’s visibility into the rapidly growing API threat landscape.
The combination is designed to make it easy for customers to secure their APIs by helping them discover all their APIs, assess their risk, and respond to vulnerabilities and attacks.
Learn more
Learn more about Akamai’s API security solutions and our acquisition of Neosec.
Congratulations and thank you, OWASP!
Creating security awareness takes a huge effort from the community, and we appreciate OWASP for heading up this project. Special thanks to Erez Yallon, Inon Shkedy, and Paulo Silva for all their great work on the 2023 edition.
We also want to thank all the contributors, specifically Akamai’s Maxim Zavodchik and Mike Elissen for participating in this project and educating the larger developer community on API security.
Additional information about APIs
Akamai tracks the use of APIs and the amount of API traffic as part of its State of the Internet (SOTI) reports. Read previous SOTI reports for more information and look for new SOTI reports every quarter.
Additional resources
Video series: Fundamentals of API Security
Blog post: What Proposed New Changes in the OWASP API Security Top 10 Mean for You
