What Cloudflare's Free Plan Actually Gives You for WAF (It's Less Than You'd Think)

This one's a "here's what I found," not a "here's what I built" — worth saying up front, because the honest answer matters more than a tidier story. I went to check and configure Web Application Firewall protection on Tabeer.ai's Cloudflare zone. No WAF rules got added, because two separate limitations made that impossible with what was available at the time, and both are worth knowing before you assume WAF is "just on" because a domain sits behind Cloudflare.

Limitation One: Token Scope

The API token available for this zone was provisioned for DNS management — reading and writing dns_records. That's a genuinely useful, narrowly-scoped token (see the DNS incident it was enough to resolve on its own), but it has no Firewall Services permission. Every attempt to read WAF configuration failed:

curl -H "Authorization: Bearer $CF_TOKEN" \
  "https://api.cloudflare.com/client/v4/zones/$ZONE/rulesets/phases/http_request_firewall_managed/entrypoint"
# {"success":false,"errors":[{"code":10000,"message":"Authentication error"}]}

curl -H "Authorization: Bearer $CF_TOKEN" \
  "https://api.cloudflare.com/client/v4/zones/$ZONE/firewall/rules"
# {"success":false,"errors":[{"code":10000,"message":"Authentication error"}]}

Both security_level and the legacy firewall/rules endpoint returned the same authentication error, distinct from a 403 — this is the API correctly saying "this token can't do this," not "this zone has no rules." A token scoped for one part of a Cloudflare zone (DNS) genuinely cannot see or touch another part (Firewall), which is good practice from Cloudflare's side, but means you can't assume one working token gets you everywhere in the dashboard's equivalent.

Limitation Two: The Plan Itself

Even with a properly-scoped token, the zone is on Cloudflare's Free plan, and Free does not include the Managed WAF Ruleset — the actual rule set that inspects requests for SQL injection, XSS, known CVE exploitation patterns, and so on. That's a Pro-and-above feature.

What Free does include:

• Security Level (Essentially Off / Low / Medium / High / Under Attack) — a blunt, single-dial setting that adjusts how aggressively Cloudflare challenges suspicious-looking traffic, not rule-based inspection.
• Basic DDoS mitigation — always on, not configurable, not the same thing as a WAF.
• A small allotment of free custom rules — Cloudflare has expanded what Free gets here over time, but it's you writing specific match conditions by hand, not a maintained, continuously-updated ruleset covering known attack patterns.

If a site's actual threat model includes things like SQLi/XSS probing, credential stuffing, or bot traffic hitting login/checkout flows specifically, "it's behind Cloudflare" is not the same claim as "it has a WAF" unless the plan actually includes one.

What I'd Actually Recommend

1. Check the dashboard directly, not just the API — Security → WAF will show plainly what's active and what's plan-gated for any given zone, without needing a token with the right scope at all.
2. If Free is intentional (cost-sensitive early-stage project, low actual attack surface), at minimum set Security Level to Medium or High and add a handful of free custom rules for the endpoints that matter most — a login route, a payment webhook, anything mutating data from an unauthenticated request.
3. If real protection is the goal, budget for Pro — it's the tier where the Managed Ruleset actually turns on, and it's a small monthly cost relative to what a single successful injection or credential-stuffing run against an unprotected endpoint can cost.
4. Provision a properly-scoped token (Zone.Firewall Services, at minimum read) for whoever needs to audit or manage this going forward, separate from a DNS-only token — least-privilege access is correct practice, but only if the right privilege actually gets granted to someone who needs it.

If you're auditing what your Cloudflare plan actually protects against — versus what you assumed it did — get in touch.