Set Up Cloudflare WAF: 12 Steps, Free to $250/Mo [2026]

Cloudflare shipped two emergency Web Application Firewall releases in September 2026 alone, adding block-mode detections for an Adobe Commerce remote code execution flaw (CVE-2026-75650) on September 10 and a WordPress path traversal bug (CVE-2026-87902) on September 25. A third release on October 9 added coverage for an F5 BIG-IP heap-based buffer overflow (CVE-2026-94127) and promoted a command-injection rule from log-only to block. If your site or API sits behind Cloudflare but you never finished configuring the WAF beyond the default toggle, none of that protection is doing what you think it’s doing.

This tutorial walks through a full Cloudflare WAF setup in October 2026: picking the right plan, turning on managed rulesets, writing custom Wirefilter rules, configuring rate limiting, tuning false positives without breaking your checkout flow, and automating the whole thing with Terraform so it survives more than one engineer’s tenure. By the end you’ll have a working, version-controlled WAF configuration protecting both a website and an API endpoint, plus a troubleshooting checklist for when (not if) a rule blocks something it shouldn’t.

·

Google · Preferred Sources

Don't miss new tech stories on Google

Add Tech Insider once in the Google app and our stories appear in your news suggestions.

Add Now

What Cloudflare WAF Actually Does and Why It Matters Right Now

Cloudflare WAF sits at the edge, in front of every request that reaches your origin server, and inspects HTTP and HTTPS traffic before it ever touches your application. It works whether your backend is a single VPS, a Kubernetes cluster, or a serverless function, because the enforcement point is Cloudflare’s network, not your infrastructure. That’s the core pitch versus a server-side module like ModSecurity: you’re not patching rule logic on every box behind a load balancer, you’re changing one dashboard setting or pushing one API call and it takes effect globally within seconds.

The Cloudflare WAF documentation breaks the product into three layers that matter for this tutorial: managed rulesets maintained by Cloudflare’s own security team, the OWASP Core Ruleset for generic attack-pattern coverage, and custom rules you write yourself using Cloudflare’s Wirefilter expression language. A rate limiting layer and a bot management layer sit alongside these and run in a defined order, which matters once you start combining them.

Why October 2026 specifically? Beyond the three emergency releases already mentioned, Cloudflare’s changelog also disabled a stale rule for fake Bing/MSN bot user agents that was producing false blocks, and in late September the company published guidance on detecting the React Server Components vulnerability tracked as CVE-2025-55182. Managed rulesets update on a rolling basis, sometimes within hours of a CVE going public, which is the single biggest argument for using a WAF at all instead of relying purely on patch cadence.

Prerequisites: What You Need Before You Start

You don’t need an Enterprise contract to follow this tutorial, but a few things need to be in place first:

• A domain you control, with access to update nameservers at your registrar (GoDaddy, Namecheap, Route 53, etc.)
• A Cloudflare account — free to create, no credit card required for the Free or Pro tier
• Admin access to your origin server or hosting panel to confirm Cloudflare’s IP ranges aren’t blocked by your own firewall
• Terraform 1.9 or newer if you want to follow the infrastructure-as-code section (the Cloudflare provider for Terraform is actively maintained and versioned independently of Terraform core)
• A Cloudflare API token with Zone:Edit and Firewall Services:Edit permissions, generated from the dashboard under My Profile → API Tokens
• Roughly 90 minutes if you’re doing the full setup including rate limiting, logging, and Terraform automation; about 25 minutes for just the managed-ruleset portion

One honest caveat up front: Cloudflare WAF only protects traffic that’s actually proxied through Cloudflare. If a subdomain or API route resolves with a gray-cloud (DNS-only) DNS record instead of the orange-cloud proxied record, none of this applies to it. That single setting trips up more teams than any rule misconfiguration.

Step 1: Add Your Domain and Switch DNS to Cloudflare

Sign in to the Cloudflare dashboard and click Add a Site. Cloudflare scans your existing DNS records and imports them automatically, but you should still review every record before continuing, since a missed MX record can take down email delivery mid-migration. Confirm that your main A or CNAME record for the website, and any API subdomain, show the orange cloud icon (proxied), not the gray cloud (DNS only).

