OWASP API Security Top 10 Risks

When trying to build better API security, it can be challenging to know where to start. Your team might be wondering what counts as a “critical” versus “noncritical” vulnerability, and which tools to implement to mitigate the most severe risks impacting backend applications (aka servers) and other API-powered systems.

The cybersecurity industry, as a whole, responds to these questions by creating frameworks that give research-based insights on which risks to prioritize and how to respond to them. And one of the recent developments is a framework for securing your APIs is the OWASP API Top 10.

OWASP API Top 10 Defined

The OWASP foundation has been providing security recommendations to organizations for over a decade now. Their most well-known effort is the OWASP Top 10 project, which has been around since 2003, and recently updated for 2021.

In 2019, the first OWASP API security list was released. OWASP chose to release this list because they recognized the importance of APIs and their growing risk in impacting the security posture of today’s mobile, SaaS, and web-based applications.

Why should you use the OWASP API Security Top 10?

Today’s software companies cannot innovate without APIs. They form the foundation of countless applications, by enabling them to easily integrate and share data and functionality with other entities — such as third parties and other internal development teams. So, the very essence of an API is the ability to easily exchange data and provide interoperability. But unfortunately, this also means that it is simple for an attacker to expose the application logic and sensitive data delivered by an API. And since these APIs are often publicly available, the risk of consumption by malicious actors is paramount.

Web application security vs API Security

Why did OWASP need to release a separate list of the top 10 vulnerabilities for APIs? Because APIs and web applications, while often reliant on each other, are distinctly different technologies and can introduce different types of risk.

Web application security

Traditional web applications mainly contain entry points in two places — the client side and the server side. The biggest threats to web apps generally have to do with weaknesses in either of these two categories.

Two examples of the OWASP Top 10 vulnerabilities in applications include broken access control, which means that the server can be accessed by unauthorized personnel, and cryptographic failures, which means that data within the server is not properly encrypted.

As we can see, both of these types of risks are directly related to the server. This is because web apps have a limited number of entry points — the data gets processed on the server side, the web page is rendered in the client browser, the user sends a request back, and it reaches the server again. It’s a simple, two-way street and while bad actors can tamper with any part of this process, there are limited entry points.

API Security

APIs, on the other hand, offer a potentially vast attack surface because they expose many API endpoints that bad actors can use to access sensitive data. Components within a single app operate with individual APIs that send and receive data from servers. One application can contain numerous client-facing entry points, all of which can be leveraged by an attacker.

And as we mentioned earlier, the very nature of APIs is to expose data. When this works as it should, APIs make applications far more efficient because they can “talk” to other applications and databases. But unfortunately, this nature also makes API security risks particularly detrimental to the companies that use them.

OWASP API Security Top 10 Explained

The OWASP API Security list ranks the top vulnerabilities that are most likely to compromise your application server's security. It provides excellent direction for your teams as you consider solutions and services to bolster your API security and create a better end-to-end security posture for your entire organization.

Here's the full list, you can use this to skip to each section:

1. Broken object-level authorization

2. Broken user authentication

3. Excessive data exposure

4. Lack of resources & rate limiting

5. Broken function-level authorization

6. Mass assignment

7. Security misconfiguration

8. Injection

9. Improper asset management

10. Insufficient logging & monitoring

#1: Broken object-level authorization

APIs use object-level authorization to ensure that only the right users can access the data being delivered by that API. If this access control mechanism is broken, attackers can use the API to disclose, change, or destroy data that they don’t own or shouldn’t have access to.

#2: Broken user authentication

User authentication endpoints and flows are considered broken if the API fails to use adequate security mechanisms — such as strong encryption keys, password stuffing prevention, or strongly hashed passwords. If a developer fails to rotate keys or set up token authentication, attackers can obtain access to someone else’s credentials and use them to access the APIs.

For example, GitLab has several versions of its software that aren’t performing correct authorizations on scheduled pipelines. This vulnerability could allow a malicious user to run a pipeline in the context of another user.

#3: Excessive data exposure

This vulnerability occurs when an API provides more information than it should, which attackers can leverage. his type of data exposure is common because developers often generically implement APIs without limiting endpoints. Instead, they need to be very intentional about which API endpoints they are choosing to expose and, by default, filter out the rest.

