It’s projected that APIs will account for 90 percent of all cyberattacks in 2022. Despite the growing concerns, many web developers still build APIs without a sufficient focus on security, leaving loopholes that bad actors can use to gain access to your data.

OWASP exists to help developers combat cybercriminals in the digital age.

In this article, you will learn everything you need to know about OWASP and their top 10 API security list.

What Is OWASP?

The Open Web Application Security Project (OWASP) is a highly regarded non-profit organization represented by thousands of members worldwide. The foundation promotes best practices in web application security, codifies industry standards, and produces freely available articles, methodologies, documentation, tools, and technologies to help developers keep their data safe.

What is the OWASP API Security Top 10?

The organization's flagship project is the OWASP Top 10 list, which covers the most dangerous web application vulnerabilities and mitigation strategies currently facing web developers.

The list has been incorporated in many prominent standards, including PCI DSS, the U.S. Defense Information Systems Agency, and the U.S. Federal Trade Commission.

Since 2003, the original Top 10 involved common web application security vulnerabilities, like cross-site scripting (XSS) attacks.

However, the rise of APIs has changed the landscape of vulnerabilities so fundamentally that a new approach was necessary.

In 2019, OWASP added the API Security Top 10 list to the annual reports they maintain. The list serves as a standard awareness document for software development of the security issues they need to address.

Here is a brief overview of the Top 10 Security Threats:

‍

Drilling Down the Current OWASP API Security Top 10 List

The cost of API security breaches goes beyond the financial costs associated with legal battles, fines, and lost customers - a ruined reputation and broken trust with your user base can have long-lasting measures that take years to recover from.

To make sure that doesn’t happen to you, in this section, we will walk you through the current list and cover each of the vulnerabilities in greater detail with some examples.

1. Broken Object Level Authorization

Broken object level authorization (BOLA) vulnerabilities exist when user A can access user B’s data due to errors in the business logic of the application or in the process of authorizing data (or lack thereof).

BOLA is the single most common, and often most serious, vulnerability for APIs.

When a user sends an API request, they try to access one or multiple values (objects). When authorization works correctly, a given user can only access the objects they have been granted access to.

When that's not the case, hackers can modify API calls to act like they are another user and access sensitive data related to that account.

Example: A large delivery provider built an API that allowed an authorized user to access all their shipments, delivery status, and account information. The problem was that even though this API required authentication, with minimal tweaks to the API requests, it was possible to access other user’s data and harvest that information.

2. Broken Authentication

Broken authentication vulnerabilities occur when an API incorrectly verifies the identity of a user, which may result in the exposure of resources, functionalities, or sensitive data to the attacker.

This OWASP vulnerability refers to a lack of authentication at the API layer, authentication methods that use weak password policies, or flawed authentication mechanisms that hackers can exploit.

Some of the broken authentication vulnerabilities that you should guard your API against include:

• Credential stuffing
• Dictionary attacks
• Lack of limits on failed logins

Enabling multi-factor authentication, limits on failed logins, password checking, and enabling certain password complexity requirements are a great way to dramatically reduce the likelihood of successful broken authentication attacks.

Example: A hacker found it was possible to request password resets from a fitness platform via APIs supplying a phone number. The hacker iterated through several potential phone combinations until he found out those that worked. When the app sent a 4-digit password reset code, he brute-forced the codes, gaining access to different accounts.

3. Excessive Data Exposure

Excessive data exposure vulnerability occurs when an API returns more data, fields, and information than the action a user is trying to perform requires.

Many web and mobile apps rely on API calls that return more information to the user than necessary, exposing unfiltered data in direct API calls.

An attacker can take advantage of this vulnerability to find loopholes in the API to gain access to sensitive information.

Example: An electronic payment platform used an API that presented a list of real-time transactions. A hacker discovered that it was possible to call that function directly without authentication and return full transaction details, enabling them to harvest data from over 200 million transactions, including addresses, descriptions, and amounts.

4. Lack of Resources & Rate Limiting

Lack of resources and rate limiting vulnerabilities occur when an API fails to effectively cap the number of requests processed over a given period of time - or whenever there are no rate limits in place at all.

Since all APIs have limited resources, restricting how many requests can be processed by the API as well as how many API calls related to a given user or IP address can be processed within a certain time frame is a must to protect yourself from DDoS and brute-force attacks.

APIs are especially vulnerable to DDoS attacks coming from different IPs that target different API functions and data. Without proper limits and restrictions on the frequency and volume of API requests, cyber attackers can brute-force password requests and harvest user information.

Example: A major social media site allowed users to reset their password using a 6-digit code. The site required the code to be used within 10 minutes and limited guesses to 200 attempts per IP address. However, it did not limit how many different IPs could be used. A hacker found the API for submitting security codes and created a server farm on AWS that brute-forced the combinations in less than 10 minutes, allowing any account to be taken over.

5. Broken Function Level Authorization

Broken function level assignment vulnerabilities occur whenever an API allows a user to use the unintended HTTP methods to access the functional capabilities outside their assigned user privileges.

Every API function, or endpoint, generally supports a range of methods - including PUT, POST, GET, DELETE, and others - and organizations must carefully consider which specific endpoints and methods need to be enabled for users and third parties.

For instance, an API might enable a user to GET their available balance using their banking app. But if the hacker can hijack the API and unlock the PUT method, they manipulate that value the way they want.

Example: A popular dating app enforced several user access and functionality restrictions within the app. However, since the app used a set of APIs to interact with the backend, it was possible for users to change account settings and permissions, enabling them to turn on premium features without paying.

6. Mass Assignment

Mass assignment vulnerabilities occur when the user is able to overwrite server-side variables when it’s not intended by the API by manipulating user-entered data.

