API connection is vulnerable to which of the following

An API attack is hostile usage, or attempted hostile usage, of an API. Below are some of the many ways that attackers can abuse an API endpoint.

Injection Attacks

Injection attacks occur when malicious code is embedded into unsecured software. SQLi (SQL injection) and XSS (cross-site scripting) are the most prominent examples, but there are others. Injection attacks are a long-standing threat against web applications; today, they are also a growing threat for APIs.

DoS/DDoS Attacks

In a Denial of Service (DoS) or Distributed Denial of Service (DDoS) attack, the attacker attempts to make the targeted system unavailable to its intended users. They have a wide variation of possible scale. At one extreme, “slow” DoS attacks can exhaust the victim’s resources with very little bandwidth. At the opposite extreme, volumetric DDoS assaults can consist of several terabits per second of incoming traffic. When these occur against prominent websites, they can gain a lot of publicity. However, DoS and DDoS attacks are growing in frequency against API endpoints as well. 

Authentication Hijacking

Attackers attempt to bypass or break the authentication methods that a web application is using.

Data Exposure

Web applications frequently process and transfer sensitive data: credit card information, passwords, session tokens, private health information, and more. If an application does not handle the data correctly—for example, by not encrypting in transit, or at rest—then it could be compromised.

This is especially a concern for RESTful APIs that use HTTP as the underlying protocol. HTTP includes a number of operations that are potentially vulnerable. An attacker can craft malicious requests, control message mapping, and even manipulate the responses generated by the backend system. 

Parameter Tampering

An attacker attempts to manipulate the parameters exchanged between client and server. The goal is to modify application data, such as user credentials and permissions, price and quantity of products, etc.

Man in the Middle (MitM)

In an API MitM attack, the attacker intercepts communications between an API endpoint and a client. The attacker steals and/or alters the confidential data that is passed between them.

Unencrypted Communications

Transport Layer Security (TLS) is one of the most elementary “must-haves” in a secure API, but many organizations are still using APIs without it. This gives hackers free reign over the API and the data that passes through it.

Application Abuse

The attacks listed above are seen across verticals and industries. In addition to these, there are dangerous threats which are more specific, and are tailored to the targeted applications. 

Here’s a common example from the travel industry. Many companies (airlines, aggregators, etc.) offer mobile applications through which customers can purchase flight tickets. When a customer uses an application and begins to reserve a seat, the backend will usually decrease the available space on the plane immediately. If the customer completes the reservation and purchases a ticket, the decrease becomes permanent. Otherwise, it lasts for a default timeout period (usually 10 minutes or so).

This creates an opportunity for abuse. First, competitors reverse-engineer the API. Then they use bots to pose as customers, which begin the flight reservation process but never complete it. Each time, a seat is removed from available inventory for the entire timeout period. This makes it unavailable to legitimate customers during that time. When a large enough number of bots are doing this simultaneously, repeating the process after each timeout has finished, large blocks of seats can remain unsold. The bots can prevent real customers from buying.

Notice that this form of attack (called inventory denial) is based on legitimate requests. The bots masquerade as legitimate users; they send requests to the API endpoint as if they were instances of the application being used by actual humans on their mobile devices.

Therefore, many WAFs cannot detect these API security attacks. Most WAFs are designed to detect problems in the requests (e.g., attempted script injection, malformed headers, and so on). But in this attack, the requests themselves are legitimate. (The problem is that they are being used for a broader illegitimate purpose.) 

Since the requests themselves appear innocuous, the primary way to defend against this attack is to accurately identify the requestors are being bots.

This problem can (and does) occur on travel websites too. But as described here, website traffic is easier to scrub. 

Within a web application, it is easier to detect bots. Therefore, it is easier to block bots from gaining access. 

This means that API abuse can be harder to prevent than web application attacks. This is especially true for an application-layer attack like inventory denial.

What is API connection vulnerable to?

What is API vulnerability?

Which of the following are the risk for API?

What are the different types of attacks against APIs?