OWASP Updates Top 10 API Security Risks
OWASP, the well-known cybersecurity research group, recently updated its API Security Top 10, which describes the top risks inherent in insecure APIs. The API Security Project was launched in 2019, and the 2023 update now provides a more accurate representation of the current threats facing application programming interfaces (APIs).
The 2023 list highlights various types of authorization flaws and introduces potential risks around business logic flows, improper inventory management, and more. APIs are commonly used to share data internally and connect with third parties. Yet, since APIs have become a common attack target, knowing the top risks associated with them is crucial to informing security best practices.
Below, I’ll briefly describe each security risk on the API Security Top 10 2023 and see what was changed from 2019. I also gathered some perspectives from cybersecurity experts to help determine why the update was made and what it reflects in the current threat landscape.
The OWASP API Security Top 10 2023
Here’s what the current list looks like:
- API1:2023 – Broken Object Level Authorization: This risk, often shortened to BOLA, refers to when it’s possible to change the ID of an object to return data the requesting party does not have permission to access. This vulnerability occurs at the object level and is likely number one because it’s highly prevalent and incredibly easy to exploit.
- API2:2023 – Broken Authentication: Authentication could be compromised in many ways. For example, if authentication permits brute forcing, weak passwords or loose identity control, it could easily be broken. This API vulnerability is severe since it could be used to completely take over a user account unnoticed.
- API3:2023 – Broken Object Property Level Authorization: This vulnerability may seem similar to BOLA, but is distinct. Broken Object Property Level Authorization is more of an issue of data overexposure. This risk occurs when a consumer can access sensitive properties that should not be shared with other users.
- API4:2023 – Unrestricted Resource Consumption: APIs without rate limiting can easily be subjected to denial-of-service attacks, which can override servers or cause high expenses. To avoid unrestricted resource consumption, place limits on bulk requests, large file sizes or high processing demands.
- API5:2023 – Broken Function Level Authorization: This type of vulnerability has to do with regular users being able to hit sensitive functions, such as modification, creation or deletion, that they should not otherwise be able to access. Administrative functions are a common target for this attack type.
- API6:2023 – Unrestricted Access to Sensitive Business Flows: This risk is less technical in nature and has to do with attackers leveraging gaps in business logic to their advantage. For example, an attacker might write a script to automatically purchase every ticket for a concert and then resell them on an external market at higher prices.
- API7:2023 – Server Side Request Forgery: Often abbreviated as SSRF, this attack type is common across the web. It occurs when an attacker directs the system to an unvalidated URL with malicious intent. Using input sanitation and an allow list can help curb SSRF.
- API8:2023 – Security Misconfiguration: This is a broad risk category pertaining to many types of insecure configurations. Often, these are publicly-known exploits, like insecure cloud service defaults, unpatched modules or missing TLS or CORS.
- API9:2023 – Improper Inventory Management: The rapid rise of distributed APIs and microservices can cause sprawl and lead to many undocumented services and multiple versions running simultaneously. Without solid inventory habits and API life cycle practices, old beta or shadow endpoints can pose risks if left unmaintained.
- API10:2023 – Unsafe Consumption of APIs: The software dependency chain is wide, and APIs often integrate with other APIs to perform their duties. Developers tend to trust interactions with external APIs more than user input, but these could have weaker security requirements, and the data might be compromised.
Three New Risks Were Added
One brand new vulnerability in 2023 is 6: API6:2023 – Unrestricted Access to Sensitive Business Flows. This risk suggests that hackers could leverage non-technical flaws in API-driven business flows. For example, consider a user who buys up all the seats for an airline flight and then cancels their tickets last minute at no cost. In that case, the airline might raise prices significantly to find last-minute fliers, at which point the hacker could purchase a new ticket at a discounted rate. This is borderline fraud, and gaps in logical flows are very common, said Yaniv Balmas, VP of security research at Salt Security.
Another entrant on the 2023 list is API7:2023 – Server Side Request Forgery. This is an older vulnerability and part of the generic OWASP Top 10. It was likely added to the API list because SSRF is seen often, specifically in APIs, making it a more common attack vector. “It’s super easy to do this with APIs, and it’s being attempted everywhere,” said Balmas. “When it’s successful, it could lead to very serious issues.”
According to Jeremy Snyder, founder and CEO, FireTail, these new risks “reflect the rising importance of APIs for organizations and the growing interdependence of software and business logic. Dependence on third-party APIs, exposure of flaws in exploitable business logic or vulnerability to request forgeries creates undue risk for organizations that don’t have mature API security programs.”
The last major addition is API10:2023 – Unsafe Consumption of APIs. Interaction with third-party APIs is quite common, and developers tend to place a lot of trust in their outputs. Yet, there could be a whole range of vulnerabilities laden in this data. If it’s not sanitized before being input into your services, it could lead to severe conditions, explained Balmas.
Other Changes From 2019 to 2023
So, what else changed in the updated 2023 list? Aside from slight name variations, many fundamentals were carried over from the OWASP API Security Top 10 2019. There are a few other changes worth noting.
For example, API3:2019 – Excessive Data Exposure and API6:2019 – Mass Assignment were combined to form API3:2023 – Broken Object Property Level Authorization. Authorization continues to plague many APIs. This is because API owners now juggle thousands of resources with unique permissions ranging from public to partner and private consumption, and controlling who can access what object properties is increasingly challenging. “The permission model can get super complex, really fast,” said Balmas. “It’s not trivial to set up.”
“One interesting observation from our research is that most API data breaches are the result of problems in authentication, authorization or data handling,” said Snyder. “The new OWASP Top 10 actually aligns much better with the problems that affect API owners in the real world.”
Other changes included the removal of API8:2019 – Injection, indicating a decrease in SQL injection-style attacks on APIs. Also removed was API10:2019 – Insufficient Logging & Monitoring, which suggests that API providers have adopted the right cloud-native monitoring practices in recent years.
How API Owners Should Respond
The updated OWASP list reflects the current state of the top important API risk categories. “These are the things that you as an API developer should be looking out for when developing your APIs and deploying them in production,” said Balmas. And plugging each hole will require a holistic approach. Here are some high-level ways to respond:
- Implement object-level authorization checks, and consider using randomly generated object IDs.
- Carefully assign and enforce privileges for sensitive functions.
- Put limits on request sizes, frequencies and what users can access.
- Place restrictions on business flows that might harm the business if used excessively.
- Avoid insecure configurations when possible.
- Document services and update these catalogs regularly.
“APIs pose a unique set of challenges because they sit at the intersection of networks, applications and cloud and can run on any compute platform,” said Snyder. As such, API providers must deploy a unique set of mitigations to comprehensively respond to today’s changing risk landscape.
For more information, I recommend developers read each OWASP risk above in detail to understand the specific scenarios they reference. OWASP also does a great job providing more fine-grained mitigation advice for each vulnerability.
