A Look at OWASP's Top 10 API Security Risks

The current OWASP list "Top 10 API Security Risks", an update of the 2019 list, highlights known and new risks. It also highlights what developers need to work on in terms of API security - and provides food for thought.

A classic e-commerce application works like a restaurant: it provides the services in the form of the menu, forwards the orders to the backend - the kitchen - and then delivers what the guests want. A modern web application, on the other hand, is more like a salad bar: the guest puts everything together from scratch - with a separate API for each ingredient. Today, task-specific apps and services share the work directly in a small-scale way. Without these interfaces - today primarily web APIs - our everyday online life would come to a standstill, as would the business world; at times, the term "API economy" even made the rounds.

When an ingredient plays such a critical role in the digital menu, it attracts attackers almost magically. The fact that OWASP (Open Web Application Security Project) has added a separate list of the ten biggest API risks to its well-known top 10 list of critical web vulnerabilities in 2019 shows just how threatening the API pot is threatening to boil over. The API risk list was recently updated. This provides interesting insights into which API threats are currently brewing.

The first thing that stands out: Four of the top five API risks relate to authentication and authorization. As in 2019, "Broken Object Level Authorization" also holds the top spot in 2023 (API1:2023). API3 ("Broken Object Level Property Level Authorization"), API5 ("Broken Function Level Authorization") and API2 ("Broken Authentication") work according to a similar recipe. With API4 ("Unrestricted Resource Consumption"), only one risk made it into the top 5 that opens the way to the salad bar for resource misuse due to a lack of limiting parameters - or more precisely: that allows DoS attacks to block this very path.

It is easy to understand why Broken Object Level Authorization is so persistently in first place: If an API endpoint does not check whether a user is actually authorized to access the requested object, this opens up a considerable attack surface. An attacker can gain access to internal data, including business secrets or - equally critical in view of the GDPR legal situation - personal data in order to exfiltrate, modify or delete it. The process is therefore similar to legitimate data traffic. Network-based defense tools therefore often only take effect once the attacker has exfiltrated internal data - or, in the worst case, has already exfiltrated it: The control only kicks in after the digital stalking has taken place, i.e. far too late.

API3:2023 ("Broken Object Level Property Level Authorization") in turn aggregates two points from the previous list: API3:2019 ("Excessive Data Exposure") and API6:2019 ("Mass Assignment"). This is because OWASP now focuses on their common cause: shortcomings in the procedure for validating authorization at object property level. This also paves the way for unauthorized persons to view and manipulate sensitive data.

A real - and very exciting - innovation in the top ten list, however, is API6:2023: "Unrestricted Access to Sensitive Business Flows". This is where OWASP moves away from pure technology and jumps straight to the level of business risks. The background: some programming or configuration errors in API endpoints give third parties insight into the business logic that should actually remain hidden behind the API - and this gives malicious third parties a taste for abusing the gap for lucrative purposes.

The OWASP report gives three vivid examples of this risk, including the following: An airline offers the online purchase of tickets with no cancellation fees. A malicious user books 90 percent of the seats for a desired flight. A few days before the flight, he cancels all the tickets at once, so the airline has to lower the ticket prices to fill the plane. Now the user buys a one-way ticket - considerably cheaper than the original one.

While new business-related risks have been added, there is a worrying omission from the 2019 API top ten list: The 2019 risk list granted a list item to the various varieties of injection attacks (SQL, NoSQL, command injection, etc.) (API8:2019). This point has now been dropped. This is because OWASP classifies injections as a general problem for (web) applications. This has led to lively discussions on GitHub.

The omission is not consistent for two reasons: Firstly, injections are one of the main risks even in modern web applications that use APIs. Nowadays, there are APIs that are not backed by a web application, but by a direct backend application. Similar to web applications, there is an injection risk here, but not XSS or similar. It is therefore still imperative to take precautions against API injections.

Secondly, the newly introduced list item API6:2023 "Unrestricted Access to Sensitive Business Flows" could be claimed to apply to the application side with at least the same justification. The omission is therefore incomprehensible. Above all, however, it is a cause for concern because it means that development teams may examine APIs less intensively for injections, meaning that this sensitive topic does not receive the attention it deserves in development.

In the current version, only a single attack variant gained its own place on the top ten podium because, according to OWASP, it is as widespread as it is easy to implement: server-side request forgery (SSRF). SSRF can occur when an API retrieves a resource without validating the URL specified by the user. In this way, an attacker can force the application to send a manipulated request to the desired target, even if the target is behind a firewall and should not be accessible from the outside.

