WAFs were a top-notch security instrument a decade ago, but now they are not. They fail to protect APIs. Meanwhile, the number of API-specific vulnerabilities grew more than twofold in 2022. According to a [report]() by Wallarm, many such vulnerabilities have critical severity, and 33% are immediately exploited. But companies still heavily rely on WAFs, so many services turn out to be highly insecure and prone to data breaches. Consider this: an average data breach cost [hit]() 4.35 million dollars in 2022, and it’s ever-growing!

To save money and reputation, use a more reliable API security tool rather than a default cloud WAF. If you are not convinced yet, here we describe three limitations that make your default WAF ineffective, which are not usually discussed.

## Web & API Security

The use of APIs is [skyrocketing](), and the number of exposed flaws in business logic is growing proportionally. The reason lies in the difference between microservices and monolithic architecture, which previously dominated the field.

When a monolithic app receives a request from a user, the response is computed within the internal infrastructure and without interacting on the network. Only one endpoint per request is exposed. It’s the opposite for microservices: they interact online all the time via internal APIs to compute the response. Of course, they can be deployed on a dedicated server and won’t need to communicate on the network, but it’s costly and doesn’t make sense since microservices are specially designed for the cloud.

APIs provide access to many functions previously hidden inside a monolith, which implies many newly exposed flaws attackers can use. But it’s not only the attack surface that matters for securing your APIs! Let’s dig into it.

## Limitations of WAFs in API Security

There are a few pros and many cons to using a default cloud WAF in API security. It’s well known that WAFs cannot effectively deal with functional attacks. Yet, many crucial limitations are rarely discussed. Let’s explore them one by one.

### Nested Encodings

