API Attack Types & Vulnerabilities: Complete Guide

Today, Application Programming Interfaces (APIs) are essential in running any business and organization. Every day, developers deploy applications and systems that rely heavily on APIs for successful operations and service delivery. A study published in 2019 by Akamai showed that 83% of web traffic comes from APIs. Unfortunately, this vast reliance on APIs comes at a cost. Although API usage has led to the development of robust and complex applications that improve business use and performance, poor APIs implementation can open a system to common API vulnerabilities. Hackers can then exploit these vulnerabilities, which might lead to data loss, reputation loss, and, eventually, economic loss.

Why is API security important?

As applications become more complex and robust, hackers focus more on exploiting insecure and misconfigured APIs. An API attack is much more lethal as it exposes organizations' private information and the underlying system functionalities. According to a study by Verizon, 90% of all hacking attempts target web applications. Since more web apps are adopting APIs daily, APIs have also become one of the primary and most critical attack vectors. Additionally, since API implementations rely on existing web technologies, APIs are also vulnerable to popular web vulnerabilities. However, due to the general nature of APIs, they further extend the attack surface, escalating the cost of the attack on a business. That’s because most APIs have a flexible channel to the backend. An exploited API can reveal much more information with devastating financial consequences.

Common API Attack Types & Vulnerabilities

These vulnerabilities are pretty common in web-based systems. Developers and security experts should focus more on these kinds of API attacks as they often lead to data loss and other adverse effects like financial costs. This section will look at some of the common API attack types and also give you a solution for every attack. Some of these vulnerabilities are listed in the Open Web Application Security Project (OWASP) Top 10 API vulnerabilities. However, you will notice that you can mitigate most of these API attacks by implementing the following approaches.

• Use an API gateway.
• Use API tokens for authorization.
• Use API Claims to simplify authorization access.
• Use Pairwise Pseudonymous Identifiers (PPID) to avoid leaking Personally Identifiable Information even through tokens.

1. Broken Object Level Authorization (BOLA)

Broken Object Level Authorization (BOLA), also called Insecure Object Level Reference, is one of the most common API vulnerabilities. This API attack was listed in position one in OWASP's top 10 API vulnerability list. A BOLA API hacking attack occurs when the server does not properly check a user (either logged in or not) has the permission to access a particular resource using the API. For example, can they update, delete or read an object which they don’t have access to? Below is a simple example describing the exploitation of Broken Object Level Authorization.

 Normally, an authenticated user will send a request to the server requesting a “Record_A,” and the server will respond with the requested resource (Record_A in this case) to the API caller. In BOLA exploitation, an attacker or a malicious user (maybe an insider threat) will try to manipulate the request to try and  access a different piece of data- say “Record_B.” This method of API hacking mainly occurs when the server is not verifying authorization levels correctly. Unfortunately, BOLA vulnerabilities frequently occur in complex architectures, as it can be hard to enforce authorization across an entire system. One of the significant problems with this attack is that attackers can perform privilege escalation.

Mitigation recommendations:

• Use UUIDs (Universally Unique Identifiers). It is best to avoid auto-incrementing identifiers
• Enforce authorization mechanisms. Securing your APIs from BOLA attacks requires correct authentication and robust authorization mechanisms. As the illustration above shows, a correctly authenticated user can also perform a  BOLA exploitation.
• Rigorous testing of business logic.

2. Broken User Authentication.

Broken User Authentication is a common term in the OWASP Top 10. In this type of API hacking, attackers can try to exploit various novelties to gain the upper hand. For example, credential stuffing, brute-forcing passwords and usernames, or even the forgot password option. Some systems have a flaw in the “forgot password” option. When users click on “forgot password,” they might somehow have direct access to the main application. Another way attackers can exploit a Broken User Authentication vulnerability is through session management attacks like stealing session tokens or session hijacking. All these exploits will ultimately result in attackers gaining access to endpoints through illegitimate tokens.

Mitigation recommendations:

When you look at the exploitations listed, it's clear that even authentication systems can be compromised. Below are some of the solutions you can implement to improve API security.

• Implement a secure user authentication mechanism. Authenticate only trusted users.
• Do not expose session IDs in URLs (e.g., URL rewriting).
• Session IDs should have an expiration date. In the case of critical financial systems, these IDs can even expire once a user logs out.
• Avoid relying only on API keys as the only form of authentication.
• Implement Multi-Factor Authentication (MFA)
• In situations of Machine-to-Machine communication, implement Mutual TLS together with OAuth MTLS Sender Constrained Tokens.

3. Excessive Data Exposure

When users send requests to an API endpoint, the API should return only the requested information and not any other resources. Excessive Data Exposure vulnerability occurs when the API response returns additional information other than the requested field or object. Although client UI might filter these excessive data, attackers may still find other access methods. A real-world example of Excessive Data Exposure vulnerability exploitation occurred in 2019. A computer science student discovered that a public API endpoint on the Venmo digital wallet was returning transaction records. The student developed a simple Python script to capture over 100,000 transaction data daily without requiring authorization. Hackers mainly exploit this API vulnerability to acquire personal user credentials or sensitive company data. In the long run, it results in financial costs as companies will need to pay harsh fines as compliance regulations protect personal data.

Mitigation recommendations:

• Limit data exposure to only authenticated, authorized, and trusted parties who need to consume the data.
• Developers can implement OAuth Scopes and Claims to ensure each user only accesses what they need to.
• Ensure that response is filtered in the API level (backend) and not the Client-Side.
• Enforce rules that govern how sensitive information is transmitted.

4. Improper Assets Management

