OWASP API Security Top 10 2023 Security Risks

As explained by the online community, Open Web Application Security Project (OWASP), APIs are a critical part of modern applications. They allow software programs to communicate with each other and provide services to customers, partners, and internal teams. API security focuses on strategies to mitigate vulnerabilities, misconfiguration, and security risks of APIs.

OWASP API Top 10 2023 Report

OWASP’s API Security Top 10 was designed to help developers understand and address the most common security risks associated with APIs. OWASP’s API Security Top 10 2023 reflects the changing API threat landscape and addresses new attack vectors that have emerged since the last version was released in 2019. 

Below we provide a short description of each vulnerability on the 2023 list, along with OWASP’s summary.

Broken Object Level Authorization – API1:2023

Threat Agents/Attack Vectors	API Specific: Exploitability Easy Attackers can exploit API endpoints that are vulnerable to broken object-level authorization by manipulating the ID of an object of the request.
Security Weakness	Prevalence Widespread: Detectability Easy This issue is extremely common in API-based applications. The server component usually does not track the client’s state, and relies more on parameters like object IDs, which are sent from the client to decide which objects to access.
Impacts	Technical Moderate: Business Specific Unauthorized access to other users’ objects can result in data disclosure to unauthorized parties, data loss, or data manipulation. Unauthorized access to objects can also lead to full account takeover.

Broken Object Level Authorization (BOLA) is a security vulnerability that can occur in web applications or systems where access control relies on object identifiers. When there’s a flaw in the authorization implementation, attackers can manipulate or bypass access controls to gain unauthorized access to specific resources. In a well-implemented system, each object should have a unique identifier, and proper authorization checks should be enforced to make sure that only the user with the proper authorization can perform the requested action. 

Learn more about BOLA and how to protect your systems against it.

Broken Authentication – API2:2023

Threat Agents/Attack Vectors	API Specific: Exploitability Easy 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.
Security Weakness	Prevalence Common: Detectability Easy Software and security engineers’ misconceptions regarding authentication boundaries and inherent implementation complexity make authentication issues prevalent. Detecting broken authentication is easy with resources available.
Impacts	Technical Severe: Business Specific Attackers can gain complete control of other users’ accounts in the system, read their personal data, and perform sensitive actions on their behalf. Systems are unlikely to be able to distinguish attackers’ actions from legitimate user ones.

Broken Authentication is a security vulnerability that refers to the inadequate implementation of authentication mechanisms in API systems. This vulnerability occurs when authentication mechanisms such as passwords, access tokens, or session management are not properly implemented, leading to various attack vectors. Attackers can exploit this weakness to gain unauthorized access to sensitive data, impersonate legitimate users, perform unauthorized actions, or compromise the integrity and confidentiality of the API. Some common examples of broken authentication include weak password policies, improper session management, flawed multi-factor authentication (MFA) implementation, vulnerable password reset functionality, and security flaws in token-based authentication systems. 

Learn more about broken authentication and how to defend against it. 

Broken Object Property Level Authorization – API3:2023

Threat Agents/Attack Vectors	API Specific: Exploitability Easy APIs tend to expose endpoints that return all object’s properties, especially REST APIs. Identifying additional properties that can be manipulated requires more effort, but there are automated tools available to do this task.
Security Weakness	Prevalence Common: Detectability Easy Inspecting API responses is enough to identify sensitive information in returned objects’ representations. Fuzzing is usually used to identify additional properties. Whether they can be changed is a matter of crafting an API request and analyzing the response.
Impacts	Technical Moderate: Business Specific Unauthorized access to sensitive object properties may result in data disclosure, data loss, or data corruption. Under certain circumstances, unauthorized access to object properties can lead to privilege escalation or partial/full account takeover.

New on the 2023 list, Broken Object Property Level Authorization refers to a security vulnerability that occurs when an API does not properly enforce authorization controls at the object or property level. In API systems, authorization controls ensure that authenticated users have the appropriate permissions to access and manipulate specific objects or properties within the system. 

When this vulnerability is present, an attacker may be able to access or change unauthorized object properties by exploiting flaws in the authorization mechanisms. This could result in unauthorized data access, modification, or deletion. 

Unrestricted Resource Consumption – API4:2023