Your WAF is there to match incoming requests to the patterns of bad. [WAFs]() need to know what fraudulent requests look like. To teach them, you provide regular expressions for strings like “eval(” or “base64_” to be grepped in requests. When the payload is encoded, you add encoded analogs of fraudulent strings to your rule set. However, things get tricky if your payload is encoded multiple times. You need to add a set of matching strings for each encoding level. In turn, it leads to increased request processing time or time out. The latter is a disaster: users don’t like when they don’t get what they are looking for.

### Data Protocols Parsing

Often, online traffic is built in a Russian-doll manner: protocols go on top of other protocols. There are many of them above HTTP. For example, in gRPC, data is encapsulated and exchanged via HTTP2.

To reconstruct and check the payload, the WAF needs to know how these protocols are structured. Some WAFs support protocol parsing, but often it is limited to REST APIs and JSON data. Meanwhile, other popular API protocols like [gRPC](), [GraphQL](), [WebSocket](), and [SOAP]() are disregarded.

Among the most popular cloud WAFs, Cloudflare supports more protocols than others. The WebSocket protocol is an oldie but goodie, but WAFs, except Cloudflare, don’t support it! It doesn’t come as a surprise because security is one of the company’s biggest focuses. Yet, Cloudflare cannot parse GraphQL, which is rapidly gaining popularity. Strange.

| **AWS WAF**| **Cloudflare**| **Google Armor**| **Azure WAF**
—|—|—|—|—
**GraphQL**| [+]()| -| -| –
**REST API**| [+]()| +| +| +
**SOAP**| -| +| -| –
**JSON-RPC**| +| +| +| +
**gRPC**| -| [+]()/- no inspection for malicious payloads| -| –
**WebSocket**| [-]()| [+]()/- no inspection for malicious payloads| -| –
**Cloud WAFs’ protocol support table**

AWS WAF is the only one to protect GraphQL APIs, and it has done so [since 2020](). Amazon adopts a forward-looking strategy but leaves behind old solutions, like the SOAP protocol, which is still used in many legacy solutions migrating to the cloud.

Only one protocol can be parsed by all these default WAFs – the REST API. But there’s an important caveat you need to know.

## Checked Request Size Limitation

The size of the scanned payload in a WAF is always limited to the request’s first bytes. This fact still is widely overlooked and leads to weak security measures: an attacker can bypass all WAF checks at once by putting the malicious code further in the request body.

Can WAFs offer us a solution in case of oversized payloads? There are two ways a WAF can react: block the request immediately or pass it further without checking the bytes after the limit. Each WAF adopts a different strategy by default, so you need to check the settings before using your WAF to ensure it behaves as expected.

But blocking isn’t an intelligent solution: at least some of your APIs may receive legitimate yet big requests. To solve this, you can allow bigger requests for specific URIs. Still, the setup procedure is not obvious because of the rules hierarchy, and the initial concern becomes valid again: anything exceeding the limit may lead to an attack.

There’s no point in expecting AWS, Google, or other cloud providers to drop the checked payload limit. If it’s not in place, intentionally oversized requests can overload servers. Also, legitimate big requests would time out because of the time-consuming checks.

| **Maximum inspected request body size**
—|—
AWS WAF| 8 KB
Cloudflare| 128 KB
Google Armor| 8 KB
Azure WAF| [128 KB]()
**The request body size limitation table**

The limitation was not as crucial in the early days of the internet. Previously, requests mainly featured form submissions and were relatively small. Even if a user attached a file, it was uploaded in chunks due to bandwidth and throughput limitations.

It’s different for the data circulating between B2B endpoints. Let’s consider an example: a business has a digital document flow. To deal with customers and contractors, large PDF files accompanied by complex metadata, possibly containing a malicious payload, are sent back and forth. These files are not divided into chunks because the networks are now way more efficient than they used to be. It’s not the only example of a big, legitimate request. There is much more heavy data of various types circulating on the network.

Remember that many cloud providers don’t say their WAFs have this undesirable limitation when they offer a default WAF solution. It may be misleading and result in compromised data.

## Check Your WAF for API Limitations

The open-source [GoTestWAF]() tool by Wallarm allows you to identify security gaps in your WAFs. It takes a predetermined set of threat vectors and sends them to the tested URL in various request parts – HTTP path, header, or body. After the tests’ execution, the tool generates a report specifying the number of blocked and missed attacks, and calculates an overall safety score.

GoTestWAF has two scan modes: blind scan and app-specific scan, which makes it unique. In the blind scan mode, the check isn’t targeting APIs _per se_ but rather the WAF. No requests are API-specific. Most WAF checkers work in this way. But in the app-specific mode, GoTestWAF sends valid requests to different APIs relying on OpenAPI documentation.

How can GoTestWAF help eliminate the security gaps discussed above? Let’s consider an example of a WAF that can parse JSON but can’t check for encoded attack vectors in the fields. A WAF checker in the blind-scan mode won’t be able to model the attack targeting this vulnerability because the test requests will lack the necessary headers and fail the WAF check. However, if your requests comply with the protocol, you can insert the encoded attack vector in any field and check if the app’s WAF reacts appropriately.

_The report shows the percentage of passed and blocked vectors of various attack types._

In the vectors set, there are checks for the 8 KB, 15 KB, 32 KB, 64 KB, and 128 KB limits.

To test your APIs, pull the [GoTestWAF image]() from the Docker repository and run the command:

docker run -v ${PWD}/reports:/app/reports –network=”host”
wallarm/gotestwaf –url=

You’ll find the report in the ‘${PWD}/reports’ folder inside the container. Learn more in this quick [GoTestWAF demo video]().

## Conclusion

Bill Gates once claimed that 640 KB is enough for everything. If it ever was true, those times have long passed. Today, WAFs cannot limit the assessed payload to 128 KB, let alone 8 KB, if they intend to save you from cyberattacks. In today’s digital world, WAFs must handle all protocols, decode nested encodings, and inspect the entire payload. Then you will get the visibility and threat protection required to address your modern API-first environment’s compliance and business risks.

There’s more to [API security]() than threat detection – you need mitigation too. To ensure your APIs are secure, you should have advanced coverage for web applications and APIs. Book a consultation to learn how Wallarm can help.

The post [8 KB is not enough: why WAFs can’t protect APIs]() appeared first on [Wallarm]().Read More