A Rust-Powered Rewrite for Cloudflare’s WAF

Cloudflare’s Web Application Firewall (WAF) is a critical piece of infrastructure, blocking over 57 billion threats daily—roughly 650,000 HTTP requests every second. The core filtering engine, originally written in LuaJIT by Cloudflare’s now-CTO, has served the platform for years, earning top marks in the 2020 Gartner Magic Quadrant for WAF. Following the company’s pattern of replacing aging code, the team has rebuilt the WAF from the ground up in Rust, introducing a new architecture that separates rule logic from execution and brings significant management improvements.

Rollout begins today with 10% of new accounts receiving the new WAF when adding a Pro plan zone or higher. This expands to all new accounts through April, followed by migrations for existing customers. Enterprise users can request early access immediately.

Rule Management Gets a Refresh

The new WAF overhauls how users interact with managed rulesets. Previously, enabling Cloudflare’s Managed Ruleset required toggling a global switch and then manually configuring individual rule groups displayed as a simple list. The interface made quick, high-level tasks difficult—questions like “which rules are disabled?” or “which rules mitigate XSS?” required clicking through each group and rule individually.

The updated UI consolidates all rules into a single, filterable table. Rule tags have replaced the less flexible group structure, with each rule able to carry multiple tags indicating the affected software component, the attack vector (e.g., XSS, SQLi, RCE), or a specific CVE. One-click deployment is available for defaults, but power users retain advanced filtering, bulk editing, and inline rule controls. A new review screen highlights any deviations from the default configuration before changes are applied, simplifying rollback and auditing.

A New Engine Under the Hood

The shift from a LuaJIT NGINX module to a Rust-based engine is more than a language change. The new implementation adopts the wirefilter syntax—the same expression language used by custom Firewall Rules—as the basis for managed rulesets. This unification is a core design goal: it gives users a consistent filtering experience across both custom and managed rules, and it allows Cloudflare to share the same underlying Rust library for execution.

The move is driven by three objectives:

  • A safer, more performant runtime consistent with modern Cloudflare technologies
  • Richer filtering capabilities to simplify exception handling and flexible deployments
  • A unified syntax that closes the gap between custom Firewall Rules and managed rulesets

Beyond safety and consistency, the team expects performance gains, with further details promised in upcoming posts.

Updated Rulesets, Independent Actions

The port to the new engine comes with meaningful changes to how rules are expressed. Rule status is now decoupled from rule action, letting administrators enable or disable a rule and set its action (e.g., LOG vs. BLOCK) independently. All managed rulesets have been converted to the wirefilter syntax to support this.

The Cloudflare OWASP Core Ruleset receives its own major update. The current WAF runs a version based on the 2.x OWASP ModSecurity Core Ruleset, while the new implementation is based directly on the latest 3.3 release from the OWASP GitHub repository. This brings several advantages:

  • Fewer false positives and stronger application-generic rules
  • Finer control over sensitivity scoring, with visibility into each rule’s score contribution and the total score on triggered requests
  • A paranoia level setting to easily adjust rule aggressiveness based on false positive tolerance
  • Rule tags that match rules to application types

The engineering team also built an internal converter to translate ModSecurity syntax to wirefilter. This tooling keeps the Cloudflare implementation in lockstep with upstream OWASP releases and, once open-sourced and UI-exposed, is intended to ease migrations for customers coming from ModSecurity-based WAFs.

Account-Wide Configuration and Versioning

Historically, the Cloudflare WAF was managed on a per-zone basis. That model works for simple or highly segmented setups, but larger deployments often had to rely on the API or tools like the Cloudflare Terraform Provider to push consistent policies across many zones.

The new WAF introduces rulesets as a native, versioned concept, deployable against any arbitrary traffic filter within an account. Administrators can now:

  • Apply the Cloudflare Managed Ruleset across all zones
  • Deploy the OWASP Core Ruleset to all traffic except paths starting with /api/*
  • Disable Managed Rulesets account-wide for traffic originating from a specific IP

Versioning is built in from the start, enabling UI-based diffing and rollback that Cloudflare plans to expose in the coming months. Initially, account-based configurations are restricted to Enterprise customers, but custom Firewall Rules will also migrate to the new engine soon, letting customers build and deploy their own custom rulesets across any traffic filter.