OWASP API Top 10

API security is not optional—it’s a necessity. Compromised APIs can expose sensitive information, leading to data breaches, unauthorized access, and financial loss. Gartner predicted that API abuse and related data breaches would nearly double by 2024, which aligns with the alarming rate of API attacks observed recently. For instance, in 2022, the cryptocurrency trading company 3Commas suffered a $22 million loss when hackers exploited vulnerabilities and gained unauthorized access to API keys. The same year, Optus, a telecom giant, faced a highly publicized API breach that compromised 11.2 million customer records and resulted in over $140 million in damages.

The OWASP API Security Project is a leading resource for API security. The Open Worldwide Application Security Project (OWASP) is a nonprofit organization dedicated to enhancing software security through community projects, education, and awareness. It published the first edition of the OWASP API Security Top 10 in 2019 and released an updated list in 2023 to reflect changes in the API threat landscape, incorporating community feedback and reordering the rankings based on severity and frequency.

This article provides an overview of the latest version of the OWASP API Top 10, discusses each risk, and provides tips on testing each risk and implementing best practices for attack prevention.

Summary of the OWASP API Top 10

This table summarizes the 2019 and 2023 versions of the OWASP API Security Top 10. In the following sections, we will take a closer look at the changes.

Unchanged risks

API1:2023 - Broken Object Level Authorization (BOLA)

Authorization remains the biggest challenge in API security, so it is no surprise that BOLA remains the top security risk in the 2023 edition, indicating its severity and prevalence. An API responsible for managing objects is vulnerable to BOLA when an attacker gains unauthorized access by manipulating the object ID sent within the request. Object IDs can be anything from sequential integers or generic strings such as /userID, /vehicleNumber, or /shopName.

Let’s take a look at an example. Assume that we have an API that allows users to retrieve their health records based on user ID.

GET /api/v3/patient-record/user_id
Host: https://api.example.com
User-Agent: User Machine

The user_id in the URL above is the object identifier unique to each user. To test for BOLA, a security tester could try to access the records of another user by changing the user_id in the request URL and seeing if the API performs proper authorization checks.

GET /api/v3/patient-record/1026
Host: https://api.example.com
User-Agent: Attacker Machine

Successful exploitation of this vulnerability can result in disclosing sensitive data, data manipulation, or, in extreme cases, account takeover.

It is essential to implement strong authorization controls at the object layer, ensuring that users only have access to the resources and actions they are authorized to use. Proper access control mechanisms, such as role-based access control (RBAC), can help prevent BOLA issues and enhance the security of your API. Regular security assessments and testing of your APIs are also crucial to identify and address these vulnerabilities.

API5:2023 - Broken Function Level Authorization (BFLA)

This threat has retained its position on the list since 2019 and should not be confused with API1:2023. A key point here is the term “function level”: This vulnerability arises when an application does not validate user permissions before allowing access to specific endpoints, potentially compromising the system’s integrity and security.

Let’s look at an example of an application with an administrative API endpoint /api/v3/changeUserRole. To test for BFLA, a security tester with a regular role could try to send a modified request to change their role to admin using the API endpoint and observe if the API performs proper authorization checks:

GET /api/v3/changeUserRole?newRole=admin
Host: https://api.example.com
User-Agent: Attacker Machine

Successful exploitation could cause system compromise, financial loss, service disruption, reputation damage, or data breaches.

Developers should consider the type of function or endpoint, the action performed, and the user’s role and scope when implementing proper authorization checks.

API8:2023 - Security Misconfiguration

This threat moves one spot down from its #7 position in the 2019 list. It has been updated to reflect new attack vectors that have emerged, expanding the scope to include configuration issues such as insecure API keys, tokens, secrets, lack of encryption or hashing, and improper error handling or logging.

Depending on the issue’s type and severity, this vulnerability can expose sensitive data, cause data manipulation or service disruption, and, in some cases, expose system details that can lead to full server compromise.

Security testers should use API security solutions to scan and identify security misconfiguration issues in applications, such as unpatched flaws, standard endpoints, services running with insecure default configurations, or insecure API keys.

There is no one-size-fits-all approach for preventing security misconfiguration, but developers can follow best practices, including the following:

