← All products

Web Application Firewall (WAF)

The Cloudflare WAF evaluates proxied HTTP requests against custom rules, rate limiting rules and Cloudflare managed rulesets before they are forwarded to the origin server. This page documents the evaluation model, configuration objects, documented limits, plan availability and a deployment procedure.

Document control

Dana
Technical writer, Integrity Czech Republic s.r.o.

Overview

A web application firewall inspects HTTP requests before an application processes them and applies rules that allow, log, challenge, redirect or block. It is a filtering control that operates alongside patching rather than in place of it: it reduces exposure to known exploit classes and to automated scanning during the interval between disclosure and deployment of a fix.

The Cloudflare WAF is evaluated in Cloudflare data centres that proxy traffic for a zone. Cloudflare states that its network operates in 348 cities (https://www.cloudflare.com/network/, retrieved 2026-08-28). Only traffic that is proxied through Cloudflare is inspected. A DNS-only record, a hostname resolved outside the zone, or a client connecting directly to the origin IP address bypasses the WAF.

Rule content in the Cloudflare managed rulesets is maintained by Cloudflare and changes without a customer deployment step. Cloudflare does not publish a contractual update interval for managed rule content.

Cloudflare does not publish a measured latency figure for rule evaluation. If latency is a design constraint, measure it against your own configuration.

Architecture

A request to a proxied hostname terminates TLS at the Cloudflare data centre selected by anycast routing. The request then passes through the ruleset engine, which evaluates rules grouped into ordered phases. The security-relevant phases execute in this order:

1. URL normalisation and request sanitisation.
2. http_request_firewall_custom: zone and account custom rules.
3. http_ratelimit: rate limiting rules.
4. http_request_firewall_managed: Cloudflare Managed Ruleset, Cloudflare OWASP Core Ruleset and other managed rulesets deployed to the zone.

Within a phase, rules are evaluated in configured order. A terminating action stops evaluation of the remaining rules for that request. A non-terminating action allows evaluation to continue. The full phase list, including transform, redirect and cache phases, is documented in the phases reference cited below.

Detections are separate from rules. Attack score, leaked credentials detection, malicious uploads scanning and sensitive data detection compute values during request processing and expose them as fields. They do not block on their own; a rule must reference the field and specify an action. This separation is why enabling a detection changes no traffic until a rule consumes it.

The Cloudflare Managed Ruleset applies signature and heuristic detections curated by Cloudflare. The OWASP Core Ruleset operates differently: it evaluates a request against generic attack patterns, accumulates a score, and triggers when the score crosses a configured threshold at a configured paranoia level. The two rulesets are tuned independently.

Capabilities

Configuration model

WAF configuration consists of rulesets deployed to phases. A rule has an expression, an action, an order and optional action parameters. Expressions are written in the Cloudflare Rules language over typed fields such as http.request.uri.path, http.request.headers, ip.src.country, ip.src.asnum, cf.bot_management.score and cf.waf.score. Field availability is not uniform across plans; bot and attack score fields require the corresponding entitlement.

Actions available in the firewall phases are Block, Managed Challenge, Interactive Challenge, JS Challenge, Redirect, Serve Error, Skip, Execute and Log. Managed ruleset behaviour is adjusted with overrides rather than by editing vendor rules: a ruleset-level override changes the action or status for the whole ruleset, a tag-level override changes a group of rules, and a rule-level override changes one rule. Exceptions, expressed as skip rules, remove specific traffic from managed ruleset evaluation without disabling rules globally.

For the OWASP Core Ruleset, two settings determine behaviour: the paranoia level, which selects how many rules participate in scoring, and the score threshold, which sets the anomaly score at which the ruleset acts. Raising the paranoia level increases both detection and false-positive rate.

Configuration is manageable through the dashboard, the Rulesets API and the Cloudflare Terraform provider. Rule order and ruleset deployment order are part of the configuration and should be held in version control when rules are managed as code.

Limits and constraints

The values below were verified against Cloudflare documentation on 2026-08-31 and change without notice. Verify at the source before designing against them: custom rules, rate limiting rules and rules language actions.

The counting characteristics available on Pro are the same as on Free. A rate limiting rule that counts on anything other than the source address requires Business or Enterprise, which is a frequent cause of a rule designed on one plan failing to deploy on another.

Further constraints that apply regardless of plan:

• Only proxied traffic is inspected. DNS-only records, direct-to-origin-IP connections and non-HTTP protocols are outside the WAF data path.
• Request body inspection is bounded by a maximum inspected body size; content beyond that boundary is not evaluated. Confirm the current value in the source documentation.
• Managed rule content is vendor-controlled. Individual managed rules can be disabled or overridden but not rewritten.
• Detections do not act on their own. Enabling attack score, leaked credentials or upload scanning changes no traffic until a rule references the resulting field.
• Analytics sampling and retention differ by plan, which affects how much evidence is available for tuning on lower plans.

Plan availability

Deployment

Prerequisites. Complete the following before changing any rule:

• Inventory the applications, frameworks, exposed endpoints and API paths served by the zone, including administrative interfaces and machine-to-machine endpoints.
• Record which hostnames are proxied and which are DNS-only.
• Identify the integrations that must not be challenged or blocked: monitoring probes, payment callbacks, partner systems, CI pipelines and mobile clients.
• Confirm which plan the zone is on, because the Log action and regular expression support depend on it.
• Establish a rollback path: export the current ruleset configuration through the API or Terraform and store it.

Staged validation. Choose one of the following, depending on entitlement:

1. On Enterprise, deploy the managed rulesets with a ruleset-level override setting the action to Log. Collect matches in Security Events for a defined observation window covering at least one full business cycle.
2. On Free, Pro or Business, where Log is unavailable, use a non-production zone or a dedicated hostname that receives representative traffic, or scope enforcement with an expression that limits the managed rulesets to a small traffic slice such as a single path prefix or a test cookie. Review Security Events for that slice, then widen the expression in stages.

Configuration. Apply changes in this order:

1. Deploy the Cloudflare Managed Ruleset in blocking mode with the exceptions identified during validation.
2. Deploy the OWASP Core Ruleset at a low paranoia level and a permissive score threshold. Tighten in steps, re-observing after each step.
3. Add custom rules for application-specific paths: administrative interfaces, authentication endpoints, upload handlers and internal APIs.
4. Add rate limiting rules to authentication, password reset, checkout and expensive API endpoints, with thresholds derived from observed traffic rather than from defaults.
5. Scope exceptions as narrowly as the expression language allows. Prefer a path plus method plus rule ID exception over disabling a rule for the zone.

Cutover. Enable enforcement during a window in which application owners are available. Change one ruleset at a time so that a regression can be attributed. Keep the previous configuration export accessible for the duration of the window.

Verification. Confirm each of the following before closing the window:

• Synthetic transactions for the primary user journeys complete without a challenge or block.
• The integrations recorded during prerequisites still succeed, verified from their own logs rather than from Cloudflare analytics alone.
• Security Events shows blocked traffic matching the expected exploit classes and no clustering of blocks on legitimate paths.
• Rate limiting counters are triggering at the intended thresholds under normal load.

Rollback. To reverse the change, re-apply the exported configuration through the API or Terraform, or set a ruleset-level override that disables the ruleset. Record the rule IDs involved in any incident before rolling back, so that tuning can resume from evidence.

Operational considerations

Tune from evidence. Every blocked request carries a Ray ID; the corresponding Security Events entry identifies the ruleset, rule ID and matched field. Support processes should capture the Ray ID from the user, because it is the only reliable key back to the decision.

Analytics sampling and retention differ by plan. On lower plans a false positive that is not investigated promptly may no longer be visible. Where Enterprise Logpush is available, forward firewall events to the SIEM and retain them according to your own policy rather than relying on dashboard retention.

Managed rule content changes on Cloudflare's schedule. New rules can begin matching traffic that previously passed. Configure alerting on Security Events volume so that a change in match rate is noticed, and review new managed rules after they are announced in the Cloudflare changelog.

Rate limiting rules interact with shared client addresses. Traffic behind carrier-grade NAT, corporate proxies or a single mobile gateway can exceed a per-IP threshold without abuse. Where the plan permits additional counting characteristics, count on a session identifier or a header rather than on the source address alone.

Failure modes to plan for: a managed rule update causing new false positives, an exception that is broader than intended silently disabling protection, and an origin that remains reachable directly and therefore unprotected regardless of rule configuration.

Known caveats

• A log-only rollout is not available below Enterprise. Procedures copied from Enterprise documentation will not apply on Free, Pro or Business.
• The WAF protects the Cloudflare data path only. If the origin IP address is reachable from the internet, an attacker who discovers it bypasses the WAF entirely. Restrict the origin firewall to Cloudflare IP ranges (https://www.cloudflare.com/ips/), enable Authenticated Origin Pulls, or connect the origin with Cloudflare Tunnel.
• The OWASP Core Ruleset and the Cloudflare Managed Ruleset behave differently. Raising the OWASP paranoia level without lowering the threshold, or the reverse, produces results that are easy to misread during tuning.
• Disabling a managed rule for the zone is frequently used as a quick fix for one endpoint. It removes that protection for all traffic. Use a scoped exception instead.
• Regular expressions are unavailable on Free and Pro, so rules written for a Business zone may not deploy to a Pro zone.
• Requests served from cache and requests to DNS-only hostnames do not traverse the same evaluation path; do not infer coverage from a single successful test.
• Attack score and bot score fields referenced by a rule will not evaluate as expected if the entitlement for those fields is absent, which can silently change rule behaviour after a plan change.

Interoperability

The WAF shares the ruleset engine and the Rules language with rate limiting rules, transform rules, redirect rules, cache rules and configuration rules. Rules in different phases can therefore reference the same fields, and phase order determines which runs first.

Bot Management exposes cf.bot_management.score and related fields that WAF custom rules can reference, which is the supported way to combine bot classification with exploit filtering in a single decision.

Turnstile can issue pre-clearance for a session so that a visitor already verified by a widget is not challenged again by WAF rules on a proxied zone.

Workers execute after the security phases in the Cloudflare request pipeline, so a request blocked by the WAF does not reach a Worker. The documented traffic sequence should be consulted when a Worker and a WAF rule appear to conflict.

API Shield adds schema validation, mTLS client certificate enforcement and endpoint discovery for API traffic, and composes with WAF rules on the same hostnames.

FAQ

Does the WAF inspect request bodies? Yes, up to a documented maximum inspected size, and the fields available for body inspection depend on plan and on content type. Content beyond the inspected size is forwarded without body-based evaluation.

Do WAF rules apply to API traffic? Yes. Rules are evaluated on any proxied HTTP request, including JSON APIs and machine-to-machine endpoints. Challenge actions cannot be solved by a non-browser client, so API paths should use Block or rate limiting rather than a challenge.

How is a false positive traced? Capture the Ray ID from the affected response, locate the event in Security Events, and read the ruleset and rule ID from the entry. Scope an exception to that rule ID, path and method.

References

• https://developers.cloudflare.com/waf/, retrieved 2026-08-28.
• https://developers.cloudflare.com/waf/custom-rules/, retrieved 2026-08-28.
• https://developers.cloudflare.com/waf/rate-limiting-rules/, retrieved 2026-08-28.
• https://developers.cloudflare.com/waf/managed-rules/, retrieved 2026-08-28.
• https://developers.cloudflare.com/waf/detections/, retrieved 2026-08-28.
• https://developers.cloudflare.com/ruleset-engine/rules-language/actions/, retrieved 2026-08-28.
• https://developers.cloudflare.com/ruleset-engine/reference/phases-list/, retrieved 2026-08-28.
• https://www.cloudflare.com/network/, retrieved 2026-08-28.
• https://www.cloudflare.com/ips/, retrieved 2026-08-28.

Content snapshot: 2026-08-28.

Changelog