OWASP Top 10 API Security Vulnerabilities | Curity (2024)

Many threats face modern software applications. It’s smart to keep updated on the latest exploits and security vulnerabilities; having benchmarks for such vulnerabilities is paramount to ensure application security before an attack occurs.

The Open Web Application Security Project (OWASP) is a trusted nonprofit foundation that publishes software security analysis. The group is well-known for its yearly roundup of top web application vulnerabilities. Since 2019, they also release an API security vulnerabilities list as well.

As the value of APIs increases in our daily lives, these touchpoints become more vulnerable to attack. Below, we highlight the latest OWASP top 10 API security vulnerabilities list for 2023, and expand on what actions API providers can take to address each insecurity.

These actions boil down to a few basic security strategies. We’ll see that most of these vulnerabilities can be mitigated by implementing the following approaches:

• Use an API gateway.
• Use access tokens and make sure to audit them rigorously.
• Use claims to simplify authorization. If the token has enough data to authorize on, then the logic becomes simpler in the API.
• Use PPID ( Pairwise Pseudonym Identifiers ) to avoid leaking personally identifiable information to external parties, even in the tokens.

1. Broken Object Level Authorization (BOLA)

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. - OWASP

Since APIs enable access to objects, if authorization is broken there is a wide attack area. Thus, authorization to API-accessible objects must be secured.

Solution: Use an API gateway and implement object-level authorization checks. Require access tokens to permit access, and only allow access to those with the proper authorization credentials.

2. Broken User Authentication (BUA)

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. - OWASP

Another common API vulnerability is the use of illegitimate tokens to gain access to endpoints. Authentication systems themselves may be compromised, or expose an API key accidentally. Attacks can exploit such authentication tokens to gain access.

Solution: Secure user authentication, and only ensure trusted users are authenticated. Go beyond simple API keys with OAuth flows. Always consider the type of access. If it’s machine to machine access, consider adding additional layers of security such as Mutual TLS together with OAuth MTLS Sender Constrained Tokens to ensure that clients don’t misbehave and pass tokens to the wrong party.

3. Broken Object Property Level Authorization (BOPLA)

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. - OWASP

It’s easy to publish a suite of endpoints without itemized restrictions. More often than not, however, not all functions apply to all users. The more data you unnecessarily expose, the more you unnecessarily place yourself at risk.

Solution: As a rule of thumb, limit data exposure to only trusted parties who need it. Ensure what is returned is only accessible by those with correct privileges. Limit API response payloads to reduce exposure. By using OAuth Scopes and Claims, developers can delineate exactly who is eligible to access what. Claims can contain details about what parts of the data should be allowed to access. As an added benefit, the API code becomes simpler and more maintainable when access control is structured the same way in all APIs.

4. 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. - OWASP

See Also

4 API Authentication Methods for a Secure REST APIKeep API Keys Safe, Because The Repercussions Are Huge | Nordic APIs |

DoS attacks are a common brute force method used by black hats to overload a server and effectively snuff out a server’s uptime. If an API has no set limitations on the number of resources that can be called, it is wide open to a detrimental attack.

Solution: Put rate limits on APIs using an API gateway or management solution. Put restrictions on responses, and implement things like filtering and pagination.

5. Broken Function Level Authorization (BFLA)

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. - OWASP

OWASP highlights a common pain point for software developers: access control is difficult to implement properly. Teams working on in-house solutions rarely get it right. Exact administrative levels must be consistently defined across a platform and must accurately reflect organizational hierarchies.

Solutions: Adopt OpenID Connect to help standardize user identity creation and maintenance. Avoid in-house development, and outsource access management systems to specialized tooling. Developers can also mitigate this vulnerability by adopting Scopes and Claims. By baking such criteria into an OAuth process, API providers create more user-specific access restrictions that tie identity to the requesting party. This enables more confirmed validated assertions. Also, Claims simplify the implementation of the API. Since the token carries more data, the API simply has to look and see, is Alice allowed to do Action 1?

6. 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. - OWASP

An attacker who authenticates and calls an API in an automated manner could gain ownership of many business resources, and prevent other users from accessing them.

Solutions: Act like a hacker to think through threats to the business. For such endpoints, use authorization rules to prevent users from creating too many resources within a time period. Use multi-factor authentication before allowing API access, to ensure human interaction, and to prevent unauthorized API access from scripts.

7. 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. - OWASP

This highlights that any input to APIs must be treated with care, and considered dangerous until proven otherwise. Even when a valid API access token is provided, a malicious user should not be able to trick the API into calling untrusted locations. Using even a cheap VPN can help mask an attacker's true location, making it even more difficult to trace such malicious activities.

Solutions: Base solutions on OAuth and OpenID Connect designs, where most URIs are configured in backend components. When user-supplied URIs such as callback endpoints are supplied, they are validated against a whitelist.

8. 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.

This guideline by OWASP is rather all-encompassing, as the chance for security misconfiguration is high. Many little details could put your platform at risk. For example, returning sensitive information from malformed requests could be eye-opening for black hats with ulterior motives.

Solutions: A general takeaway here is not to rely on default configurations. Check with your management or gateway provider and ensure they cater to your specific application requirements. Do not insert sensitive information in error messages. Also, use Pairwise Pseudonyms in tokens to not leak identity data outside the system. This way, no client can collude with another client to figure out who a user is.

9. 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. - OWASP

It is important to keep versions and documentation up-to-date; not only for the sake of developer experience but for your security as well.

Solutions: Plan your versions and API deprecation timelines ahead of the release. Do not let old API versions continue to function. Synchronize documentation with live API endpoints and consider using an API Specification as a source of truth.

10. Unsafe Composition 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

A compromised third-party API could potentially provide dangerous input to your API, such as malicious strings that lead to unexpected actions later. An example is a specially constructed string that results in SQL injection, to return unauthorized data to an attacker.

Solutions: Always use an API Gateway. Do not allow SQL and untrusted data types as accepted data formats. Monitor API requests from trusted parties for unusual behavior. Another option is to temporarily suspend accounts that make strange requests.

What Are The Implications for Identity Control?

Following common vulnerability benchmarks helps platform architects arm systems to stay one step ahead of API security threats. Since APIs can allow access to Personally Identifiable Information (PII), ensuring security for such services is paramount for not only business stability, but to meet regulations like GDPR.

What’s interesting is that the top issues on OWASP’s list involve the improper use of identity — or the absence of an identity strategy altogether. A better identity emphasis won’t solve every issue here, but developing with identity in mind, and having ample evidence to prove assertions, is critical for ensuring data requesters have the proper authority.

Thankfully, providers using OAuth and OpenID Connect can delegate identity, utilizing Scopes and Claims to enable a platform-wide trust. To avoid OWASP’s vulnerability list, always use an API Gateway combined with the Phantom Token Approach for OAuth tokens.

Published: 2020-05-05Updated: 2023-06-13

Curity