For many security providers, OWASP is a go-to source. As APIs have become more prevalent and widely adopted, the OWASP Top 10 API Security Risks report - a dedicated list of vulnerabilities to watch out for aimed at those building and maintaining APIs - has become a reference guide for some of the most common missteps and failures across the board.
In this blog, we will dig into the history of OWASP and the Top 10 API Security Risks and how they’ve changed since the inaugural report in 2019. Then, we will take an in-depth look at each of the vulnerabilities listed in the 2023 report, covering what they are, why they are significant, and how to prevent them from occurring.
To kick things off, let’s start by looking at the organization behind the report: OWASP.
What is OWASP?
The Open Web Application Security Project (OWASP) is a non-profit organization dedicated to improving software security. If you’ve taken a class in application security or heard anyone talk about it, chances are you’ve heard their name floating around.
Founded in 2001, OWASP operates under an open community model, where security experts, developers, and technologists collaborate to create massive amounts of material on application security. Most of these materials revolve around articles, methodologies, documentation, tools, and technologies in web application security.
OWASP is best known for its OWASP Top 10, a standard awareness document that helps developers and organizations understand the most critical security risks facing web applications. This list, regularly updated based on evolving threats and industry consensus, is a popular guideline for organizations and developers looking to understand and mitigate common security vulnerabilities.
OWASP's resources are designed to be accessible and beneficial for various stakeholders in the software development and security fields, promoting informed and secure software development practices globally.
What is the OWASP Top 10 API Security Risks (2023 Edition)
Although OWASP is known for its more widely applicable Top 10 report, the OWASP Top 10 API Security Risks report is a document solely focused on API security. Building on OWASP's long-standing expertise in web application security, this report specifically addresses the unique challenges and risks associated with Application Programming Interfaces (APIs).
The list identifies and ranks the top ten most critical security risks API developers face today. Developed through industry-wide surveys, expert input, and community feedback, the report offers a comprehensive overview of crucial API vulnerabilities. Also included are real-world examples of each vulnerability and strategies for mitigation.
The first edition of the OWASP Top 10 API Security Risks report was released in 2019. This inaugural edition marked a significant shift in focus towards the unique security challenges presented by APIs. OWASP developed the 2019 report in response to the rapidly increasing use of APIs in modern software development and the corresponding rise in security vulnerabilities related explicitly to APIs.
In June 2023, OWASP issued the first significant update to their initial API Security Top 10 list. Over the four years since its initial release, OWASP has collected data and feedback reflecting the evolving landscape of API security threats and the latest industry practices, applying this learning to a significantly updated Top 10 list. The 2023 edition of the report provides a comprehensive and up-to-date overview of the most critical API security risks - and it provides some critical updates to reflect the ever-changing landscape of API security.
What Has Changed Since the 2019 Report?
The changes between the OWASP Top 10 API Security Risks reports of 2019 and 2023 reflect the evolving landscape of API security threats and industry practices. Of course, some staples of the list have not changed. The entries on the list that have remained unchanged include:
1 - Broken Object Level Authorization
2 - Broken Authentication
5 - Broken Function Level Authorization
7 - Security Misconfiguration
9 - Improper Assets Management
Other than these five, which have remained the same, others have changed entirely or been significantly updated. Let’s take a look at the latest updates.
3 - Excessive Data Exposure (2019) to Broken Object Property Level Authorization (2023)
In the 2023 report, OWASP has combined the previously separate 2019 risks of Excessive Data Exposure and Mass Assignment into a new category, Broken Object Property Level Authorization. This reflects how providers have shifted towards a more nuanced approach to authorization, emphasizing the importance of fine-grained access control at the object property level. It addresses vulnerabilities where users access data they shouldn’t, either seeing or updating it, due to inadequate control of object properties.
4 - Lack of Resources & Rate Limiting (2019) to Unrestricted Resource Consumption (2023)
The 2023 report renamed this risk to emphasize the broader impact of unregulated resource consumption. This change highlights the critical need to limit API requests to prevent crashes, resource depletion, or high operational costs due to autoscaling.
6 - Mass Assignment (2019) to Server Side Request Forgery (SSRF) (2023)
SSRF was introduced as a new risk category in 2023, replacing Mass Assignment. The inclusion of SSRF as a top risk reflects the growing concern over attacks where an API is tricked into sending malicious requests to internal systems or servers. This threat is increasingly becoming more common.
8 - Injection (2019) to Lack of Protection From Automated Threats (2023)
The 2023 report replaced Injection with a focus on protection against automated threats. This update underscores the importance of defending APIs against automated attacks like bots, scripts, and credential stuffing. The update makes sense as these attacks become more prevalent and damaging without GUI-based defenses like those in web applications.
10 - Insufficient Logging & Monitoring (2019) to Unsafe Consumption of APIs (2023)
Lastly, the 2023 report introduced Unsafe Consumption of APIs, replacing the 2019 focus on logging and monitoring. This is spurred by the growing awareness of the risks of unquestioningly trusting data from third-party APIs. It underscores the necessity for rigorous validation of all data received from APIs, acknowledging that even reputable sources can be compromised.
Changes Reflect Complexity
These changes in the OWASP report from 2019 to 2023 highlight the massive changes that API developers have experienced in just over four years. These updates align with the increasing complexity and integration of APIs in modern applications, signaling critical areas for security focus and improvement.
Methodology Behind the OWASP API Top 10
As with any collated list of potential risks, the methodology is as important as the findings. OWASP builds its list through a comprehensive approach, joining data from many sources. While there is plenty of reported data in the form of vulnerability reports and disclosures, OWASP also benefits from a significant open-source contribution from various vendors, consultant groups, bug bounty reports, and organizational efforts. This ultimately results in a list that reflects both the publicly available data and the data typically reserved within closed-source or first-party reporting.
Importantly, OWASP maintains its non-profit and independent status. Although it does benefit from sponsorships, its data is platform and solution agnostic. In other words, if a weakness is present, it is reported. This has made the top ten list a trusted source for many providers.
Detailed Explanation of OWASP API Top 10
Finally, we have arrived at the entire list, updates, and all. In this next section, we will cover all ten vulnerabilities that OWASP has outlined. For each, we will cover what the vulnerability is and a brief example. We will also go over the consequences of not defending against such vulnerabilities, as well as how to prevent them.
Broken Object Level Authorization
This risk involves insufficient authorization checks when an API handles object identifiers, potentially allowing unauthorized access. An example would be if a user manipulates the ID in the URL to access another user's data. The consequence of having this type of vulnerability exploited is that attackers could gain unauthorized access to data, leading to data breaches and privacy violations. To prevent this type of exploit, you’ll want to implement robust and consistent object-level authorization checks across all API endpoints.
Broken Authentication
This occurs when authentication mechanisms are implemented incorrectly, potentially allowing attackers to compromise authentication tokens or user identities. An example of this would be if an authentication mechanism will enable attackers to use stolen tokens to impersonate a legitimate user. If broken authentication is in place, this could lead to unauthorized access, data breaches, and account takeovers. To ensure that your APIs don’t succumb to this type of exploit, you should use multi-factor authentication, secure token handling, and regular updates to authentication mechanisms.
Broken Object Property Level Authorization
This risk arises from inadequate or missing authorization checks at the object property level, leading to information exposure or manipulation. For example, this type of exploit happens when an attacker modifies an object property they shouldn't have access to, like changing the role property from 'user' to 'admin'. If this vulnerability is exploited within your APIs, you could expect to see unauthorized data manipulation and the risk of information leakage. To prevent this, you should implement fine-grained access control and validate authorization at the property level.
Unrestricted Resource Consumption
This involves API requests consuming excessive resources, leading to potential service disruption. A typical example of this would be when an attacker sends numerous complex requests to exhaust server resources, causing a denial of service. The apparent consequence of this type of exploit would be a Denial of Service attack, and since more resources are consumed, you could expect increased operational costs. The simplest way to prevent this type of attack is to implement rate limiting and quotas for each endpoint and enforce efficient resource management and monitoring for spikes.
Broken Function Level Authorization
This occurs when there are flaws in function-level access controls, potentially allowing unauthorized access to functions. This risk is embodied in scenarios such as when a regular user accesses administrative functions due to poorly implemented access controls. If users can access certain functions because of broken function level authorization, this might lead to unauthorized actions being performed and data breaches. To prevent this, ensure a clear separation of user roles and robust access control policies.
Unrestricted Access to Sensitive Business Flows
This exploit relates to when APIs expose business logic without adequate controls, leading to abuse or misuse. An example of this might be if someone uses automated scripts excessively using a 'free trial' feature. If allowed, you can expect the business logic to be abused, impacting operations and increasing costs. To prevent this type of behavior, developers should aim to implement business logic rate limiting and abuse detection mechanisms.
Server Side Request Forgery (SSRF)
This occurs when an API fetches a remote resource based on a user-supplied URI without proper validation. A typical execution of this attack involves attackers tricking the server into making requests to internal services within the organization's infrastructure. This might lead to internal network exposure and data breaches. To prevent this from happening, APIs should validate and sanitize all user-supplied URIs and restrict outbound requests.
Security Misconfiguration
This involves insecure default configurations, incomplete setups, or misconfigured HTTP headers. A common form of this issue is when an API server can be accessed with default credentials or when verbose error messages expose sensitive user data. This can lead to unauthorized access and data leakage. To prevent this from happening, developers should regularly review and update configurations and follow security best practices.
Improper Inventory Management
This happens when developers and their organizations fail to maintain an accurate inventory of deployed API versions and endpoints. An example of where this can cause issues is when outdated API versions remain operational and accessible, containing known (and unknown) vulnerabilities. The risk here is the possible exploitation of outdated or deprecated APIs. To prevent this, organizations should maintain a thorough and up-to-date inventory of all API endpoints and versions.
Unsafe Consumption of APIs
This involves insufficient validation or security checks when consuming third-party APIs. An example would be when a user trusts data from a third-party API without validation, leading to malicious data from the third-party API being processed. If allowed, it could lead to data corruption and security breaches through third-party integrations. To stop this from happening, developers should apply robust security checks and validations for all data received from third-party APIs.
Key Takeaways and Recommendations
The OWASP report provides several key takeaways that providers should consider.
First and foremost, OWASP points towards proactive efforts as a stronger solution than mitigation. Many of the problems on the top ten list are problems that exist because of lacking awareness or detail oriented thinking - for that reason, simple issues such as Broken Object Level Authorization, or BOLA, are surfaced alongside recommendations for better controls, checks on implementation, and overall observability of the platform.
Secondly, OWASP makes a point to suggest an awareness of - and in many cases, reduction of - the amount of data that is being exposed by an API. Overly verbose systems are easier to crack, and while simple misconfigurations are frighteningly common, it is the verbosity of the platform and the surfacing of attack vectors which compounds their threats so significantly.
The OWASP top ten list makes it clear that shifting left is the best policy for security in 2024. Integrating security early on in the life of a project and engaging in regular testing and validation is incredibly important, as is higher quality and more consistent education on the resultant risks of failing to adopt this strategy. APIs are the backbone of the modern internet, and in many ways - although OWASP doesn't say it in so many words - security needs to "level up" in many organizations and be taken as the much more critical facet that it actually is.
Conclusion
With that, we’ve done an in-depth exploration of the latest updates to the OWASP Top 10 API Security Risks. We’ve looked at the changes since the edition released in 2019 and reviewed the latest 2023 list from top to bottom.
To prevent these risks from impacting your APIs and operations, you’ll need the right toolkit as a developer. These exploits must often be stopped well before they can hit production. To do this, it makes sense to find and remedy these as early as possible when code is being written. Using a tool like StackHawk, users can test their APIs and applications to detect many of the OWASP API Top Ten Security Risks mentioned in the list.
By running StackHawk in your CI/CD flow, your code is tested in its running state, reporting potential vulnerabilities. Developers can then be aware of any vulnerabilities and fix them before they can be exploited. Want to know more about how StackHawk works? Check out the blog here. Sign up for a free trial today to try out StackHawk for yourself and protect your APIs against the OWASP Top 10!