Cloudflare will give you two nameservers to set at your domain registrar. Propagation typically completes within a few hours, though it can take up to 24 hours depending on your registrar’s TTL settings. Nothing else in this tutorial works until that switch is live, so this is the step to do first and then come back to once propagation finishes.

While you wait, lock down your origin so it only accepts traffic from Cloudflare’s published IP ranges. Otherwise an attacker who finds your origin IP through a leaked DNS history or a misconfigured subdomain can bypass the WAF entirely by connecting directly.

Step 2: Pick the Plan That Actually Matches Your WAF Needs

Cloudflare’s plan tiers gate WAF capability more than most people realize, and picking the wrong one means discovering a missing feature mid-incident. Here’s the current breakdown as published on Cloudflare’s pricing page and the managed rules documentation:

Plan	Price	Managed Rulesets	Rate Limiting Rules	Bot Protection
Free	$0/month	Free Managed Ruleset only	1 rule	Bot Fight Mode
Pro	$20/mo annual, $25/mo monthly	Cloudflare Managed Ruleset + OWASP Core Ruleset	2 rules	Super Bot Fight Mode
Business	$200/mo annual, $250/mo monthly	Full managed ruleset access + overrides	5 rules	Super Bot Fight Mode + attack score field
Enterprise	Custom quote	Full access + Attack Signature Detection	Up to 100 rules, or 100 with Advanced Rate Limiting add-on	Optional Bot Management add-on

For a personal project or low-traffic blog, the Free plan’s single Managed Ruleset is genuinely useful against the most widely exploited vulnerabilities, but it won’t give you the OWASP Core Ruleset or more than one rate limiting rule. Most production APIs and e-commerce sites need at least Pro to get the full managed ruleset stack, and anything handling payment data or regulated information should budget for Business so you get five rate-limiting rules instead of two — that’s the difference between protecting just your login endpoint and also covering password reset, checkout, and a search API separately.

Step 3: Turn On the Cloudflare Managed Ruleset

In the dashboard, go to Security → WAF → Managed rules. If you’re on Free, you’ll see only the Free Managed Ruleset, which Cloudflare describes as safe to deploy on most applications since it targets only high-impact, widely exploited vulnerabilities. Toggle it on and leave the default action in place for now.

On Pro and above, you’ll also see the Cloudflare Managed Ruleset, which is the one that picked up the Adobe Commerce and WordPress CVE detections mentioned earlier. Deploy it, but set its default sensitivity to Low for the first 48 hours. Cloudflare’s own design research into the WAF rebuild documented a recurring customer requirement: “When onboarding with Cloudflare, I want to quickly turn on the WAF and use the default settings so I can proceed to configuring the rest of the Cloudflare features,” according to Cloudflare’s own product design writeup. That default-on behavior is good for day one, but low sensitivity for the first two days gives you breathing room to watch Security Events before you start blocking real traffic.

Managed rules are regularly updated by Cloudflare’s team and specifically marketed as providing protection against newly discovered and zero-day vulnerabilities — which is exactly the mechanism that pushed out the three CVE detections from September and October 2026 without any action required from your side once the ruleset is enabled.

Step 4: Deploy the OWASP Core Ruleset and Tune Sensitivity

The OWASP Top Ten project defines the generic attack categories — SQL injection, cross-site scripting, protocol anomalies, request smuggling — that the OWASP Core Ruleset (CRS) is built to catch. Unlike the Cloudflare Managed Ruleset, which targets specific named vulnerabilities, the CRS looks for generic attack patterns, which makes it more prone to false positives on applications with unusual input formats (think rich-text editors, code-sharing tools, or anything that legitimately accepts snippets that look like SQL or JavaScript).

In Security → WAF → Managed rules, enable the OWASP Core Ruleset and start with the Anomaly Score threshold set conservatively — the dashboard presents this as a sensitivity slider rather than a raw numeric score, and Low sensitivity is the right starting point for anything handling user-generated content. Watch Security Events in Log mode for at least a few days before moving to Block, especially on routes that accept file uploads or long-form text.

A Cloudflare Security Week product panel summed up the overall WAF feature set this way: “And just to recap, so WAF will be custom rules, file rules where you define your own requirements from security access policies, rate limiting rules,” according to a Cloudflare TV product discussion. The managed rulesets and the CRS are the baseline; the custom rules layer below is where you encode knowledge specific to your own application.

Step 5: Write Your First Custom Rule With Wirefilter Syntax

