What’s New in OWASP API Top 10 2023: The Latest Changes and Enhancements

As APIs continue to increase across industries, so too do the threats to their security. The OWASP API Top 10 list is an essential resource for businesses looking to secure their application programming interfaces.

OWASP is best known for releasing the top 10 security risks and vulnerability lists for web apps, mobile apps, APIs, and so on, which are revised every four years to reflect the latest threats and risks affecting organizations globally.

The OWASP API Top 10 2019 edition provided a comprehensive overview of the top threats facing APIs at that time, but the threat landscape has evolved rapidly since then. To address these changes and provide new insights and recommendations for API security, the OWASP released the API Top 10 2023 list.

The list has quite a few changes from the 2019 Top 10 API security risks. What are these changes in the OWASP API Top 10 2023 vs. 2019?

Analyzing the Differences: OWASP Top Ten API 2023 and 2019 Lists

OWASP API Top 10 2023 risks


Comparing the OWASP API Top 10 2023 security risks list with the 2019 list, we can see that some categories remain, some have been modified while others have been added, and a few vulnerabilities removed. Let us take a closer look at these changes.

The Unchanged Categories 

Broken Object Level Authorization (BOLA), Broken Function Level Authorization (BFLA), and Security Misconfigurations are three unchanged OWASP Top 10 API vulnerability categories in the 2023 list. Their position on the list remains unchanged too.

BOLA remains in the #1 position in the OWASP API Top 10 2023 list, as it continues to be a go-to attack vector for threat actors and one of the top security risks facing APIs today. Why is it so?

Object-level authorization mechanisms are complex and diverse. Given the rapid pace of the development environment, developers find it difficult to keep pace and may overlook authorization issues or not inspect and test object access thoroughly. Further, many API frameworks don’t allow good control over authorization.

BFLA and security misconfigurations remain unchanged in their rankings because they are still very popular. They are easily exploitable and offer access to sensitive data and restricted resources with ease.

The New Additions 

Unrestricted Access to Sensitive Business Flows, Server-Side Request Forgery (SSRF), and Unsafe Consumption of APIs are newly added to the OWASP API Top 10 2023.

The new addition, Unrestricted Access to Sensitive Business Flows, has ranked #6 in the OWASP API Top 10 2023 list. This category encompasses various threats that can be effectively mitigated by implementing rate-limiting measures.

SSRF, which made it to the latest OWASP Top 10 web application vulnerabilities list, has also entered the API Top 10 list this year. SSRF is ranked #7 on the 2023 API Top 10 list. SSRF has made it to the list mainly due to the significant increase in SSRF attacks over the years. Why so?

In modern-day IT architectures, a growing number of containerized components communicate over predictable paths using APIs. Developers also tend to access external resources based on user inputs like URL-based file fetching, custom Single Sign-On (SSO), URL previews, etc. While these features boost the functionality of apps, they also make the exploitation of SSRF vulnerabilities easier. SSRF vulnerabilities are dangerous, common, and difficult to mitigate.

The Unsafe Consumption of APIs is the third new entrant into the 2023 list and is ranked #10.

Attackers have shifted their focus towards compromising the integrated services associated with their targets rather than directly targeting the APIs. This changing tactic emphasizes the need to proactively create awareness about the growing risk.

The Categories That Have Been Updated 

Broken User Authentication has been modified into Broken Authentication and still retains its #2 position on the OWASP top ten API 2023 list. This reflects how the category will look beyond user-level authentication flaws and risks. API and microservice authentication flaws, as well as new risks, such as allowing users to change sensitive information without password confirmation and failure to validate the JWT expiration date, have been included in this category.

Broken Object Property Level Authorization, ranked #3 on the latest list, combines Excessive Data Expose (API03:2019) and Mass Assignment (API06:2019). Both vulnerabilities emphasize the need to secure API endpoints properly to prevent unauthorized access and exploitation by threat actors.

Lack of Resources and Rate Limiting has been renamed to Unrestricted Resource Consumption in OWASP API Top 10 2023. Previously, the focus was only on vulnerabilities, but now Unrestricted Resource Consumption also highlights the consequences of not having proper rate limits and other restrictions on resource usage.

Other limits, such as execution timeouts, maximum allowable memory, and the maximum number of processes, have also been included in addition to rate limiting. Together, these limits help ensure the proper functioning of the APIs.

The Categories That Were Removed 

Insufficient Logging and Monitoring and Injections have been removed from the OWASP API Top 10 2023 list.

While API-based applications may still be exposed to generic security risks such as ” Insufficient Logging and Monitoring ” or “Injection,” OWASP API Top 10 objective is to emphasize the importance of special attention to security risks that are particularly relevant to APIs.

It’s crucial to recognize that these generic risks don’t exhibit unique characteristics or exploit vulnerabilities differently in the context of APIs.

The Complete OWASP API Top 10 2023 Risks

API1:2023 Broken Object Level Authorization

