When it comes to protecting APIs, WAF’s greatest strengths turn out to be its biggest weaknesses

If there’s one thing that most people know about in the cyber security space it’s the Web Application Firewall (WAF). For the past two decades, WAFs have been on the frontline of the application security stack, leveraging pre-configured policies and analyzing traffic metadata to block known vulnerabilities. 

However, today’s applications are entirely different animals than the web applications WAFs were originally developed to protect. Application Programming Interfaces (API) power microservice architecture and cloud computing that are at the core of the latest, advanced technologies and products used today. Unfortunately, this also means that the relative advantages of using WAFs to secure web applications are not enough to protect APIs from the newer, more innovative, functional attacks that are often used to breach them.
 

The problem with using WAFs to secure APIs

Modern NextGen WAFs employ automatic policy creation that includes protections against API-based abuse. To ensure optimal API protection, WAFs are ingested with API schema that details how input validation and content should be delivered to the API. If a query does not conform to the schema, the WAF identifies it as a potential threat and blocks it. 

In theory, this model should be able to protect APIs as their calls should always conform to predefined communication protocols. Any digression from these predefined protocols is automatically identified as a possible attack and blocked. In reality, this type of protection is inherently faulty because it depends on the existence of fully maintained, accurate API schemas to keep the WAFs abreast of any changes that may affect the API call. 

However, in many cases API documentation lags far behind current configurations as documentation is often low priority for the dev teams that work on APIs. In most cases, schemas are outdated, incomplete or inaccurate. This means that in many cases, the WAFs protecting APIs do not have the info needed to keep them secure. 

APIs need frequent maintenance and updates as the software they power evolves. Unfortunately, the dev teams that execute these changes and the security teams tasked with protecting APIs aren’t always fully aligned. 

In many organizations, sec and dev teams operate in separate silos, unaware of each other’s activities. This means that security teams can be unaware of changes to APIs, and in some cases, completely ignorant to their existence. 
 

API threat landscape

But even the most accurate schemas only show WAFs how API calls should be structured. They teach the WAF what each API call should look like, but they don’t dive down into the details of the business logic and type of data that is transferred with every API call. The WAF is completely ignorant of acceptable patterns, workflows and relationships with endpoints that proper API usage should entail. 

This means that WAFs are potentially capable of protecting against old-school technical attacks — which are common ways of attacking web applications — targeting coding mistakes and usually don’t conform to the API schema. However, they are vulnerable to functional attacks that target flaws in the API’s business logic flow. 

This issue is even more pressing when examining the modern microservice architecture that is fast-becoming the standard way of building complex, modern software. Microservice architecture separates the different functionalities within an application into standalone entities. These entities communicate externally through APIs that are by nature accessible to the outside world. 

Consequently, functionalities that were once buried deep within the application are now fully exposed to external users. This makes it much easier for hackers to quickly identify where the private, sensitive data they seek to access can be found in the application.
 

Dedicated data-driven protection for each API 

The core business logic that drives API functionality is reflected in the way users interact with them. By examining the way a user interacts with an API, it’s possible to understand whether a specific use case is legitimate or not. 

However, WAF protection doesn’t take these usage patterns into consideration in its protection methodology. Instead, WAFs rely on the analysis of call metadata to ensure that protocols conform to the schema. Any anomalies discovered in the call structure are considered potential attacks.

Focusing on the business logic at the core of every API offers new cyber security possibilities. Because each API performs a very specific function, the analysis of API transactions and the data that flows through them enables the modeling of the complex relations and data flows that represent proper API behavior.

This method enables data-driven API discovery of key elements — consumers, methods and sensitive data — without needing any documentation. With this information at hand, granular behavior models of API functionality can be leveraged at the center of any API security mechanism.

Once granular-level models of the business logic and application behavior behind an API have been created, anomalous activities are automatically identified and blocked. Any behavior that doesn’t conform to the single function that the API facilitates is by definition an attempted attack. 

This innovative, data-driven approach to API security enables fully customized security mechanisms for each API in your deployment. 
 

Conclusion

With modern microservice architecture exposing more and more of a software’s underlying functionality externally, it’s critical that organizations do everything they can to protect their APIs. By taking a data-driven approach to API security it’s possible to model expected API usage patterns and understand what proper usage looks like. AI-powered capabilities empower the automatic modification of these models in accordance with any updates or changes made by dev. That way, misalignment between dev and sec teams do not impact security levels.