Custom rules use Cloudflare’s Wirefilter expression language, documented in full in the Ruleset Engine rules language reference. The syntax combines request fields with Boolean operators, and it’s deliberately close to Wireshark’s display filter syntax if you’ve ever used that.

(http.host eq "api.example.com" and
 http.request.uri.path eq "/v1/export" and
 http.request.method eq "GET")

That expression matches a specific host, path, and method combination — useful for isolating a single expensive endpoint rather than applying a blanket rule to your whole API. A second common pattern blocks known attack tooling by user agent:

(lower(http.user_agent) contains "sqlmap" or
 lower(http.user_agent) contains "nikto" or
 lower(http.user_agent) contains "acunetix")

In the dashboard, go to Security → WAF → Custom rules, click Create rule, and either use the visual builder (which generates Wirefilter under the hood) or switch to Edit expression and paste it directly. Set the action to Log first, deploy, and give it a few hours of real traffic before switching to Block or Managed Challenge. Custom rules run before rate limiting rules in Cloudflare’s processing order, so anything you block here never reaches the rate-limit or managed-rule layers at all — which is efficient, but also means a bad custom rule can silently eat traffic that never shows up anywhere else in your analytics.

Step 6: Lock Down Login, Admin, and Checkout Endpoints

Generic managed rules catch generic attacks. The endpoints that actually get hit hardest — login forms, password reset, admin panels, checkout — need rules written specifically for them. A reasonable starting rule for an admin path most legitimate users never touch:

(http.request.uri.path contains "/wp-admin" and
 not ip.src in {203.0.113.10 203.0.113.11} and
 not cf.client.bot)

This challenges anyone hitting a WordPress admin path who isn’t on an allow-listed office or VPN IP and isn’t a verified bot (so legitimate crawlers aren’t caught). Set the action to Managed Challenge rather than an outright Block for admin paths — it stops automated credential-stuffing tools without locking out a legitimate admin who’s traveling and hitting from a new IP.

For login-specific protection, pair a custom rule that flags unusual request patterns (missing standard headers, abnormal content-length on a login POST) with the rate limiting rule you’ll build in the next step — custom rules and rate limiting are meant to work together, not as alternatives to each other.

Step 7: Configure Rate Limiting Rules for APIs and Brute Force

Rate limiting rules in Cloudflare run in the http_ratelimit phase, after custom rules, and require a matching expression, a threshold, a time period, and an action. Go to Security → WAF → Rate limiting rules and create a new rule. For a login endpoint, a sane starting threshold is five requests per IP per minute:

Expression: (http.request.uri.path eq "/login" and http.request.method eq "POST")
Characteristics: IP address
Period: 1 minute
Requests: 5
Action: Managed Challenge

The available matching fields depend on your plan: Free exposes only path and verified-bot fields, Pro adds host, URI, and query, and Business adds HTTP method, source IP, and user agent directly in the rate-limiting rule builder. If you’re on Free and need to match on method, you’ll need to combine a custom rule (which has broader field access) with a narrower rate-limiting expression.

For APIs specifically, don’t apply one rate limit to every route. Authentication endpoints, password-reset flows, and expensive search or export endpoints each deserve their own rule with their own threshold — a search endpoint can usually tolerate far more legitimate traffic than a password-reset form, so one shared limit either blocks real users on the lenient side or lets attackers through on the strict side.

Step 8: Enable Bot Fight Mode and Super Bot Fight Mode

Bot Fight Mode is available on every plan including Free and is a simple toggle under Security → Bots. It challenges traffic matching known bot signatures with no configuration required. Pro, Business, and Enterprise plans get Super Bot Fight Mode instead, which adds a configurable response per bot category — you can choose to allow verified good bots (search engine crawlers), challenge likely-automated traffic, and block known-bad bots outright, all without needing the separate Bot Management add-on.

Cloudflare assigns each request a bot score from 1 to 99 when these features are active, and that score becomes available as a field (cf.client.bot, cf.bot_management.score) you can reference in both custom rules and rate limiting expressions on plans with Bot Management enabled. Full Bot Management with granular scoring and verified-bot categories remains an Enterprise-tier product, quote-priced rather than listed publicly.

Step 9: Tune False Positives With a Log-Before-Block Workflow