Improper Asset Management is all about API version control. Imagine you have a set of developers on the API  providers team managing a particular version (say, Version one), and they are no longer there to support that version. Other developers might move on to implement version two or three of the API while version 1 still exists. Between these versions, you will find things like BOLA, authentication requirements, or rate limiting have been applied to the API differently. Maybe the other developers fixed these issues in later versions of the API (version one or version two), but version one is still exposed to all those vulnerabilities. Some of the consequences of Improper Assets Management vulnerability include sensitive information leaks or resource takeover through a common database shared between API version one and API version two.

Mitigation recommendations:

• Delete outdated APIs that are longer required by the application.
• Have an inventory of all current APIs with crucial information like the current version, who can use the API, which resources they can access with the API, the modes of authentication and authorization implemented, etc.
• Synchronize systems/ app documentation with live API endpoints.

5. Injection Attacks

You have probably heard of famous web injection attacks like SQL injections. Well, there are also injection attacks in APIs. An API injection vulnerability enables hackers or malicious users to send untrusted data to a system to reveal sensitive information or execute particular actions. This data may be sent through user input fields, passing them as parameters or file uploads. Other injection techniques used by attackers include Javascript queries, SQL, NoSQL, and OS command lines. Unfortunately, not only APIs that are vulnerable to Injection attacks. Third-party developer programs are also vulnerable. This problem might raise a chain of attacks that erase data or harvest valuable information.

Mitigation recommendations:

• Implement an API Gateway
• Filter the type of data that the API can transmit. For example, you should restrict the passing of SQL queries and untrusted data types mainly used for injection attacks. You can use some of the freely available libraries to validate data.
• Implement DI (Dependency Injection), mainly if your application heavily relies on Javascript.
• Implement systems that check for any unusual behavior from trusted clients making API requests, such as unexpected scripts, parameters, or other code injections. Further, you can also suspend these accounts.

6. Mass Assignment

The Mass Assignment vulnerability is one of the easiest ways an attacker can use to wreck your database. In simple terms, Mass Assignment is an API vulnerability that allows users to modify fields in the database that they shouldn’t change. Most development frameworks offer developers mass assignment as a feature to make data mapping simple. This feature enables assigning values to multiple variables or object properties all at once, thus simplifying the development process. Despite that advantage, the mass assignment also poses some serious security flaws. Assume your company has an application with two user roles — editor and admin roles. You are employed as an editor. This application only allows you to change your name and email address. Only the admin can change user roles. Assume you update your name and save the changes; the system will generate the request below.

//
{
"first name": "John",
"last name": "Doe"
}
//

Once the changes are updated, you will get a 200 OK response as shown below.

//
{
"first name": "John", "last name": "Doe", "isAdmin": "false"
}
//

Now, here is the catch! In the response, you can see a new field called isAdmin that is currently set to false. However, this field was not part of the request. Since an attacker can also see this response, they will spot that new field and try to manipulate the system with the following request.

//PUT
{
"first name": "John",
"last name": "Doe",
"isAdmin": "true"
}
//

In the above request, the attacker has directly set the isAdmin parameter to true. Now, if the application uses the mass assignment feature to update user records, the isAdmin field will be set to true. With a slight change to the API request, the attacker gained admin privileges.

Mitigation recommendations:

• Perform penetration testing on your systems and APIs (act and think like a hacker). This method will enable you to find some critical flaws in your application.
• Avoid binding incoming data and internal objects.
• Ensure that whatever information is returned in the API response is only accessible to the right user with the proper privilege level.
• When working with frameworks, use one that implements measures against mass assignment attacks or malicious parameter assignment.
• Avoid including unnecessary links in your API response.

7. DDoS Attack

A Distributed Denial of Service (DDoS) attack overloads a network system saturating the target machine with requests, either slowing down traffic or blocking it completely. This attack makes a system, service or network unavailable to users. An API DDoS attack makes the API endpoint unreachable. That occurs when an attacker infects several computers (botnets) and uses them to send numerous requests to the API endpoint, thus exhausting its memory. API DDoS mainly targets e-commerce systems opening them to Inventory Denial attacks (IDA).

Mitigation recommendations:

• Implement API resource and rate limiting. That is the first measure for protecting your APIs against DDoS attacks. Without rate limiting, you can even face friendly-DoS attacks. That is a situation where an authorized user requests too much data from the API.
• Use a reliable web application firewall. Firewalls can filter malicious traffic sent to your API endpoint.
• Create awareness among your technical team about the changing landscape of DDoS threats.

8. Insufficient Logging & Monitoring

Whenever an attack happens, the incident response team relies heavily on the logs to determine how the attack was carried out and who probably attacked your systems. For example, if an attacker accessed a system by brute-forcing credentials, a proper monitoring and logging system will show you what exactly happened. You might see a lot of traffic from one IP or failed logins at time intervals that would not be human-possible. If you don’t have a proper logging and monitoring system, attackers will continue exploiting existing API vulnerabilities undetected.

Mitigation recommendations:

• First, ensure you tackle all API vulnerabilities through penetration testing or bug bounty programs.
• Put a rigorous monitoring and logging system that keeps records of any API activity. In case of any incident, these logs will come in handy in analyzing the attack.
• Enforce identities in API transactions to improve the log trail.

Conclusion

Security is of the utmost importance in the API world. If an attacker can compromise your system by changing a few lines of code, it opens up several attack vectors that let them access data they shouldn't be able to. While APIs have a lot of potential uses for both customers and organizations, they can also be attacked. This article has looked at the 8 most common API attack types & Vulnerabilities. Since the API attack surface is dynamic and evolving, businesses and organizations should take the necessary steps and enforce API security on their systems.