According to OWASP, this type of attack is very explosive because web services, Kubernetes and Docker provide their management and control channels via HTTP on known or predictable paths. This makes them a perfect target for SSRF attacks.

This is reminiscent of an explosive incident from the year before last: at the end of 2021, the Log4Shell zero-day vulnerability in Log4j caused quite a stir. Although Log4Shell itself is not an SSRF vulnerability, it can be used for SSRF.

In addition to the aforementioned error of not limiting resource consumption through policies (API4:2023), the current API risk list includes another, similar group of configuration errors, which OWASP simply calls "Security Misconfiguration" (API8:2023). This point lumps together various security flaws, from a lack of security hardening of the API stack, outdated security patches and a lack of Transport Layer Security (TLS) to inadequate CORS (Cross-Origin Resource Sharing) guidelines, as well as error messages that contain stack traces or disclose sensitive information.

Finally, API9:2023 ("Improper Inventory Management") adds a colorful array of risks due to inadequate inventory and documentation. The proliferation of APIs, which is all too common today, quickly leads to inconsistencies in the API inventory and outdated documentation. The spectrum of gateways here ranges from unclearly defined APIs and the lack of a clear concept of when an API should be decommissioned, to an incomplete overview of sensitive data streams and data types.

In short, the increasingly granular division of labor between web APIs has created a wealth of explosive security risks. Some of the associated security gaps require little specialist knowledge on the part of the attackers, while others can be exploited automatically. These gaps are often based on dangerous default settings or on steps that were simply forgotten during configuration. As a result, misuse without precautions to protect the APIs is often only noticed when the milk has already been spilled.

• API1:2023 - Broken Object Level Authorization
  APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface of Object Level Access Control issues. Object level authorization checks should be considered in every function that accesses a data source using an ID from the user.
   
• API2:2023 - Broken Authentication
  Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user's identities temporarily or permanently. Compromising a system's ability to identify the client/user, compromises API security overall.
   
• API3:2023 - Broken Object Property Level Authorization
  This category combines API3:2019 Excessive Data Exposure and API6:2019 - Mass Assignment, focusing on the root cause: the lack of or improper authorization validation at the object property level. This leads to information exposure or manipulation by unauthorized parties.
   
• API4:2023 - Unrestricted Resource Consumption
  Satisfying API requests requires resources such as network bandwidth, CPU, memory, and storage. Other resources such as emails/SMS/phone calls or biometrics validation are made available by service providers via API integrations, and paid for per request. Successful attacks can lead to Denial of Service or an increase of operational costs.
   
• API5:2023 - Broken Function Level Authorization
  Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers can gain access to other users’ resources and/or administrative functions.
   
• API6:2023 - Unrestricted Access to Sensitive Business Flows
  APIs vulnerable to this risk expose a business flow - such as buying a ticket, or posting a comment - without compensating for how the functionality could harm the business if used excessively in an automated manner. This doesn't necessarily come from implementation bugs.
   
• API7:2023 - Server Side Request Forgery
  Server-Side Request Forgery (SSRF) flaws can occur when an API is fetching a remote resource without validating the user-supplied URI. This enables an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall or a VPN.
   
• API8:2023 - Security Misconfiguration
  APIs and the systems supporting them typically contain complex configurations, meant to make the APIs more customizable. Software and DevOps engineers can miss these configurations, or don't follow security best practices when it comes to configuration, opening the door for different types of attacks.
   
• API9:2023 - Improper Inventory Management
  APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. A proper inventory of hosts and deployed API versions also are important to mitigate issues such as deprecated API versions and exposed debug endpoints.
   
• API10:2023 - Unsafe Consumption of APIs
  Developers tend to trust data received from third-party APIs more than user input, and so tend to adopt weaker security standards. In order to compromise APIs, attackers go after integrated third-party services instead of trying to compromise the target API directly.

OWASP Top 10 API Security Risks (source: OWASP 2023).

The current OWASP list of the greatest API risks illustrates that the ways and means of attacking the well-oiled interlocking of APIs based on a division of labor are effective and varied. The protection of APIs must be organized with the same division of labour as the interaction of applications and services.

The first bulwark against API misuse is Identity and Access Management (IAM). IAM systems use standards such as OAuth, OpenID Connect or SAML to ensure in advance that the user is who they claim to be and assign well-dosed authorizations for access to applications and APIs. In this way, they avoid authentication errors (API2:2023).