This is the step most tutorials skip, and it’s the one that determines whether your WAF stays enabled past week one. Cloudflare’s own research into customer job stories found this almost universally: “When refining and tuning the configuration of my zone, I only want to configure the rules I’m interested in so I can reduce the potential number of false positive results,” per the Cloudflare WAF design blog post. The workflow that actually works:

• Deploy every new rule — managed, OWASP, or custom — in Log mode first, never straight to Block
• Give it 48 to 72 hours of real traffic before reviewing Security Events
• Filter events by rule ID, hostname, and path to separate attack traffic from legitimate edge cases
• Write narrow exceptions scoped to a specific endpoint or trusted integration rather than disabling an entire ruleset
• Re-test core user flows (login, checkout, search, file upload) after every sensitivity change, not just after the initial deployment
• Document every exception with the business reason and a review date, since undocumented exceptions accumulate into a WAF nobody trusts

Avoid the instinct to fix a false positive by disabling a whole managed ruleset. Cloudflare’s dashboard lets you override the action for a single rule ID within a ruleset, which keeps the rest of that protection intact while silencing the one rule causing trouble.

Step 10: Ship Logs to Your SIEM With Logpush and Instant Logs

Cloudflare separates logging into three tiers with different purposes. Security Events in the dashboard give you immediate, sampled-on-Free visibility for day-to-day investigation. Instant Logs provide near-real-time streaming suited to active debugging during a deployment, not long-term storage. Logpush is the durable option, built to export logs to object storage, analytics platforms, or a SIEM for retention and correlation.

Published log retention on the plans page runs up to 24 hours on Free, up to 30 days on Pro, and up to 6 months on higher paid tiers for standard analytics — which is exactly why most teams running compliance workloads push logs out to their own SIEM rather than relying on Cloudflare’s native retention window. Set up Logpush under Analytics → Logs, choosing your destination (S3-compatible storage, Splunk, Datadog, or a generic HTTP endpoint), and select the WAF-specific log fields: rule ID, action, source IP, ray ID, hostname, and path, at minimum. Correlate those events with your origin server logs using the ray ID, which is unique per request and threads through both layers.

Step 11: Automate Your WAF With Terraform — A Complete Working Project

Clicking through a dashboard works for one zone. It doesn’t scale past a handful of domains, and it leaves zero audit trail for who changed what. The Cloudflare Terraform provider lets you define every rule, ruleset, and rate limit as code. Here’s a minimal but complete working setup covering a managed ruleset, a custom rule, and a rate limiting rule for one zone.

terraform {
  required_providers {
    cloudflare = {
      source  = "cloudflare/cloudflare"
      version = "~> 5.0"
    }
  }
}

provider "cloudflare" {
  api_token = var.cloudflare_api_token
}

variable "cloudflare_api_token" {
  type      = string
  sensitive = true
}

variable "zone_id" {
  type = string
}

resource "cloudflare_ruleset" "managed_waf" {
  zone_id = var.zone_id
  name    = "deploy-managed-waf"
  kind    = "zone"
  phase   = "http_request_firewall_managed"

  rules = [
    {
      action = "execute"
      action_parameters = {
        id = "efb7b8c949ac4650a09736fc376e9aee"
        overrides = {
          action = "block"
        }
      }
      expression  = "true"
      description = "Deploy Cloudflare Managed Ruleset"
      enabled     = true
    }
  ]
}

resource "cloudflare_ruleset" "custom_rules" {
  zone_id = var.zone_id
  name    = "custom-firewall-rules"
  kind    = "zone"
  phase   = "http_request_firewall_custom"

  rules = [
    {
      action      = "block"
      expression  = "(lower(http.user_agent) contains \"sqlmap\" or lower(http.user_agent) contains \"nikto\")"
      description = "Block known scanner tooling"
      enabled     = true
    },
    {
      action      = "managed_challenge"
      expression  = "(http.request.uri.path contains \"/wp-admin\" and not cf.client.bot)"
      description = "Challenge non-bot traffic to admin path"
      enabled     = true
    }
  ]
}

resource "cloudflare_ruleset" "rate_limit_login" {
  zone_id = var.zone_id
  name    = "rate-limit-login"
  kind    = "zone"
  phase   = "http_ratelimit"

  rules = [
    {
      action      = "managed_challenge"
      expression  = "(http.request.uri.path eq \"/login\" and http.request.method eq \"POST\")"
      description = "Rate limit login POST requests"
      enabled     = true
      ratelimit = {
        characteristics     = ["cf.colo.id", "ip.src"]
        period              = 60
        requests_per_period = 5
        mitigation_timeout  = 600
      }
    }
  ]
}