Threat Agents/Attack Vectors	API Specific: Exploitability Average Exploitation requires simple API requests. Multiple concurrent requests can be performed from a single local computer or by using cloud computing resources. Most tools available are designed to cause DoS via high loads of traffic.
Security Weakness	Prevalence Widespread : Detectability Easy It’s common to find APIs that do not limit client interactions or resource consumption. Crafted API requests, such as those including parameters that control the number of resources to be returned.
Impacts	Technical Severe: Business Specific Exploitation can lead to DoS due to resource starvation, but it can also lead to operational costs increase, such as those related to the infrastructure due to higher CPU demand and increasing cloud storage needs.

Another new entry, Unrestricted Resource Consumption, also known as resource exhaustion or resource depletion, refers to a security vulnerability where an API does not effectively limit the interactions or resource consumption. The unrestricted consumption of resources can occur in various ways, such as by submitting excessive or maliciously crafted requests, exploiting design flaws, or bypassing rate limiting and throttling mechanisms. This vulnerability can lead to denial-of-service (DoS) attacks, where an attacker intentionally consumes excessive resources, causing the underlying system to become unresponsive to legitimate users. These attacks can cause a significant impact on the availability, performance, and stability of the API and the systems it relies on.

Learn more about how to protect against DoS attacks

Broken Function Level Authorization – API5:2023

Threat Agents/Attack Vectors	API Specific: Exploitability Easy Exploitation requires the attacker to send legitimate API calls to an API endpoint that they should not have access to as anonymous users or regular, non-privileged users. Exposed endpoints will be easily exploited.
Security Weakness	Prevalence Common: Detectability Easy Authorization checks for a function or resource are usually managed via configuration or code level. Implementing proper checks can be a confusing task since modern applications can contain many types of roles, groups, and complex user hierarchies. It’s easier to discover these flaws in APIs since APIs are more structured.
Impacts	Technical Severe: Business Specific Such flaws allow attackers to access unauthorized functionality. Administrative functions are key targets for this type of attack and may lead to data disclosure, data loss, or data corruption. Ultimately, it may lead to service disruption.

Broken Function Level Authorization is a security vulnerability that can occur in API systems when the authorization checks are not properly implemented at the function or endpoint level. This vulnerability allows attackers to bypass the intended access restrictions and gain unauthorized access to certain API functions or endpoints. When broken function level authorization is present, attackers can exploit this weakness to perform unauthorized actions or access sensitive functionality that should be restricted to certain roles or users. This can lead to various security risks, including unauthorized data access, data manipulation, privilege escalation, or the execution of unauthorized API functions. 

Learn more about broken function level authorization and how you can defend against it.

Unrestricted Access to Sensitive Business Flows – API6:2023

Threat Agents/Attack Vectors	API Specific: Exploitability Easy Exploitation usually involves understanding the business model backed by the API, finding sensitive business flows, and automating access to these flows, causing harm to the business.
Security Weakness	Prevalence Widespread: Detectability Average Lack of a holistic view of the API in order to fully support business requirements tends to contribute to the prevalence of this issue. Attackers manually identify what endpoints are involved in the target workflow and how they work together.
Impacts	Technical Moderate: Business Specific Exploitation might hurt the business in different ways, for example: prevent legitimate users from purchasing a product or lead to inflation in the internal economy of a game.

New on the 2023 list, Unrestricted Access to Sensitive Business Flows is a security vulnerability that can occur in API systems when there is inadequate control over excessive use of sensitive business processes or flows. This vulnerability allows users to exploit overuse of sensitive, business-critical actions to harm the business such as over purchasing a product, creating comments, or making a reservation using API-driven services. The consequences of unrestricted access to sensitive business flows could be disruption of critical operations or services, financial losses, product availability, and negative user experience.

Server Side Request Forgery – API7:2023

Threat Agents/Attack Vectors	API Specific: Exploitability Easy Exploitation requires the attacker to find an API endpoint that accesses a URI that’s provided by the client. In general, basic SSRF (when the response is returned to the attacker), is easier to exploit than Blind SSRF in which the attacker has no feedback on whether or not the attack was successful.
Security Weakness	Prevalence Common: Detectability Easy Modern concepts in application development encourage developers to access URIs provided by the client. Lack of or improper validation of such URIs are common issues. Regular API requests and response analysis will be required to detect the issue.
Impacts	Technical Moderate: Business Specific Successful exploitation might lead to internal services enumeration, information disclosure, bypassing firewalls, or other security mechanisms. This can lead to DoS or the server being used as a proxy to hide malicious activities.