BOLA vulnerabilities enable attackers to access data objects (access to which should have been restricted) using unauthorized requests. This leads to the exposure of data objects, and eventually leakage, modification, and destruction of data and other resources.

• Implement fine-grained access controls
• Strong authentication and session management
• Validate and enforce authorization at each access point
• Regular security testing and auditing
• Monitor and log authorization activities
• Keep APIs and libraries updated

API2:2023 Broken Authentication

Broken Authentication is a vulnerability that occurs when the API does not properly authenticate its users, and the application is unable to detect whether the user is legitimate or not. As a result, the attacker can gain partial or full control over the API, app, and its resources. These OWASP API Top 10 2023 vulnerabilities make the API prone to brute force attacks, credential stuffing attacks, etc.

• Implement strong authentication mechanisms
• Secure session management
• Use secure credential storage
• Employ rate limiting and account lockout
• Regularly update and patch authentication libraries
• Perform secure coding practices
• Conduct regular security testing

API3:2023 Broken Object Property Level Authorization

All users need not have access to all object properties. For accessing certain object properties, the user must verify themselves and validate their access permissions. The Broken Object Property Level Authorization vulnerability extends unrestricted access to object properties that should have been restricted. So, attackers can access, modify, add, and delete property values to objects.

• Implement Attribute-Based Access Control (ABAC)
• Validate and sanitize input
• Implement proper authorization checks
• Apply principle of least privilege
• Implement secure object property manipulation
• Monitor and log object property access

API4:2023 Unrestricted Resource Consumption

Resources are at the core of APIs; APIs cannot function without resources. However, the existence of resources also brings a whole range of API security risks since it programmatically exposes resources. Without proper limitations, attackers can overwhelm APIs by sending multiple requests. This leads to the degradation of services, DoS/ DDoS attacks, performance latency issues, crashes, etc.

• Implement Throttling and Rate Limiting
• Implement Quotas and Usage Limits
• Monitor and analyze resource usage
• Implement Caching and Content Delivery Networks (CDNs)
• Implement efficient Algorithms and Data Structures
• Perform Input Validation and Sanitization
• Implement Resource Monitoring and Scaling

API5:2023 Broken Function Level Authorization (BFLA)

APIs use function-level authorization to control access to specific user functions and actions based on their privilege level. It ensures that authorizations, verifications, and permission checks secure each function and action.

Broken Function Level Authorization vulnerabilities arise in APIs when these function-level authorizations fail, enabling attackers to illegitimately access functions and features and perform restricted actions like data/ feature modification or deletion, unauthorized access, privilege escalation attacks, etc.

• Implement granular and fine-grained access controls based on function level authorization.
• Validate and enforce authorization checks for each function or action within the API.
• Regularly review and update authorization rules to reflect changes in user roles or permissions.
• Apply the principle of least privilege by granting users the minimum necessary privileges to perform specific functions.
• Implement secure coding practices to prevent bypassing or tampering with function level authorization.
• Conduct regular security testing, including code reviews and vulnerability assessments, to identify and address any vulnerabilities in function level authorization.
• Monitor and log function level access and activity to detect and respond to unauthorized or suspicious behaviour.

API6:2023 Unrestricted Access to Sensitive Business Flows

Insufficient access restrictions on an API endpoint can lead to a vulnerability where sensitive business flows are exposed. It is crucial to carefully consider the business flows that an API endpoint exposes, as some flows hold more sensitive information that could potentially cause significant harm if accessed without proper restrictions.

• Identify and classify sensitive business flows within the API.
• Implement appropriate access controls and restrictions to ensure only authorized users can access sensitive business flows.
• Utilize role-based access control (RBAC) or attribute-based access control (ABAC) mechanisms to enforce proper authorization for sensitive business flows.
• Regularly review and update access control policies to reflect changes in user roles or permissions.
• Implement secure authentication mechanisms to verify the identity of users accessing sensitive business flows.
• Implement secure session management practices, including session timeouts and secure session tokens, to protect sensitive business flow access.
• Monitor and log access to sensitive business flows to detect and respond to unauthorized or suspicious activity.
• Conduct regular security testing, including penetration testing and code reviews, to identify and address vulnerabilities related to unrestricted access to sensitive business flows.

Explore the API Penetration Testing Checklist, encompassing a detailed list of use cases to test during your API security assessment

API7:2023 Server-Side Request Forgery (SSRF)

Server-Side Request Forgery occurs when APIs process requests from user-controlled URLs and fetch internal/ remote server resources without validating the user request first. So, attackers can access backend servers, including those protected by firewalls, by simply manipulating the URL. They can access sensitive information and engage in other malicious activities.