Run terraform init, then terraform plan to review exactly which rules will be created before anything touches production, and terraform apply to deploy. Store the state file remotely (an S3 backend or Terraform Cloud) rather than locally, since a lost state file for a WAF configuration means re-auditing every rule by hand. If you’re also scanning this Terraform code for misconfigurations before it merges, an IaC scanner catches things a manual review misses — this site’s own Checkov setup walkthrough covers that exact workflow for Terraform specifically.

Putting It All Together: A Complete Working Project

To see the whole setup as one coherent system rather than a list of disconnected steps, walk through a concrete example: a small Node.js API at api.example.com serving a login endpoint, a password-reset endpoint, and a public search endpoint, fronted entirely by Cloudflare. The complete project has four moving parts, each covered earlier in this tutorial, now wired together.

First, DNS: the api.example.com A record is proxied (orange cloud) and points at the origin server’s private load-balancer IP, never the raw public IP of the application server itself. Second, the origin lockdown: the application server’s own firewall accepts inbound HTTPS traffic only from Cloudflare’s published IP ranges, enforced at the infrastructure level so even a leaked origin IP is useless to an attacker. On a Linux box running nginx as a reverse proxy in front of the Node app, that allow-list looks like this:

# /etc/nginx/conf.d/cloudflare-allowlist.conf
# Generated from Cloudflare's published IPv4/IPv6 ranges
geo $cf_allowed {
    default 0;
    173.245.48.0/20 1;
    103.21.244.0/22 1;
    103.22.200.0/22 1;
    103.31.4.0/22 1;
    141.101.64.0/18 1;
    108.162.192.0/18 1;
    190.93.240.0/20 1;
    188.114.96.0/20 1;
    197.234.240.0/22 1;
    198.41.128.0/17 1;
    162.158.0.0/15 1;
    104.16.0.0/13 1;
    104.24.0.0/14 1;
    172.64.0.0/13 1;
    131.0.72.0/22 1;
}

server {
    listen 443 ssl;
    server_name api.example.com;

    if ($cf_allowed = 0) {
        return 403;
    }

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header X-Real-IP $http_cf_connecting_ip;
    }
}

Third, the WAF layer from the Terraform configuration in Step 11: the Cloudflare Managed Ruleset blocking the CVE-tagged signatures from the September and October 2026 releases, a custom rule challenging scanner tooling and non-bot admin-path traffic, and a rate-limiting rule capping login attempts at five per minute per IP. Fourth, the observability layer from Step 10: Logpush exporting every WAF decision, tagged with its rule ID and ray ID, to a SIEM where it’s correlated against the Node app’s own access logs using that same ray ID.

With all four pieces live, a credential-stuffing attempt against /login gets challenged by the rate-limiting rule after five requests, an SQL injection attempt against the search endpoint’s query parameter gets blocked by the OWASP Core Ruleset before it reaches the Node process at all, and a direct connection attempt to the origin’s public IP — bypassing Cloudflare entirely — gets dropped by nginx’s geo-based allow-list before it even reaches the application layer. None of the three protections depends on the others, which is the point: a gap in one layer doesn’t mean the whole project fails.

Step 12: Test, Monitor, and Maintain Your Rules Over Time

Before considering the setup done, test every rule against both attack traffic and legitimate traffic patterns. A quick manual check from the command line confirms a block rule is actually live:

curl -A "sqlmap/1.7" -I https://example.com/login
# Expect a 403 or a challenge page, not a normal 200

Beyond that single curl check, run your normal application test suite against staging with the same ruleset applied, since staging is where you catch a rule blocking your own monitoring tool or a third-party webhook before it blocks a paying customer. Once live, review Security Events weekly for the first month, then monthly after that, and specifically re-test after every managed-ruleset version bump — Cloudflare’s changelog, available at developers.cloudflare.com/waf/change-log, lists every rule addition and action change, including the three CVE-driven updates from September and October 2026 referenced earlier.

Common Pitfalls When Setting Up Cloudflare WAF

Most WAF incidents trace back to a handful of repeated mistakes, not exotic attack patterns:

