What Proposed New Changes in the OWASP API Security Top 10 Mean for You
The Open Worldwide Application Security Project (OWASP) has recently issued a release candidate (draft) for the first updated version of their API Security Top 10 document since 2019. Let’s review the proposed 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.
What is the OWASP Top 10?
OWASP is a nongovernmental organization that creates security awareness documents based on community feedback and expert assessment that describe the most common types of vulnerabilities found in organizations today.
The OWASP Top 10 was first published in 2003 and is regularly updated. The audience for the Top 10 ranges from developers to security analysts to CISOs. Some people focus on the more technical aspects of the document, and some use it to ensure that the products they purchase have the right coverage.
The OWASP API Top 10
OWASP publishes a separate API Top 10 document in addition to their web application security Top 10 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 Application Programming Interfaces (APIs).”
The API Top 10 has not been updated since 2019. Since then, the reliance on APIs across industries has become even more prevalent, with 70% of developers expected to increase API usage this year.
The latest updates to the OWASP API Security Top 10 release candidate are available now. Let’s review what looks different in the API vulnerability landscape today (Figure 1).
Fig. 1: The changes in the OWASP API Top 10 since 2019
Highlights of the recent changes
How API3:2023 BOPLA is different from API1:2023 BOLA
Mass Assignment and Excessive Data Exposure are now merged into Broken Object Property Level Authorization (BOPLA). 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
The new definition requires defenders to dive deeper into the objects, which increases the complexity and level of business logic understanding required to detect attacks.
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 for properties in an object.
This distinction is important for CISOs who are choosing an API security product because they need to make sure that the product covers both attacks.
API6:2023 Server Side Request Forgery is in, API8:2019 Injection is out
The OWASP community dropped Injection in severity and added Server Side Request Forgery (SSRF). This is a bold move, which indicates the changing landscape of managed security service providers and the changing expectations for security products to solve threats out of the box. This change also allows for details of another attack vector in the top 10.
Here are some suggested reasons why the OWASP community chose to make this change:
In the cloud, Kubernetes and Docker pass URLs over APIs, so more APIs could potentially be more vulnerable to SSRF than injection.
Using popular services (SaaS, PaaS, CloudaaS, etc.) are more likely to expose URLs than commands (such as SSO and OAuth 2.0) and are more likely to have redirects.
Injection is now is essentially part of API7:2023 Security Misconfiguration
Proper security configuration includes a web application firewall, which should prevent injections by default.
API8:2023 Lack of Protection from Automated Threats is new to the Top 10
OWASP suggests that rate-limiting defenses are less effective over time, and other than implementation flaws or any other vulnerabilities, bots can harm a company just by using the API as intended, but in an automated manner. The details refer to the OWASP Automated Threats to Web Applications, which doesn't have a unique perspective on API, but takes a general approach.
Here’s what you need to know about this addition:
Automated threats are overcoming defenses and becoming more sophisticated.
API is the focal point because of its goal to serve at large scale.
The automated threats defense layers have to observe all the business logic and not only APIs.
API10:2023 Unsafe Consumption of APIs also new to the Top 10
Because -aaS products are growing rapidly, APIs often have to integrate and communicate with different internal and external (third-party) services, sending data 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/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
Have security products that are checking/monitoring/inspecting the traffic flows
Do not trust third-party APIs, although they are most often paid services (e.g., recommendation engines or search engines).
Build defenses and limits into your app
Final insights and takeaways
The new OWASP Top 10 for API Security release candidate is a fantastic step in an API-specific direction, breaking farther away from the application-focused Top 10 and emphasizing the distinct nature of API threats.
Some takeaways to keep in mind include:
APIs are challenging to protect. The attacks are complicated, can be customer-specific, and can require understanding of the business logic inside the API. As a result, a security product likely needs higher compute power to adequately protect APIs.
OWASP has highlighted several new topics in the API security area:
Third parties and internal services should not be trusted
Cloud environments, containers, and Kubernetes are included as part of API security (at a high level) and play a role in the high risk of URLs passing (SSRF)
“Authorization” is the topic of four of the top five API attacks — objects, properties, and authentication. This emphasizes the complex nature of API authorization, and the difficulty in testing for and identifying vulnerabilities that are caused by faulty API logic, not a software problem.
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.