• Ensure that all API communications happen over an encrypted communication channel.
• Define and enforce all API response payload schemas, including error responses.
• Repeatedly review and update configurations across the API stack.

{{banner-small-1="/design-banners"}}

Redefined risks

API2:2023 - Broken Authentication

Broken User Authentication was #2 in the 2019 OWASP API Top 10 list and retains its #2 position on the 2023 version. However, it has been renamed to Broken Authentication to cover a broader range of issues, including problems with machine authentication, session management, and other non-user-specific authentication mechanisms.

Broken authentication occurs when an API implements authentication mechanisms incorrectly, allowing attackers to compromise authentication tokens or exploit implementation vulnerabilities to impersonate other users temporarily or permanently. The impact of this risk depends on the privileges and data associated with the compromised or impersonated user accounts: The consequences can potentially include unauthorized access, data breaches, identity theft, financial loss, reputational damage, and even secondary attacks.

Let’s take an example of an incorrectly implemented API that allows unauthenticated requests to change a customer’s email address. An attacker performs reconnaissance to gather a list of customer usernames and crafts a POST request for changing the customer’s email address.

POST /api/change_email
Host: https://api.example.com
Content-Type: application/json

{
  "username": "target_customer_username",
  "new_email": "attacker@example.com"
}

Since the API does not require authentication, the attacker can freely ask to change the email addresses of specific customers. The attacker can then initiate a password reset using the new email address to complete the account takeover.

POST /api/reset_password
Host: https://api.example.com
Content-Type: application/json

{
  "email": "attacker@example.com"
}

To test for broken authentication, a security tester could check for common implementation flaws, such as these:

• APIs that allow unauthenticated requests
• Weak passwords
• Insecure password recovery mechanisms
• A lack of multi-factor authentication

Proper authentication mechanisms should be implemented to prevent this risk, following security best practices and standards. For starters, the authentication mechanisms should use robust encryption algorithms, enforce password policies, and implement multi-factor authentication. Additionally, the API should use secure and short-lived authentication tokens, such as JWTs or OAuth tokens, instead of cookies or sessions.

API4:2023 - Unrestricted Resource Consumption

Unrestricted Resource Consumption has been redefined from API4:2019 Lack of Resources & Rate Limiting to highlight the importance of managing resources rather than limiting access, moving the focus from the reasons behind resource limitations to the consequences of unregulated resource consumption.

There are several root causes for this vulnerability, but at the core is the failure to limit the size or quantity of resources a client can request or the number of requests they can make in a given timeframe. Excessive use of API resources could exhaust server-side resources, causing the API to slow down or crash or increase operating costs.

Developers should follow best practices specific to resource limiting, such as defining the maximum data size on all incoming payloads and deploying advanced API security solutions that block attacks. They should also use behavioral rate-limiting to identify and limit abnormal behaviors.

API9:2023 - Improper Inventory Management

While maintaining the same spot in the 2019 list, OWASP renamed this risk to increase its scope. The term “assets” was used in 2019 to refer to hosts, deployed API versions, and API endpoints documentation; the 2023 edition uses “inventory” to emphasize that the issue is not about managing assets alone but maintaining inventory. In essence, the scope is no longer limited to securing the assets of an API, such as its code, data, and infrastructure, but maintaining an accurate inventory of all elements of APIs, including hosts, environments, access methods, documentation, and version information.

A security tester could try to access or exploit deprecated API versions or debug endpoints, which may have different URLs or headers than the current version, and see if the API redirects or blocks them. Proper inventory management ensures that all hosts and API versions are regularly documented, tracked, and updated. Organizations should also consider implementing an automated solution that uses efficient inventory mechanisms, such as versioning and deprecation.

New risks

API3:2023 - Broken Object Property Level Authorization (BOPLA)

Broken Object Property Level Authorization (BOPLA) is a new addition and merger of two previous vulnerabilities: API3:2019 - Excessive Data Exposure and API6:2019 - Mass Assignment. OWASP included this new category to address the root cause of these two vulnerabilities: inadequate authorization at the object property level.