• DNS-only records that bypass the WAF entirely. A gray-cloud DNS record means Cloudflare isn’t proxying that traffic, so no rule applies regardless of configuration.
• Jumping straight to Block mode. Deploying a new managed ruleset or custom rule directly to Block, without a Log-mode observation window, is the single most common cause of broken checkout flows reported in Cloudflare community threads.
• Origin servers that don’t restrict traffic to Cloudflare IP ranges. If an attacker finds your real origin IP, they route around the WAF completely, making every rule you wrote irrelevant.
• Disabling an entire ruleset to fix one false positive. This throws away unrelated protection instead of overriding the single problematic rule ID.
• Treating rate limiting and custom rules as interchangeable. Rate limiting controls volume; custom rules control pattern-matching. Using one where you need the other leaves a gap.
• Forgetting that free-tier rate limiting caps out at one rule. Teams on Free sometimes assume they can protect login, checkout, and an API with separate thresholds, then discover mid-incident they only ever had one slot.
• Not testing after managed-ruleset updates. A rule that silently changes from Log to Block in a Cloudflare changelog entry — as happened with the command-injection rule on October 9, 2026 — can surface a false positive you never saw during initial tuning.

Cloudflare WAF vs AWS WAF vs ModSecurity: Which Fits Your Stack

The right choice depends heavily on where your traffic already lives and how much operational overhead your team can absorb.

Factor	Cloudflare WAF	AWS WAF	ModSecurity
Deployment model	Global edge/CDN, DNS-based onboarding	Regional, tied to CloudFront, ALB, or API Gateway	Self-hosted module on your own web server or proxy
Rule maintenance	Cloudflare-managed, auto-updated rulesets	AWS Managed Rules, versioned (CRS reached static v1.23 in Aug. 2026)	You maintain CRS or third-party rule updates yourself
Best fit	Sites/APIs wanting integrated CDN, DDoS, bot, and WAF in one place	Teams already standardized on AWS governance and CloudWatch	Teams needing full on-prem control or embedded gateway enforcement
Operational load	Low — dashboard or Terraform, no server maintenance	Moderate — native AWS IAM/Firewall Manager integration required	High — you own capacity, tuning, and update cadence

Cloudflare’s main practical edge is bundling WAF, DDoS mitigation, bot management, and rate limiting into one globally distributed control plane, which is why it tends to win for teams that don’t want to stitch together separate AWS or open-source tooling. AWS WAF makes more sense when your entire stack is already AWS-native and you want Firewall Manager, CloudWatch, and IAM policy to govern the WAF the same way they govern everything else. ModSecurity remains the right call when you need an on-premises deployment or embedded gateway enforcement that neither cloud vendor can offer. If your team is evaluating broader secure access service edge options alongside WAF, it’s worth reading how Cloudflare One stacks up against Zscaler and Netskope for a wider security-edge comparison, and if CDN cost is the deciding factor rather than WAF depth, this breakdown of Cloudflare against BunnyCDN and Fastly pricing is worth checking before you commit to a plan tier.

Troubleshooting Cloudflare WAF Issues

Even a carefully tuned WAF throws up issues. Here’s how to work through the most common ones:

• Legitimate users getting blocked on login: Check Security Events filtered to the login path, identify the specific rule ID firing, and add a narrow override rather than disabling OWASP CRS entirely.
• A rule isn’t firing at all: Confirm the DNS record for that hostname is proxied (orange cloud), not DNS-only — this is the most common silent failure.
• Rate limiting rule shows zero matches despite obvious abuse: Verify the expression’s field availability matches your plan tier; a Free-plan rule referencing method or user-agent fields it doesn’t support will silently fail to match.
• 403 errors on API calls from a trusted partner integration: Check whether a bot-management or anomaly rule is misclassifying the partner’s server-to-server requests as bot traffic, and add an IP-based exception.
• Checkout flow breaks after an OWASP CRS sensitivity change: Roll sensitivity back to the previous level immediately, then re-tune in Log mode rather than live.
• Terraform plan shows unexpected rule drift: Someone made a dashboard change outside of Terraform; run terraform plan regularly and treat the dashboard as read-only once you adopt IaC.
• Logpush job stops delivering logs: Check the destination credentials first — expired S3 tokens or rotated Splunk HEC tokens are the most frequent cause, not a Cloudflare-side outage.
• Custom rule blocks your own uptime monitor: Add an allow-list rule for your monitoring service’s published IP ranges and user agent, placed before the blocking rule in evaluation order.
• Managed ruleset update introduces a new false positive: Cross-reference the date against the WAF changelog to confirm whether a specific rule action changed, then override that rule ID specifically.

