When ships encounter bad weather and turbulence, they sail side-by-side because they stand a better chance of weathering the storm once they are tied together. Together, they are less likely to capsize. People and businesses aren’t that different. We are willing to open up to new collaborations when hardship (pun intended) comes knocking.

With the speed of change accelerating around us, we need new and improved ways of collaborating. Thus, it’s understandable why API adoption is so strong in many industries. The use cases differ, but they all lead to increased information sharing, collaborative work, and a shift toward open ecosystems. As a recent survey conducted by Imvision shows, 4 out of 5 organizations already enable either partners (B2B) or users (B2C) to access their data with external APIs.

Source: Imvision’s Enterprise API Security Survey

But this growing exchange of information doesn’t come without its fair share of risks. Having more APIs published and consumed also means more functionality being exposed. The business logic that was once hidden within an application can now be accessed — and potentially manipulated — directly. It’s not just the attack surface that grows but also the increasing complexity of relationships between functions and data objects that creates new vulnerabilities.

Take a Domino’s Pizza incident to realize the vulnerabilities created by the relationships between functions. In this case, the attacker was able to bypass the application and go directly to the API, initiating a fake payment process and manually activating the order confirmation function.

A lack of validation on the server-side (order confirmation arriving only after successful payment) made this fraud possible. Thanks to the exposed payment approval process, tech-savvy “customers” were able to rig the system so that it accepted invalid payments, providing them with free pizza.

New Technology, New Vulnerabilities

Attackers looking for cracks in APIs can employ a new attack style, one that traditional application security tools cannot detect: Functional Attacks. Understanding just what these new functional attacks are is critical for security professionals looking to secure their organization’s data, assets, and clients.

APIs are considerably more vulnerable to functional attacks that target the expected API call flow. They look like normal requests for all intents and purposes and are frequently not designated as such by standard protective measures. Unfortunately, this also means that general-purpose application security solutions, like Web Application Firewall (WAF), aren’t enough for absolute API security.

While security measures like WAFs excel at detecting and blocking malicious API calls that match known generic vulnerabilities, they fail to detect functional attacks. This is mostly because, on the surface, functional attacks are simply calls made by authentic users. It’s only when the application’s behavior is analyzed that suspicions begin to arise.

The API Attack Landscape

A closer look at the API attack landscape enables a better understanding of the risks posed to APIs. We can break them down into four distinct categories:

• OWASP Top 10 API: API Security has a dedicated OWASP top 10 list, which provides a well-researched, detailed breakdown of the common vulnerabilities that have been exploited to abuse APIs. Many of the vulnerabilities are more technical and similar to those of applications, while others are geared towards exploiting poorly designed functionalities, such as authentication and authorization flaws.
• Functional attacks: Targets proprietary business logic that governs the API functionality, which causes APIs to perform actions they’re not supposed to.
• User behavior: Several sub-categories, including data scraping, execution of rare actions, lack of execution of common actions, and other cases that indicate that the user is acting maliciously.
• Reconnaissance: This is not an attack vector on its own, but the breadcrumbs hackers leave while learning how an API works and scanning for vulnerabilities can be identified, so the attack can be stopped before it happens.

The US Postal Service suffered a functional attack that displayed usage abuse for data scraping purposes. In this case, attackers realized that they could abuse a specific API transaction by slightly changing the call parameters with each request.

This made it extremely easy for hackers to automate and distribute the attack across different credentials and thus access the data they were trying to retrieve. They achieved this without being detected, as the calls looked normal; the high volume, high-frequency requests didn’t look like abnormal behavior for The Postal Service’s highly-popular app.

Conclusion

The move towards Open Everything accelerated the creation of open ecosystems and the deployment of transformative digital initiatives. APIs play a large role in this transformation.

While APIs have incredible benefits, they also come with significant risks. Each API represents a particular function. That means that a single API can talk to another API, and each API is actually a unique access point into the inner workings of an application.

API attacks are rapidly becoming a common attack vector. Hackers eager to wreak havoc create functional attacks that manipulate API business logic to gain access to the private, sensitive data of others. Furthermore, there is a lack of custom security measures developed to protect APIs. Functional attacks that target API business logic often go undetected, as they appear like standard API calls.

It’s imperative to have a security solution that learns each API’s unique business logic and detects the anomalous behavior around functional attacks. The ability to automatically discover, test, and protect your APIs has become more critical than ever before.