Another new addition in 2023, Server Side Request Forgery (SSRF) is a security vulnerability that can occur in API systems where an attacker can manipulate or forge requests sent by the server to other internal or external systems. SSRF allows an attacker to make unauthorized requests to internal resources or external endpoints on behalf of the server.

When this vulnerability is present, an attacker can exploit it to perform various malicious activities, such as accessing sensitive information or resources, bypassing security controls, initiating remote code execution, or launching attacks against other systems. The attacker can typically manipulate the target URL or parameters to control the server’s requests and direct them to unintended or unauthorized destinations.

Security Misconfiguration – API8:2023

Threat Agents/Attack Vectors	API Specific: Exploitability Easy Attackers will often attempt to find unpatched flaws, common endpoints, services running with insecure default configurations, or unprotected files and directories to gain unauthorized access or knowledge of the system.
Security Weakness	Prevalence Widespread: Detectability Easy Security misconfiguration can happen at any level of the API stack, from the network level to the application level. Automated tools are available to detect and exploit misconfigurations.
Impacts	Technical Severe: Business Specific Security misconfigurations not only expose sensitive user data, but also system details that can lead to full server compromise.

Security Misconfiguration is a security vulnerability that refers to the improper configuration of security controls and settings in API systems. It occurs when the API is deployed with default, weak, or insecure configurations, leaving it vulnerable to exploitation. When security misconfigurations are present, attackers can take advantage of these weaknesses to gain unauthorized access, manipulate data, or disrupt the API’s functionality. Common examples of security misconfigurations include using default credentials, improper access controls, insecure default configurations, and use of unnecessary features or services. 

Learn more about security misconfiguration and how you can address it

Improper Inventory Management – API9:2023

Threat Agents/Attack Vectors	API Specific: Exploitability Easy Threat agents usually get unauthorized access through old API versions or endpoints left running unpatched and using weaker security requirements. Alternatively, they may get access to sensitive data through a 3rd party with whom there’s no reason to share data.
Security Weakness	Prevalence Widespread: Detectability Average Outdated documentation makes it more difficult to find and fix vulnerabilities. Lack of assets inventory and retirement strategies leads to running unpatched systems, resulting in leakage of sensitive data. It’s common to find unnecessarily exposed API hosts because of modern concepts like microservices, which make applications easy to deploy and independent.
Impacts	Technical Moderate: Business Specific Attackers can gain access to sensitive data, or even take over the server. Sometimes different API versions are connected to the same database with real data. Threat agents may exploit deprecated endpoints available in old API versions to gain access or exploit known vulnerabilities.

Improper Assets Management on the 2019 list has become Improper Inventory Management in 2023. This is a security vulnerability that relates to inadequate tracking and management of API assets and resources. It occurs when organizations fail to effectively monitor, secure, and control the inventory of APIs and associated components. When there are improper inventory management practices, several risks and issues can arise. These include unauthorized access to APIs, outdated or vulnerable API versions being exposed, lack of visibility into API dependencies, and potential exposure of sensitive data or functionality.

Unsafe Consumption of APIs – API10:2023

Threat Agents/Attack Vectors	API Specific: Exploitability Easy Exploiting this issue requires attackers to identify and potentially compromise other APIs/services the target API integrated with. Usually, this information is not publicly available.
Security Weakness	Prevalence Common: Detectability Average Developers tend to trust and not verify the endpoints that interact with external or third-party APIs, relying on weaker security requirements. Attackers need to identify services the target API integrates with data sources and compromise them.
Impacts	Technical Severe: Business Specific The impact varies according to what the target API does with pulled data. Successful exploitation may lead to sensitive information exposure to unauthorized actors, many kinds of injections, or denial of service.

Finally, new this year is Unsafe Consumption of APIs, a security vulnerability that occurs when APIs are consumed in an insecure manner, leading to potential security risks and vulnerabilities. This vulnerability encompasses various unsafe practices and behaviors by API consumers. Unsafe consumption of APIs can result in several security issues, including unauthorized access, data leakage, injection attacks, and compromised integrity and confidentiality of the data being exchanged. It often arises from inadequate validation, insecure coding practices, or insufficient understanding of the API’s security requirements.

OWASP API Security Top 10: 2019 vs 2023 Release Candidate vs 2023 Top 10

There are some similarities between the 2019, 2023 release candidate, and final 2023 lists. For example, all include security concerns related to broken authentication and authorization. However, there are many notable changes between the three lists. Below we’ll dig into exactly what’s changed.