Advanced Tips for Production WAF Deployments

Once the baseline setup is stable, a few refinements separate a functional WAF from a genuinely resilient one. Layer your custom rules by cost: cheap, high-confidence blocks (known scanner user agents) should run before expensive checks (bot-score evaluation), since Wirefilter evaluates in order and short-circuits on a match. Use rule labels and the cf.waf.score or attack-score field, where your plan supports it, to build a composite scoring rule instead of relying on any single signal — combining a moderate bot score with a suspicious path match catches more than either alone while reducing false positives from either signal in isolation.

For teams running both a WAF and a static analysis pipeline, treat them as complementary rather than redundant: a WAF catches exploitation attempts against known and newly disclosed vulnerabilities in near-real time, while a tool like Semgrep catches the vulnerable code pattern before it ships at all. Running a scanner such as Nuclei against your own endpoints on a schedule also tells you which CVEs your stack is actually exposed to, which helps prioritize which managed-ruleset categories to watch most closely in the changelog. Finally, if you manage more than a handful of zones, build a Terraform module once and parameterize it per zone rather than copy-pasting rule blocks — configuration drift across dozens of hand-edited zones is how a WAF that was solid on day one quietly rots within a year.

Frequently Asked Questions

Is Cloudflare WAF free?
The Free plan includes the Free Managed Ruleset, custom rules, one rate-limiting rule, and Bot Fight Mode at no cost. The Cloudflare Managed Ruleset and the OWASP Core Ruleset require at least the Pro plan at $20/month billed annually.

Does Cloudflare WAF protect against DDoS attacks too?
WAF and DDoS mitigation are separate but complementary systems within Cloudflare. DDoS protection is included automatically on all plans and operates independently of WAF rule configuration, while WAF specifically inspects application-layer request content.

How long does it take for a new WAF rule to take effect?
Rule changes propagate across Cloudflare’s network typically within seconds to a couple of minutes, which is one of the clearest advantages over patching a self-hosted module across multiple servers.

Can Cloudflare WAF protect an API that isn’t behind a traditional website?
Yes. As long as the API’s DNS record is proxied through Cloudflare (orange cloud), the same managed rulesets, custom rules, and rate limiting apply to API traffic exactly as they do to standard web traffic.

What’s the difference between the Cloudflare Managed Ruleset and the OWASP Core Ruleset?
The Cloudflare Managed Ruleset targets specific, named vulnerabilities (such as the CVE-tagged detections added in September and October 2026), while the OWASP Core Ruleset applies generic attack-pattern detection across broader categories like SQL injection and cross-site scripting, with a higher general false-positive rate.

Should I use Block or Managed Challenge as my default action?
Start new rules in Log mode, move to Managed Challenge once you’ve confirmed low false-positive rates, and reserve outright Block for high-confidence signatures like known scanner tooling or confirmed malicious IP ranges.

Do I need Terraform to use Cloudflare WAF, or is the dashboard enough?
The dashboard is sufficient for a single zone with infrequent changes. Terraform becomes worthwhile once you’re managing multiple zones, want a change audit trail, or need to replicate an identical rule set across staging and production environments.

How does Cloudflare decide which traffic counts as a bot for Bot Fight Mode?
Cloudflare assigns a bot score from 1 to 99 based on request signals including TLS fingerprinting, request headers, and behavioral patterns; Bot Fight Mode and Super Bot Fight Mode use that score with plan-specific configurable responses, while full granular control over the scoring model itself requires the Enterprise Bot Management add-on.

Related Coverage

• Set Up Checkov for IaC Security Scanning: 13 Steps [2026]
• Set Up Semgrep SAST Scanning: 13 Steps, $40/Mo Tier [2026]
• Nuclei Scanner Setup: 13 Steps, 295 Templates [2026]
• EA Javelin Anti-Cheat Setup: 13 Steps, Kernel Fixes [2026]
• Zscaler vs Netskope vs Cloudflare One: 80-DC Gap [2026]