2023 OWASP Top 10 API Security Risks: Broken Authorization and Authentication
APIs (Application Programming Interfaces) are the cornerstone of the digital economy and their numbers continue to increase. In fact, according to its’ “State of APIs Report” Rapid reported approximately 70% of developers and other survey respondents expect to use even more APIs in 2023 than last year.
Not surprisingly, as more enterprises use APIs, their attack surface continues to grow. APIs have become the primary entry point for anyone who wants to hack an organization and are under constant attack. In fact, one of our customers reported that their company experienced 60,000 hits a day against their APIs from various countries, including Russia and North Korea.
As my colleague recently wrote about, the non-profit Open Web Application Security Project (OWASP) recently published its latest OWASP Top 10 API Security Risks list. In this first piece of our three-part series, we’ll examine the top three risks on the 2023 list: Broken Object Level Authorization, Broken Authentication and Broken Object Property Level Authorization.
The Rise of API-Based Risks
The analyst firm Enterprise Strategy Group (ESG) study found that the majority (75%) of organizations typically change or update their APIs on a daily or weekly basis, creating a significant challenge for protecting the changing API attack surface. In order to get inside an enterprise, hackers need to manipulate authentication and authorization. Not surprisingly, the most recent OWASP API Security Top 10 list risks include:
Broken Object Level Authorization: Attackers can exploit API endpoints that are vulnerable to broken object-level authorization by manipulating the ID of an object that is sent within the request. Object IDs can be anything from sequential integers, UUIDs, or generic strings. Regardless of the data type, they are easy to identify in the request URL (path or query string parameters), request headers, or even as part of the request payload.
Broken Authentication: The authentication mechanism is an easy target for attackers since it’s exposed to everyone. Although more advanced technical skills may be required to exploit some authentication issues, exploitation tools are generally available.
Broken Object Property Level Authorization: APIs tend to expose endpoints that return all object’s properties. This is particularly valid for REST APIs. For other protocols such as GraphQL, it may require crafted requests to specify which properties should be returned. Identifying these additional properties that can be manipulated requires more effort, but there are a few automated tools available to assist in this task.
OWASP rated the exploitability of each of these risks as “easy” and prevalence as “widespread” or “common.” Whether it is cross-site request forgery, server-side request forgery or a man-in-the-middle attack, hackers will try to access that authentication token or try to get into the application using the user credential. Simple authentication – a username and password – is not enough in today’s app economy. There is very powerful sophisticated software such as Bots that can do a brute force attack, whether to do credential stuffing or manipulate the request using acquired JWT tokens.
Regarding authorization, we need to make sure that users are only able to access what is allowed to access, not everything. If there is no proper authorization control from an object point of view, from an actual API verb, or a function point of view, they can do more damage to the organization. It is critical to understand who the users are, and the level of authorization they are allowed to do, and what they are trying to do.
Specifically with Broken Object Property Level Authorization, the API endpoint exposes properties of an object that are considered sensitive and should not be read by the user. The API endpoint allows a user to change, add/or delete the value of a sensitive object’s property which the user should not be able to access. If a user has improper authorization, the user can go and edit or change the user ID to bring in other users, different divisions or domains of an organization, For example, if you have a particular division A, the end user may get improper access to see all the users for that particular division. You need to create restrictions and, by default, proper rules and regulations. OWASP recommends that the data returned by the API should be kept to the absolute minimum required for each individual user type.
Looking Ahead
Without the proper authorization and authentication restrictions, APIs can serve as a potential security “loophole” that can lead to costly business disruptions or data exfiltration. In the next blog in this series, we’ll examine potentially more serious risks on the OWASP Top 10 API Security Risks list: Security Misconfiguration, Unrestricted Resource Consumption and Unrestricted Access to Sensitive Business Flows