With no restrictions to which properties of a given object a user is allowed to modify, bad actors can make edits to the API from outside to grant themselves additional privileges and steal sensitive data.

Example: If an API uses the same endpoint to extract and update user details which include their login, password, and role, the hacker may try to add the role field to the update request, effectively assigning themselves a new user role to break into the API.

7. Security Misconfiguration

Security misconfiguration refers to vulnerabilities that happen due to insecure default settings or replacing the current settings with insecure configuration options.

The default, right-out-of-the-box configurations are publicly known to have vulnerabilities and loopholes, allowing bad actors to easily exploit them.

This may include:

• misconfigured HTTP headers
• unnecessary HTTP methods
• permissive cross-origin resource sharing (CORS)
• active default admin accounts and built-in administration consoles
• error messages containing sensitive information.

To protect your API from this type of vulnerability, go over the default settings and features related and turn off the things you don’t need - because each of them may serve as an entry point for bad actors.

Example: When a user triggers an error, some APIs may redirect that user to an error page that, by default, can be configured in a way that reveals sensitive information about the type and version of the web server you’re using. This removes a lot of guesswork for hackers, giving them ammunition to target the vulnerabilities your web server is known to have.

8. Injection

An injection vulnerability happens whenever an attacker can change database queries to take actions and gain access to the functions they should not have access to, resulting in the unintended execution of commands or unauthorized data access.

This may allow the attacker to bypass authentication, steal database data, alter the site in database contents - or even destroy your database.

Example: On the admin login page, a hacker may write a custom SQL injection that triggers the password value to be set to TRUE, effectively breaking into the admin account without knowing the password.

9. Improper Asset Management

Improper asset management vulnerability happens whenever attackers are able to exploit obsolete, incomplete, or undocumented API functionalities by accessing the outdated or staging versions of the current API.

This is more of a human error and usually occurs when these versions remain connected to the data source used by the current API.

Example: Developers working on the staging API may forget to decommission the outdated tools previously used in the development process. Hackers may take advantage of that to break into the current API by exploiting the vulnerability on the staging API if both of them are connected to the same data source.

10. Insufficient Logging & Monitoring

Insufficient logging and monitoring vulnerabilities happen because there’s a lack of recording information about auditable events - from failed logins to high-value transactions - that happened inside an API.

This group of vulnerabilities can cover a myriad of security issues, including:

• Alerts resulting in inaccurate or no log messages
• Insufficient logging of auditable events
• Penetration tests failing to trigger alerts
• Inaccurate warnings that don’t trigger alerts when an active attack takes place

Without logging and monitoring, if an attacker breaks into your API, chances are, they will stay under the radar and get away with committing a crime.

Additionally, APIs with insufficient logging are also harder to debug because some of the issues will fall under the radar.

Example: If the alert is triggered only when several consecutive attempts to log in are made, the hacker can spread their efforts across multiple accounts and wait for the login counter to reset to keep on picking passwords without triggering any security alarms.

How You Can Test Your API to Protect Against Cyber Attacks

API vulnerabilities are common and dangerous - with most of them being hard and costly to identify

Security experts have sought to address the problem with a two-pronged approach: adding automated code auditing tools to their continuous integration pipelines and scheduling periodic manual penetration testing by experienced “white hat” security professionals.

Manual Testing

Manual penetration testing entails performing manual tests and simulations of cyberattacks to identify API security vulnerabilities.

Manual penetration testing complements other forms of security measures but has serious limitations that prevent it from being as a complete, one-size-fits-all solution to application security, including:

• It’s challenging to test all permutations of each API endpoint, especially as the inventory of API resources grows.
• Manual pen testing is limited to the experience of the security professionals involved, and this group is in high demand and expensive.
• Business logic errors make up four of the top five OWASP attack vectors. At the same time, they are not being fully addressed by existing security testing workflows.
• Manual pen testing is slow and gets increasingly more difficult to implement as you scale.

Additionally, your API can be potentially attacked at any moment and needs to be fully audited every time you roll out an update, whereas manual testing is typically done just a few times per year.

So while manual penetration testing may help uncover some OWASP vulnerabilities, this option tends to be more costly and less effective than automated testing.

Automated Testing

In contrast, automated penetration testing provides a comprehensive toolset to continuously check your API for any vulnerabilities while completely eliminating human error.

Such an approach enables full coverage of the entire breadth of a company’s API inventory and methods, generating test cases for all endpoints and methods offered - numbering in thousands to tens of thousands of individual tests.

Even with granular tests and comprehensive coverage of your entire API footprint, automated testing does its work quickly, running in minutes rather than adding hours or days to your integration and deployment workflow.

Automated static code analysis tools identify narrow and specific flaws in an API. They can include linting standards for code formatting and checking dependencies for published vulnerabilities.

Additionally, they can help measure the quality of a codebase against KPIs, such as the percentage of code covered by test cases. But the static analysis doesn’t reach into the types of business logic errors responsible for most API breaches.

Keep Your API Safe with APIsec

With so many cyber threats, it’s important to use cutting-edge tools to implement world-class API security.

APIsec offers an automated API testing platform built on the expertise of security professionals carrying out manual pen tests, enabling comprehensive coverage of the entire breadth of a company’s API inventory and methods.

APIsec provides ten times the coverage of manual pen-testing at one-tenth the cost while addressing the most common API attack vector traditional security techniques struggle to tackle: the business logic that powers APIs.

Any identified issues can be fed to trouble ticketing systems, and pen-test reports suitable for submission to auditors and compliance officers get automatically generated. Additionally, an easy-to-use dashboard is also available for visualizing and managing changes to an API over time.

Learn more about how APIsec delivers continuous API security, with complete test coverage, that operates at CI/CD speed here.