An example of this is in Moodle, a learning platform. Moodle has a table download functionality that includes user emails in the table even when they’ve been hidden. This vulnerability can be fixed with a simple upgrade.

#4: Lack of resources & rate limiting

When development teams fail to put limits on the size or number of resources that a client is allowed to request, vulnerabilities arise. Attackers can use brute force or Denial of Service attacks when they have unlimited “retries” to perform the right request.

`express-brute` middleware, for example, has a package that is vulnerable to Rate Limiting Bypass. Incorrectly counting the number of requests sent allows an attacker to bypass the rate-limiting mechanism.

#5: Broken function-level authorization

When an access control system is set up incorrectly, attackers can gain unauthorized access to the API endpoints and use their new privileges to exploit them.

`github.com/matrix-org/gomatrixserverlib`, a Go library for common functions needed by matrix servers, has a package version where the power level parsing function can fail — causing events to either be incorrectly authorized or rejected by Dendrite servers. This vulnerability can leave organizations open to a Denial of Service (DoS) attack.

#6: Mass assignment

This vulnerability occurs when an API binds client-provided data to data models. It makes it possible for a malicious client to modify object properties simply by tampering with client-facing fields.

An example of this is laravel/framework, a web application framework. Affected versions of this package are vulnerable to Mass Assignment when not using the `fillable` property on models.

#7: Security misconfiguration

This category covers vulnerabilities that occurred because security configurations were not correctly put into place. Some examples of security misconfigurations that could affect an API are:

• Missing security patches

• Unnecessary features that are turned on

• The system does not use Transport Layer Security (TLS) or a Cross-Origin Resource Sharing (CORS) policy

• Error messages expose sensitive information

`typo3/cms`, a free open source Content Management Framework, has several versions that are vulnerable to a security misconfiguration that can lead to an account with empty credentials. This weakness could be exploited by a backend user with the right access privileges.

#8: Injection

Bad actors perform injection attacks by sending malicious data into the system via the API layer. This can impact APIs when they fail to validate or sanitize data. `simple-git`, for example, is vulnerable to command injection via argument injection in versions 3.3.0 and lower. By injecting some git options, it was possible to get arbitrary command execution.

 #9: Improper asset management

Teams must take efforts to understand the purpose and makeup of each API and document this information thoroughly. Otherwise, they could fail to update, repair, or retire their APIs when necessary. An outdated API is far more vulnerable to attacks than an up-to-date one.

#10: Insufficient logging & monitoring

When a security team doesn’t have proper logging and monitoring in place, an attacker could make repeated attempts to get into their systems without the security team’s awareness.

Two steps to strengthen your API security

As your team considers the OWASP Top 10 API risks, there are two steps that you can take to address potential security gaps — scan for vulnerabilities and educate your team about API risks.

Scanning for API vulnerabilities

Security teams must regularly scan for API vulnerabilities, using technology to assess their backend API code, locate risks, and remediate them. Using a known vulnerable project as a practice run for your team’s scanning techniques is a productive way to ensure these activities are effective. These projects are available from a variety of resources, including OWASP. 

How to scan for API vulnerabilities

Snyk offers a variety of resources that can help your team run API security scans. Snyk Code is a great way to scan your backend API code and find issues of Injection, Broken User Authentication, Excessive Data Exposure, and other security issues. Snyk IAC can help you find security misconfigurations (OWASP API Risk #7) as you configure your infrastructure to deploy your containers or serverless functions to the cloud.

Educate your team about OWASP API Top 10 vulnerabilities

Teams also need to have actionable knowledge about the OWASP Top 10. By truly understanding what causes each type of vulnerability, they will be less likely to contribute to any of these risks and more willing to help remediate them.

In addition to providing learning opportunities around common vulnerabilities, your organization also needs to create strong security policies and empower your developers to implement them with hands-on training. Snyk Learn offers helpful education about a variety of security topics, including API vulnerabilities. By truly comprehending security best practices, developers can help improve your overall security posture through secure coding, better buy-in, and faster remediation.

How Snyk Helps with API Security

Snyk not only provides resources to help organizations run more secure APIs — we also offer application and cloud security solutions. In addition, we give teams educational resources based on common vulnerabilities within various languages and frameworks, such as Java.

Our goal is to provide developer-friendly, shift-left resources that secure your entire software development lifecycle (SDLC) without compromising agility. Reach out and schedule your demo today.