• Implement strict input validation and sanitization to prevent user-controlled input from being used in server-side requests.
• Whitelist allowed URLs or IP addresses to restrict the destinations of server-side requests.
• Use URL parsing libraries or functions that enforce strict validation and only allow valid URLs.
• Implement proper authentication and authorization mechanisms to ensure that server-side requests are made with appropriate privileges.
• Apply a strong firewall configuration to block outbound requests to untrusted or potentially malicious destinations.
• Use network-level isolation or containerization techniques to limit the impact of a potential SSRF attack.
• Implement URL validation and filtering to block or sanitize potentially malicious URLs.
• Regularly update and patch server-side components and libraries to address known vulnerabilities.
• Monitor and log server-side requests to detect and investigate any suspicious or unauthorized activities.

API8:2023 Security Misconfiguration

Security misconfigurations in APIs occur when security best practices aren’t properly followed and/or the security of the API stack isn’t properly hardened. Some examples of this vulnerability include unapplied latest patches, unwanted exposure of debug logs, unpatched legacy options, unnecessary features/ services, improper implementation of CORS policy, unnecessary enabled HTTP Verbs, etc. Security misconfigurations expose APIs to a whole host of security risks.

• Follow secure configuration best practices for all components of the API, including the web server, application server, database server, and other supporting software.
• Regularly update and patch all software components to ensure they are running the latest secure versions.
• Implement secure default configurations for all components and frameworks used in the API.
• Disable unnecessary features, services, or modules that are not required for the API’s functionality.
• Restrict access permissions and privileges to only those necessary for the API’s operation.
• Implement secure communication protocols, such as TLS/SSL, to encrypt data transmitted over the network.
• Use strong and unique passwords for all system accounts and regularly rotate them.
• Protect sensitive information, such as credentials or API keys, by securely storing them using encryption or secure key management solutions.
• Implement proper error handling and logging mechanisms to prevent sensitive information from being exposed in error messages.
• Regularly perform security assessments, vulnerability scans, and penetration testing to identify and remediate any misconfigurations.
• Keep a secure backup of the API’s configuration settings and regularly test the restoration process to ensure it is working correctly.

API9:2023 Improper Inventory Management

Improper Inventory Management security risk occurs because organizations have multitudes of internal and third-party APIs that are improperly inventoried, documented, and managed. Some examples of these vulnerabilities include multiple versions of APIs being used, exposure of development APIs, improper access control policies, etc.

Improper inventory management exposes APIs, business logic, and resources. The lack of visibility also creates more vulnerabilities, such as security misconfigurations, poor authorization, authentication, etc.

• Implement an inventory management system to track and monitor all API-related assets, including hardware, software, and network components.
• Establish clear processes and responsibilities for managing and maintaining the API inventory.
• Regularly conduct audits to verify the accuracy and completeness of the inventory.
• Implement access controls and restrictions to ensure that only authorized personnel can modify or access the inventory.
• Implement version control and change management practices to track and manage updates, upgrades, and changes to API components.
• Regularly update and patch software components in the inventory to address known vulnerabilities.
• Implement a vulnerability management program to identify and mitigate any vulnerabilities in the API inventory.
• Implement proper documentation and labeling of API assets to ensure easy identification and tracking.
• Regularly review and update inventory records to reflect any additions, removals, or changes to API assets.
• Implement secure backup and disaster recovery procedures to protect the integrity and availability of the API inventory.

API10:2023 Unsafe Consumption of APIs

Developers often trust data received, especially while working with reputed third-party providers and suppliers and deploy less stringent security policies and standards. For instance, they may not restrict permissions, adequately validate data/ inputs, and have lax authentication and authorization policies. Developers leave their APIs and resources vulnerable to breaches and attacks if attackers can hack third-party providers and suppliers.

• Implement strict input validation and sanitization to prevent malicious or unexpected input from being consumed by the API.
• Implement proper authentication and authorization mechanisms to ensure that only authorized users or systems can consume the API.
• Use secure communication protocols, such as TLS/SSL, to encrypt data transmitted between the API and consumers.
• Implement rate limiting and throttling mechanisms to prevent excessive or abusive API consumption.
• Implement proper error handling to provide informative and secure error messages without revealing sensitive information.
• Monitor and log API consumption patterns to detect and respond to abnormal or suspicious behaviour.
• Regularly update and patch the API to address any known security vulnerabilities.
• Conduct regular security assessments and penetration testing to identify and mitigate potential security weaknesses in the API.
• Implement access controls to restrict API access to only trusted and verified consumers.
• Educate API consumers on secure consumption practices and the potential risks associated with unsafe API usage.


The updated OWASP API Top 10 changes highlight the need for organizations to shift towards a more comprehensive approach to API security, and AppTrana’s solutions can help you achieve this goal.

Stay tuned for more relevant and interesting security updates. Follow Indusface on FacebookTwitter, and LinkedIn

AppTrana API Protection

The post What’s New in OWASP API Top 10 2023: The Latest Changes and Enhancements appeared first on Indusface.

*** This is a Security Bloggers Network syndicated blog from Indusface authored by Indusface. Read the original post at: