What You Should Know About BreakingWAF

• A third-party research team published a blog post about a technique to bypass web application firewall (WAF) solutions that they call BreakingWAF.

• The research highlights a condition that is inherent in the way HTTP proxy technologies work.

• BreakingWAF is not a vulnerability stemming from WAF solutions — it is a misconfiguration vulnerability that vendors like Akamai address during customer onboarding.

• Securing origin server access is a standard practice when customers’ onboard to a content delivery network (CDN).

On December 3, 2024, a third-party research team published a blog post announcing a “widespread WAF bypass technique” that they dubbed BreakingWAF. Unfortunately, the announcement in that post is a broad generalization that does not necessarily take into account commonplace proxy architectures or vendor onboarding practices. In real life, customers are guided to implement access controls when they implement a CDN-based WAF. 

In this blog post, we’ll further support our customers by explaining how proxy architectures, including CDNs, work — and discussing the choices customers have in securing access to their infrastructure.

The third-party research refers to a well-known security consideration for consumers of CDN and other HTTP proxy technologies. This particular research highlights how a threat actor can bypass a proxy and evade detection by the web application and API protection (WAAP) logic of a WAF. These security considerations apply regardless of which technology vendor is providing the service. 

When implementing a CDN, users have several choices to cloak origin servers and invoke stronger edge-to-origin authentication. These include controls at both the CDN and origin application layers. This is how HTTP proxy technologies fundamentally work; an HTTP proxy acts as an intermediary between a client and a web server. 

When a client requests a web page through a proxy, the request is first sent to the proxy server. If the content has been cached by the proxy server, it is immediately delivered to the client. Otherwise, the proxy retrieves the data from the application’s "origin" server (the website application itself, for example, when personalized information must be retrieved from a database) and returns it to the client (Figure 1).

This effectively masks the client's IP address, potentially allowing access to restricted content depending on the proxy configuration. However, the origin server can still identify the proxy's IP address, not the client's original IP, unless specific headers like X-Forwarded-For are used to disclose the client's origin information. 

Security considerations inherent in the way HTTP proxies work are not vulnerabilities stemming from WAF solutions. 

Akamai’s origin firewall — Site Shield, which is included in our WAF offerings— helps prevent non-​Akamai​ machines from contacting customer origins. Site Shield provides an additional layer of security by using a defined set of IP subnet ranges to route traffic to the origin, ensuring that the client requests from the CDN are routed to the origin via the provided list of IP CIDR ranges from the Akamai CDN (Figure 2).

Allowlisting the IP ranges on the perimeter firewall helps prevent attackers from bypassing cloud-based defenses and directly targeting the application origin. When a customer configures Site Shield, they get an email with a list of ​Akamai​ servers that should be allowed to contact their origin, which they can use to establish an access control list (ACL) on their firewall to prevent any other requests. 

As the third-party researchers accurately point out, Akamai provides our customers with guidance and with several capabilities that are designed to ensure strong authentication between Akamai edge servers and customer origins. These capabilities include IP allowlists, HTTP header-based authentication, and mutually authenticated TLS. 

Customers are advised to enable these capabilities and mitigate the risks highlighted by the research. Akamai also provides detailed onboarding guidance to CDN customers that includes information on how to set up identity and access, secure certificates, and set up origin servers and testing processes before going live.