OWASP API Security Top 10 2023 Changes

• API3:2023 Broken Object Property Level Authorization brings together attackers gaining unauthorized access to sensitive information by way of API3:2019 Excessive Data Exposure and API6:2019 Mass Assignment. Both strategies are focused on manipulating API endpoints to gain access to unauthorized and typically sensitive data.
• API4:2023 Unrestricted Resource Consumption directly ties back to API3:2019 Lack of Resources & Rate Limiting, this time focusing on protecting the availability of resources to serve legitimate, but resource-intensive, requests.
• API6: Unrestricted Access to Sensitive Business Flows is new to the list but also ties back largely into API8:2023RC Lack of Protection from Automated Threats. This vulnerability calls out attackers exploiting business-sensitive functionality to damage the business, commonly done with bots or automated threats.
• API7:2023 Server Size Request Forgery is new on the list compared to the 2019 version. This vulnerability calls out the risks when an API fetches a remote resource without validating the destination, allowing an attacker to bypass the request and redirect to a malicious location.  
• API9:2023 Improper Inventory Management is the evolved version of API9:2019 Improper Assets Management, continuing to focus on the importance of tracking and managing your organization’s attack surfaces.

These changes highlight how attackers are evolving their strategies to exploit private, public, and third-party API services that drive our modern applications and online services. The changes above also call out how organizations need to mature their API security programs to be more risk- aware when selecting third-party services, document all aspects of APIs that are implemented, and build up the protection mechanisms to ensure APIs are being used securely.

What should I do now?

Overall, hats off to the OWASP community for organizing the release candidate, enabling the community to influence the final 2023 API Security Top 10 list. Below are OWASP’s recommendations as seen in https://owasp.org/API-Security/editions/2023, on how to protect APIs against the latest threats.

• API1:2023 Broken Object Level Authorization- OWASP recommendations call for implementing an authorization mechanism so users can log in before performing the requested action. Use random and unpredictable values as GUIDs. Be sure to test authorization mechanisms for vulnerabilities before deploying.  
• API2: 2023 Broken Authentication- OWASP recommendations call for following the standards in authentication, token generation, or password usage. Use the OWASP Authentication Cheatsheet, where possible implement multi-factor authentication. Implement anti-brute force mechanisms and account lockout capabilities to mitigate credential stuffing and other brute force attacks on your authentication APIs and user accounts. API keys should not be used for user authentication, only for API clients.
• API3:2023 Broken Object Property Level Authorization- OWASP recommendations call for avoiding generic methods when designing APIs and binding a client’s input into code variables. Implement a schema-based response validation mechanism and return the bare-minimum for data.  
• API4:2023- OWASP recommendations call for limiting resources, enforcing max size of data or files on incoming API parameters or payloads. Implement a client limit for third-party API usage within a specific timeframe with alerts. Rate limit or throttle API calls especially with authentication APIs or define stricter policies for APIs that consume larger amounts of computational resources.  
• API5:2023- OWASP recommendations call for using proper authorization checks in place, enforce access controls based on authenticated user’s role, permissions, or other relevant factors. It’s crucial to validate user’s access rights before allowing them to use specific API functions or access sensitive endpoints.  
• API6:2023- OWASP recommendations call for protection mechanisms to mitigate business risk with device fingerprinting, human detection, and detection of non-human patterns by analyzing interactions.     
• API7:2023- OWASP recommendations call for isolating resource fetching mechanisms in your environment. Validate and sanitize all client-supplied input data. Whenever possible, disable HTTP redirections, check for specific media types for a given function as well as URL schemes and ports.  
• API8:2023- OWASP recommendations call for repeated hardening of infrastructure, continuous review of configurations across the entire API stack, and automatically assessing the effectiveness of current configurations. Ensure all API communications happen over an encrypted communication channel (TLS) regardless of internal or public-facing API.  
• API9:2023- OWASP recommendations call for implementing protection measures and mechanisms for API inventory discovery, and documentation of all aspects of your APIs, including endpoints, parameters, requests, responses, authentication, errors, redirects, and rate limiting. 
• API10:2023- OWASP recommendations call for closely evaluating third-party API services before using them. Ensure all API interactions are over TLS, validate and sanitize data received from third-party APIs. Maintain an allowlist of redirect locations, do not blindly follow redirects.