Top 10 API Security Vulnerabilities According to OWASP

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 . In 2019, they released 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 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

*“APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. Object-level authorization checks should be considered in every function that accesses a data source using an input 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

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 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. Excessive Data Exposure

Developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user. - 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. 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. Lack of Resources & Rate Limiting

Quite often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only can this impact the API server performance, leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force. - OWASP

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

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 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. Mass Assignment

Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on a whitelist, usually lead to Mass Assignment. Either guessing object properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads, allows attackers to modify object properties they are not supposed to. - OWASP

Just because an endpoint isn’t publicly documented does not mean developers can’t access it. Hackers can easily intercept requests and reverse-engineer a private API. Just take this simple walkthrough which leverages an open Bearer Token in a “private” API. Conversely, public documentation may exist for something that is only intended for private consumption. Black hats can utilize exposed information to not only read but modify object properties.

Solutions: Act like a hacker to find vulnerabilities. Ensure what is returned is only accessible by those with correct privileges. Limit API response package to reduce exposure. Do not include unnecessary links in responses.

7. Security Misconfiguration

Security misconfiguration is commonly a result of insecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information. - OWASP

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.

8. Injection

Injection flaws, such as SQL, NoSQL, Command Injection, etc., occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization. - OWASP

Not only are APIs prone to injection, but third-party developer applications may be prone to injection as well. Such malicious code may initiate commands to erase data, or harvest valuable private records.

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.

9. Improper Assets Management

APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. Proper hosts and deployed API versions inventory also play an important role 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. Insufficient Logging & Monitoring

Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems to tamper with, extract, or destroy data. Most breach studies demonstrate the time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring. - OWASP

When an attack does occur, teams need an efficient response plan. Lacking a consistent logging and monitoring system means developers will continue to exploit vulnerabilities undetected, heightening losses and decreasing public image.

Solutions: Adopt rigorous API monitoring and testing of production endpoints. Consider a bounty program to award white hat testers who spot vulnerabilities early on. Ingrain identity into API transactions to improve the log trail. Use Access Token data for auditing, and make sure to capture audit trails on all levels in your API infrastructure.

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.