BOPLA is a vulnerability that arises when an API endpoint exposes or allows the manipulation of the properties of sensitive objects without performing adequate authorization checks, resulting in the disclosure of sensitive data, data loss, privilege escalation, or account takeover.

Let’s take a look at an example. Assume that we have an application that allows users to conduct transactions only when their addresses are verified. Users are allowed to change their addresses even when they are not yet verified using the following API request:

PUT /api/v3/updateAddress

{
  “address”: “123 API Street, Impart Avenue”
}

An attacker can attempt to update the address and add the following malicious payload:

{
	"address": "123 API Street, Impart Avenue",
	"verified": "true"
}

Because there is no validation that the user should have access to the internal object property verified, the user can change the value to true, unlocking the account and enabling unauthorized transactions.

When implementing authorization logic, it is essential to follow authorization implementation best practices, such as these:

• Implement the principle of least privilege to restrict users to the minimum level of access required.
• Implement a “deny-by-default” approach to reduce the risk of unauthorized access.
• Perform thorough permission checks on every API request.

In addition to these, developers should consider the documented authorization cheat sheets to prevent exploitation of this vulnerability.

{{banner-small-2="/design-banners"}}

API6:2023 - Unrestricted Access to Sensitive Business Flows

This new addition ranks #6 in the OWASP API Top 10 2023 list. This risk occurs when an API exposes 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.

The impact of this risk depends on the type and sensitivity of the business flow abused by the attacker. For example, suppose a company’s website announces that it will be selling tickets to a famous concert. On the day of the sale, an attacker could write a script to automatically buy 90% of the tickets, forcing legitimate users to buy them at an inflated price.

To prevent this vulnerability, API developers and security engineers must proactively identify potential business processes that could threaten the company if exploited. They can then implement appropriate protective measures to mitigate these risks, including constantly monitoring API calls/usage to flag non-human patterns.

API7:2023 - Server Side Request Forgery

Server Side Request Forgery (SSRF) is a security risk ranking #7 on the 2023 API Top 10 list. SSRF involves inserting a malicious URL into an API request, and the vulnerability occurs when the API fetches the remote resource without validating the user-supplied inputs. An attacker could forge a request to a malicious or compromised service that returns malicious content, such as malware, phishing pages, or exploit code, causing system compromise, a data breach, or service disruption.

Imagine an application allowing users to upload profile pictures by providing the image’s URL. The API call could look like this:

POST /api/v3/profile/upload_picture
{
	"url": "https://api.example.com/profile-picture.png"
}

To test for SSRF, a security tester can send a benign URL to download a file to the internal network using the API endpoint and observe how the endpoint and internal systems behave.

{
	"url": "https://link.to.benign.file/execute-malware.c"
}

The development team should follow the OWASP SSRF cheat sheet to prevent exploitation of this vulnerability. Some important actions include the following:

• Validate and sanitize all user-supplied inputs.
• Use secure and isolated request mechanisms, such as firewalls, to prevent unauthorized access to internal resources.
• Where possible, use an allow-list of permitted redirects or accesses.

API10:2023 - Unsafe Consumption of APIs

Modern applications are mostly interconnected with external or third-party APIs, consuming inputs from them. Unfortunately, most developers trust data from these third parties unquestioningly. This risk occurs when an API consumer does not validate the data or functionality provided by the third-party API, allowing attackers to compromise the consumer’s system or data.

Successful exploitation may lead to exposure of sensitive data to unauthorized actors, injection attacks, or denial of service. A relevant security incident is the Log4Shell attack, which allowed attackers to remotely execute malicious code on web services using the Log4j library.

To prevent this vulnerability, developers should follow recommended best practices, including these:

• Assess the API security posture of external service providers.
• Sanitize and validate data returned by external APIs.
• Use a secure communication channel for all API interactions.

{{banner-large-white="/design-banners"}}

Conclusion

In this article, we delved into the details of the OSAWP API Top 10 security risks, exploring their definitions, impacts, common causes, and real-world examples. We also discussed best practices and recommendations for testing and preventing each risk. By prioritizing API security, you protect your digital assets and enhance your users’ trust and confidence.

Contact Impart Security at try.imp.art for more API security tips and best practices and be sure to follow us on LinkedIn for the latest product news and updates.

‍