WAF

A WAF is a web application firewall. It sits in front of a web application and inspects HTTP(S) traffic before that traffic reaches your origin. It blocks requests whose patterns match attacks such as SQL injection, cross-site scripting (XSS) and path traversal. OWASP defines it as "an application firewall for HTTP applications" that "applies a set of rules to an HTTP conversation". Its rules "cover common attacks such as Cross-site Scripting (XSS) and SQL Injection".

A WAF is not a network firewall. It is not volumetric DDoS defense either. Cloudflare calls a WAF "a protocol layer 7 defense (in the OSI model)" that "is not designed to defend against all types of attacks". Fastly states that "a WAF only inspects HTTP or HTTPS requests (layer 7)" and "will not process any TCP, UDP, or ICMP requests". It does not absorb packet floods, and it does not fix the vulnerable code behind the endpoint. It can only judge traffic that reaches it in a form it can decrypt and parse.

Cloudflare describes three ways to implement one: network-based (usually hardware, installed locally), host-based (integrated into the application's own software), and cloud-based (a subscription, typically turned on with a DNS change). A CDN WAF is the cloud-based form. It runs in the provider's edge PoPs, so a malicious request is rejected near the client instead of in your data center. Everything below is mechanism, vendor detail and tuning.

How it works

The WAF is a reverse proxy in the request path: "a WAF is a type of reverse-proxy, protecting the server from exposure by having clients pass through the WAF before reaching the server" (Cloudflare). Each request is evaluated against a rule set. Each rule carries an action.

Blocklist or allowlist. A WAF on a blocklist (negative security model) blocks known attacks. One on an allowlist (positive security model) "only admits traffic that has been pre-approved". Cloudflare notes that many WAFs offer a hybrid of both. CDN managed rule sets are the negative model in practice. Cloudflare describes its own Managed Ruleset as "a proprietary, signature-heavy engine". Positive-model enforcement usually appears as a separate feature, such as API schema validation.

What is inspected. Rules address individual request components. An AWS WAF rule statement can inspect the HTTP method, a single header, all headers, header order, cookies, the URI path, a URI fragment, the query string, a single or all query parameters, the body, or a parsed JSON body. It can also inspect JA3/JA4 TLS fingerprints. Text transformations can normalize a component before matching.

Actions. AWS WAF rule actions include Allow and Block. They also include Count, which "counts the request but does not determine whether to allow it or block it", plus CAPTCHA and Challenge, which "uses CAPTCHA puzzles and silent challenges to verify that the request is not coming from a bot". A CloudFront-only Monetize action returns HTTP 402 with payment instructions for AI bots. Count is the observability action: it records matches while a rule is still on trial. The response code for a block is vendor-specific and configurable. It is not a universal 403. AWS WAF answers with "an HTTP 403 (Forbidden) status code" by default. A Fastly Next-Gen WAF agent returns 406 "unless you specified a different custom response code". Rules can also rate-limit a client. Cloudflare notes that "during a DDoS attack, rate limiting can be quickly implemented by modifying WAF policies".

Scoring, not just match and block. The Cloudflare OWASP Core Ruleset is its implementation of the OWASP ModSecurity Core Rule Set (CRS) version 3.3.0. It "uses a scoring model: each matching rule adds its score to a cumulative threat score, and the WAF executes the configured action when the score exceeds the threshold". Two dials control it. The paranoia level classifies rules by aggressiveness from PL1 (the default) to PL4. Rules at higher levels "might cause more legitimate traffic to get blocked due to false positives". The score threshold sets "the minimum cumulative score — obtained from matching OWASP rules — for the WAF to apply the configured OWASP ruleset action": High is 25 and higher, Medium is 40 and higher (the default), and Low is 60 and higher, so a Low threshold is the least aggressive setting because "more rules will have to match the current request for the WAF to apply the configured ruleset action".

Beyond signatures. Vendors layer machine learning and CVE-specific rules on top of pattern matching. Cloudflare states that "the ML-based Cloudflare Attack Score complements managed rulesets by detecting attack variations and bypasses". Cloudflare also states that it ships "proactive virtual patching for newly discovered CVEs (for example, Log4Shell) often deployed within minutes or hours of disclosure". Fastly defines the same idea explicitly: "a virtual patch is a pre-constructed rule that targets a specific CVE". You can enable such a patch in logging or immediate-blocking form.

Why it matters for a CDN

The CDN already terminates the connection at the edge, so it is the cheapest place to reject a request. Akamai's App & API Protector "detects and mitigates application threats in HTTP and HTTPS traffic as they attempt to pass through Akamai's edge platform to reach your origin data centers". A blocked request never crosses the middle mile. It never reaches your servers or their capacity limits.

Inspection depends on decryption. That is why the WAF belongs to the same edge stack as TLS termination. Fastly's Cloud WAF deployment requires you to "upload a TLS certificate, add an origin server" and repoint DNS. This is because the WAF has to hold the certificate to see plaintext requests at all.

The WAF also has a defined place in the edge's execution order. That order decides what it ever sees. On Cloudflare, WAF Managed Rules run in the http_request_firewall_managed phase, "which executes after: HTTP DDoS Attack Protection (ddos_l7 phase), Custom Rules (http_request_firewall_custom phase), Rate Limiting Rules (http_ratelimit phase)". Also, "a rule with a terminal action (such as Block or Managed Challenge) in any of these earlier phases prevents Managed Rules from evaluating that request". Volumetric defense is a separate, earlier layer. Fastly's Edge and Cloud deployments "feature an always-on service integration that examines inbound traffic to detect and mitigate Distributed Denial of Service (DDoS) attacks before they reach the applications and origin servers that you specify". The WAF is what reads the individual request.

What CDNs do

• Cloudflare WAF has pre-configured managed rulesets: the proprietary Cloudflare Managed Ruleset, the Cloudflare OWASP Core Ruleset, a Free Managed Ruleset, and a response-phase Sensitive Data Detection ruleset. Availability is plan-gated: every plan gets the Free Managed Ruleset, the Cloudflare Managed Ruleset and OWASP Core Ruleset need Pro or above, and Sensitive Data Detection is Enterprise only. Managed rules execute after custom rules and rate limiting rules. The Cloudflare Managed Ruleset "is updated frequently to address new threats and reduce false positives".
• AWS WAF keeps rules in what the docs now call a protection pack (web ACL): "when you create a protection pack (web ACL), you can specify one or more CloudFront distributions that you want AWS WAF to inspect", for both standard and multi-tenant distributions. Alongside your own rules you can select "one or more rule groups from AWS Managed Rules for each web ACL, up to the maximum protection pack (web ACL) capacity unit (WCU) limit". Rule capacity is a finite budget, not a free-for-all.
• Fastly Next-Gen WAF uses an agent that is, in Fastly's words, "formerly known as the Signal Sciences agent". The product is still administered through the Signal Sciences control panel and API. It deploys three ways: Edge WAF on Fastly's platform, On-Prem WAF (module plus agent on your own servers), and Cloud WAF on Fastly-hosted infrastructure. Each workspace has a Protection mode of Blocking, Logging (Not Blocking) or Off. Feature availability follows the purchased tier. On the entry tiers, rule action types are "Allow and Block only".
• Akamai App & API Protector ships in two flavors. The base product "detects and mitigates application threats in HTTP and HTTPS traffic as they attempt to pass through Akamai's edge platform to reach your origin data centers". It has a single security configuration where "setup and management is simple and protections update themselves". App & API Protector with Advanced Security Management adds multiple security configurations, match targets that scope a policy to a hostname, path or API, per-rule actions and exceptions, and client reputation controls. It also adds the option to "run your WAF in manual mode to schedule engine updates" instead of automatic upgrades.

Watch out for

• False positives block real users. Cloudflare's own caution is that "the Cloudflare OWASP Core Ruleset is prone to false positives and offers only marginal benefits when added on top of Cloudflare Managed Ruleset and WAF attack score. If you decide to deploy this managed ruleset, you will need to monitor and adjust its settings based on your traffic to prevent false positives." Raising the paranoia level increases coverage and false positives together. Cloudflare warns that at PL4 "you will probably need to disable some of its rules for applications that need to receive complex input patterns". Budget time to tune, not just to deploy.
• A WAF only catches what it parses the way the origin does. The WAFFLED study fuzzed non-malicious parts of requests: headers and body segments in application/json, multipart/form-data and application/xml. It "identified and confirmed 1207 bypasses across 5 well-known WAFs, AWS, Azure, Cloud Armor, Cloudflare, and ModSecurity". It found that "more than 90% of websites accepted both application/x-www-form-urlencoded and multipart/form-data interchangeably". Protocol-level blind spots are documented too. Fastly's Next-Gen WAF "can only inspect WebSocket traffic when it is deployed using the Core WAF deployment method". Its Edge and Cloud deployments "don't support WebSocket traffic inspection".
• Only part of a request body is inspected. Cloudflare's managed rules "inspect the body of each incoming request up to a maximum size". That limit varies by plan, and "request content beyond this limit may not be fully analyzed, which can affect how managed rules behave". The effect runs both ways. A truncated body hides content from the rules. A large inspected body gives more content to match. It raises the cumulative OWASP score and "makes it more likely to exceed the score threshold — resulting in a false positive". Cloudflare exposes an http.request.body.truncated field so custom rules can act on requests that were not fully analyzed. On AWS, analyzing more body costs money, billed per million requests "for each additional 16KB analyzed beyond the default body inspection limit".
• Your own bugs are still your own bugs. Fastly lists this as a product limitation. If attackers find a vulnerability unique to your application and your configuration has no rule for it, "it will not be able to protect your application in that instance". Cloudflare is equally direct that several OWASP Top 10 categories "depend more on how the application is built or how the entire monitoring pipeline is set up". Those categories are Cryptographic Failures, Insecure Design, Identification and Authentication Failures, and Security Logging and Monitoring Failures. Cloudflare also says that "while some risks can be addressed by a web application firewall, others require different solutions or must be mitigated during application development". Note also that the OWASP CRS is not the OWASP Top 10. They are different documents.
• Rules cost capacity and money. AWS WAF charges "are based on the number of web access control lists (web ACLs) that you create, the number of rules that you add per web ACL, and the number of web requests that you receive". There is also a monthly fee per rule group and a surcharge per million requests once a web ACL exceeds its default WCU allocation. Those charges are "in addition to Amazon CloudFront pricing". Placement is a trade-off as well. Cloudflare notes that locally installed network-based WAFs "minimize latency" but carry equipment and maintenance costs. A cloud-based WAF is a DNS change away, but it hands the inspection path to a third party.

Best practice

• Observe before you block. Fastly ships a new workspace with "the Protection mode (Agent mode) ... set to Logging (Not Blocking)", a mode that "never blocks requests". Fastly also "strongly recommend[s] you monitor your traffic via the control panel for a minimum of two weeks before blocking traffic". Akamai's five-minute setup "creates a new security configuration, with all protections on, with actions set to Alert, which means that you can now view requests in reports". Akamai then says to monitor for a few weeks before tuning. On AWS the equivalent is the Count action. Use these modes to find out what you would have blocked before a rule can stop a paying customer.
• Test in staging, tune per application. AWS is explicit: "before using any managed rule group in production, test it in a non-production environment". Follow the same testing when you add a rule group or move to a new rule group version. Fastly likewise recommends adding the WAF to a staging website before a production one. Then tune per site: adjust the paranoia level and score threshold, disable individual rules or whole tags, or create exceptions that skip a ruleset for known-good traffic.
• Keep managed rules and virtual patches current. The value of a managed ruleset is the update stream. Cloudflare "rapidly deploys protections for new CVEs through its managed ruleset, whereas the OWASP CRS remains relatively static". Fastly announces new virtual patches in its changelog. A ruleset frozen at deployment day protects against last year's attacks.
• Do not stack rulesets for the sake of it. Cloudflare's guidance is that its OWASP Core Ruleset "offers only marginal benefits when added on top of Cloudflare Managed Ruleset and WAF attack score". More overlapping rules mean more false positives, more WCUs or CPU, and more tuning, not linearly more security.
• Treat the WAF as one layer. AWS states that its managed rule groups "add another layer of security for your applications" but "aren't intended as a replacement for your security responsibilities". Blocking a request is not the same as fixing the injectable endpoint behind it: patch the code, then keep the WAF as the thing that buys you time between disclosure and deploy.