Introduction

It’s hard to imagine application security without the Web Application Firewall (WAF). For the past two decades, WAF has been an important part of the application security stack, helping organizations protect their sensitive data and transactions from attacks.

Sophisticated security solutions, WAFs are deployed in front of the application, independently protecting it by analyzing the traffic metadata and blocking known vulnerabilities using a wide range of pre-configured policies. WAFs are general-purpose security solutions, protecting any  web application in the same manner, regardless of the application’s functionality and purpose.

But web APIs aren’t the same as web applications. Same beast, different animals. And what works for applications isn’t enough to protect APIs. In fact, when it comes to protecting APIs, the strengths of WAFs turn out to be their greatest shortcomings.

WAFs and API Security

Your WAF is only as effective as the policies it enforces. Once a laborious process of manual configuration, modern WAFs (aka ‘NextGen WAF’) are equipped with advanced capabilities for automatic policy creation.

In recent years, WAF solutions have begun to include protections against API-based abuse. These protections generally include input validation and content threat detection, addressing several common forms of technical API manipulations. To enable these protections, WAFs create dedicated policies by ingesting the API schema, such as OpenAPI Specifications (fka Swagger).

While these protections can be effective, they rely on having accurate schemas beforehand. The reality, however, is that this prerequisite isn’t often met, and organizations struggle to keep up with documentation. The result? Outdated, incomplete, or inaccurate schemas, deeming the WAF protection to be irrelevant and noisy. 

Furthermore, WAFs require a lot of tuning and maintenance, so the variety and velocity of APIs makes them practically impossible to stay on top of. Too often, security teams are unaware of changes being made to APIs – or even aware of all the APIs the organization has to begin with.

API Threat Landscape

Sitting in front of the application, a WAF can utilize schemas for Input Validation (1), but generally remains ineffective against Functional Attacks(2), and uncovering publicly-available rogue APIs (3)

But perhaps the most important thing to remember is that even the best schemas only describe how the data is structured. They provide technical guidance and standards for API calls, but they don’t cover how it is used and to what end. The business logic isn’t documented.

This is why schemas can be used to protect against technical attacks, but are of little use when it comes to protecting against functional attacks.

API Threat Landscape

Case Study: Functional attacks

In a nutshell, functional attacks target the expected flow of an application in an attempt to break it. When executing a functional attack, the attacker would search for ways to manipulate the API in order to access restricted sensitive resources, or trick the API to conduct an action it isn’t meant to. Generally, functional attacks exploit flaws in the design and implementation of the API.

Consider the following case of sensitive data theft through a bank’s APIs:

In the normal usage of a bank’s service, as part of a registration process, the user inputs a phone number that is then associated with their investment account. There’s a 1:1 or 1:n relationship between the various data objects, and that logic is reflected in the regular user behaviors.

In this attack scenario, which happened to a charter bank, the attacker was a legitimate user/customer of the bank. They bypassed the front end application using their own credentials and manipulated the API directly using another legitimate user’s phone number to get access to the latter’s account information. 

Due to a vulnerability in the functionality of the API, the backend application did not validate the phone number and match it to the user sending the requests.

As a result, the attacker was able to retrieve sensitive data from other users’ accounts and quickly enumerate various phone numbers to retrieve information for many accounts – resulting in substantial damage to the reputation of the organization and exposing it to privacy regulation violations.

Protecting the API functionality

Web APIs aren’t the same as web applications. Same beast, different animals. The key difference lies in the business logic, or functionality. Both have it, but by definition APIs externalize their functionality much more than applications. 

You see, every API has a unique business logic that serves a specific functionality (or set of functionalities). Functions that in the past may have been hidden inside an application become exposed through APIs. This makes APIs more vulnerable to functional attacks targeting the expected API call flow.

WAFs are general-purpose application security solutions. They focus on enforcing policies based on the type of traffic detected. This is exactly where enforcing schemas with WAFs becomes ineffective. 

Not only are schemas not always available, but a WAF would overlook the specific functionality of the API. It may block technical manipulations, but has little value against a legitimate user trying to access the resources of other users.

Gartner quote
It’s tempting to think a WAF can be configured to include a myriad of very specific rules breaking down the logic to protect it. While that may hold in theory, in practice it simply doesn’t work: the knowledge needed into the API logic isn’t available, APIs vary greatly in their use patterns, they change rapidly, and are not always accounted for.

Applications Are Evolving

Modern architectures are breaking up applications to their core functionalities. Functionalities that were once hidden and secure within the app now have direct access to various users, consumers and partners.
Applications are evolving

Analyzing the application behavior to protect APIs

User behaviors reflect API logic. By learning the application behavior patterns, you can gain a deep understanding of its functionality, enabling enhanced security through dedicated, API-specific protections. 

Unlike WAFs that analyze only the metadata of web traffic, analyzing the actual data – all API transactions – enables the modelling of complex relations and flows within the data. 

Such a data-driven API discovery can uncover all your APIs, consumers, methods, and sensitive data without the need for documentation.

Once in-depth, granular behavioral models of API functionality are learned, it becomes possible to automatically detect and block breaches. 

Learning the application behavior and business logic enables you to automatically identify anomalous user activities and breaks within the functionality of the APIs, generating a unique advantage in mitigating attacks on APIs.

Furthermore, the learned functionality can go beyond runtime protection and be applied to security testing. Based on the learned API functionality, attack scenarios can be automatically generated to surface API security vulnerabilities.

Functional API Security: A Holistic Approach

By learning the unique API dialogue patterns and identifying anomalous behaviors, functional API security enables to accelerate security across the SDLC, from code to production.
Functional API security: a holistic approach

Addressing the OWASP API Security Top 10

Aside from its widely recognized list of the top 10 Web Application Security Risks, in 2019 OWASP published a separate list dedicated to API Security. It provides a well-researched, detailed review of the common vulnerabilities exploited to abuse APIs, listed in descending order of risk based  on ease of exploitation, prevalence, ease of detection for attackers, and potential impact.

It’s important to remember that while OWASP covers the common denominator for API vulnerabilities, each API is different and has its own unique vulnerabilities associated with its business logic and processes, and user behavior becomes more contextual than others

For more on this topic, read The CISO’s Guide to OWASP API Top 10

WASP API Security Top 10

About Imvision

With Imvision, enterprises are set to accelerate their digital transformation by making sure every API is individually protected and every API call is scrutinized – no matter how many there are. It’s about ensuring that every interaction between people, businesses, and machines can be trusted.

By applying an NLP-based technology, Imvision’s Anomaly Management Platform (AMP) is able to analyze the unique dialogue for every API, understand the application’s behavior, and model complex relations within the data. This enables it to detect and prevent breaches by identifying anomalous behaviors and breaks at the application’s business logic level.

See Imvision's full lifecycle API security platform in action