However, this only covers one of the top ten API risks - and the requesting instance of an API call is by no means always a human user. After all, many API calls are made between participating services. Web Application and API Protection (WAAP) is therefore another important ingredient. WAAP includes a web application firewall (WAF) and an API gateway.

Originally, web application security and API security were two separate product categories. However, because more and more web applications are using APIs, a modern web application security solution must also include API protection - the two topics can no longer be considered separately from a security provider's perspective. The analyst firm Gartner confirmed this trend in 2019 by merging the two areas into "Web Application and API Protection" (WAAP). WAAP has now established itself as a product category for application-related protection mechanisms. WAAP solutions include a WAF and an API security gateway, as well as functions to protect against DoS attacks and to defend against malicious bots.

A WAF offers a range of protection mechanisms against attacks at (web) application level such as injections, XSS or SSRF, and also supports TLS data traffic (API7:2023, API8:2023). The API gateway in turn offers functions for enforcing API specifications and limiting API data traffic. In the context of microservices, Kubernetes and service meshes, it is also known as a microgateway. Unlike the classic WAF, a microgateway of this kind is not used to protect the perimeter of all applications, but to provide tailored protection for individual APIs and applications in the decentralized environment of containers.

So while OWASP launched two different top ten lists for web application and API risks in 2019, security providers went in exactly the opposite direction. In view of the above-mentioned inconsistencies between the two top ten lists (keyword: injection risks), this raises the question of whether a separate consideration of the OWASP Top 10 and OWASP API Top 10 makes any sense at all in the age of modern single-page applications (SPAs). Overlaps such as those in the area of injection risks speak more in favor of a joint top ten list of WAAP risks.

The collective term "security misconfiguration" (API8:2023) is naturally a broad field. However, a good WAAP solution helps here with "security by default" concepts. An example of this would be setting a secure CORS policy or removing a policy that is too open, such as "Access-Control-Allow-Origin".

The attack vectors resulting from the misuse of API-supported business processes (API6:2023) are relatively difficult to control at a purely technical level. According to OWASP, however, this point is aimed at attacks that exploit such weaknesses in an automated manner. WAAP solutions can counter such automated attacks with rate limiting, defense against malicious bots and machine learning-based analysis of data traffic.

When it comes to WAAP solutions, DevOps teams should not lose sight of one important point: In the context of API communication, people often talk about REST, but there are definitely other query languages, including GraphQL. Attackers like to use GraphQL in particular for API abuse, as this language allows significantly more complex queries than the comparatively simple REST. For example, a malicious GraphQL query could enable a denial of service attack that overrides rate limiting as a defense mechanism. With GraphQL introspection calls, on the other hand, the attacker can read the entire data schema at once. You should therefore make sure that the WAAP solution supports GraphQL - and of course you should deactivate introspection if possible if it is not absolutely necessary.

The bouncer still has its justification: What you can already keep out of the corporate network with classic perimeter protection should not be allowed in in the first place. WAAP solutions at the perimeter therefore continue to make sense. However, classic perimeter protection alone is no longer enough. Effective defense therefore requires a zero-trust architecture instead of the traditional "if you're in, you're trusted" approach. Microgateways can be useful here, for example, to carry out API-specific validations.

However, the most important role in the division of labor for API protection still falls to the developers. This is because security solutions - whether IAM, WAAP or others - can only ever solve a limited range of security problems. Security by design is therefore also necessary to prevent problems from arising in the first place. What is needed here are development teams that work thoroughly and with understanding - ideally supported by tools that automatically check code for security vulnerabilities and configurations for errors (API8:2023). After all, in our complex and fast-moving API world, it is ultimately a futile endeavor to fight gaps and misconfigurations only when the pot is about to boil over.

In addition to the technical risk, there is the business risk (API6:2023): The aforementioned purchase of a discounted airline ticket, enabled by the booking of numerous tickets based on API abuse, is in principle a rate-limiting problem, but not at the level of network traffic, but of ordering and canceling processes, i.e. at the business process level. Such abuse can only be stopped if development teams have a clear understanding of the business processes: Which processes can be detrimental to business if someone uses them excessively? Only in the second step can a decision be made as to which technical measures can be used to distinguish misuse from legitimate use and prevent it.

In short, protecting APIs requires not only a comprehensive security concept, but also an understanding of the business and a thorough, considered approach by the development teams. Otherwise, as countless security incidents have shown, it is all too easy to get into hot water.