The Cloudflare WAF (Web Application Firewall) ships with sensible defaults. Most SMBs leave it at defaults and never look at it again. That’s fine until the day someone starts probing your contact form for SQL injection or your login for credential stuffing. The default rules catch the obvious. Real protection requires a handful of custom rules tuned to your stack and traffic patterns. Here’s what we configure on every FH client site.
What the managed ruleset catches by default
Cloudflare’s managed ruleset is updated continuously by their security team. On the free plan you get a basic ruleset; on Pro you get the “Cloudflare Managed Ruleset” and the “OWASP Core Ruleset.” Between them they catch SQL injection, XSS, path traversal, command injection, and the common CVE-driven attacks (Log4Shell, Spring4Shell, etc.) automatically.
We enable both on every FH Pro site. Combined false-positive rate is under 0.01% in our traffic — too low to matter for SMB volumes.
Custom rule 1: rate-limit POST to /api/* and form endpoints
Most attacks against SMB sites target the same handful of endpoints — the contact form, the login form, any `/api/*` route. Rate-limit them. We use 10 requests per minute per IP for form endpoints, 30 for `/api/*` reads, 5 for `/api/*` writes.
(http.request.method eq "POST")
AND (http.request.uri.path matches "^/(api|contact|login)")
Then: Rate-limit (10 per minute per IP), Action: ChallengeCustom rule 2: challenge requests with no User-Agent
Legitimate browsers always send a User-Agent. Bots that don’t bother to set one are low-effort and worth challenging. Some legitimate tools (curl, monitoring scripts) also don’t set UAs by default — we exception those by IP.
(http.user_agent eq "")
AND NOT (ip.src in {1.2.3.4 5.6.7.8})
Then: Managed ChallengeCustom rule 3: block known-bad bot UAs
Some bots identify themselves in the UA and you can block them outright. Common ones: ahrefsbot if you don’t want to be in Ahrefs’ index, semrushbot for the same reason, or specific scrapers known to hammer your site. We don’t block legitimate SEO bots (Googlebot, Bingbot) — those help us.
Custom rule 4: country-level rules
If your business is local to North America and you have no reason to serve traffic from, say, Russia or China, challenge requests from those countries on sensitive endpoints. This isn’t about blanket nationalism — it’s about saying “my SMB lead form has no legitimate audience in country X, so I’ll add friction there.”
(http.request.uri.path matches "^/(contact|admin|login)")
AND (ip.geoip.country in {"RU" "CN" "KP" "IR"})
Then: Managed ChallengeCustom rule 5: known-bad request patterns
Block requests for paths that have no legitimate use on your site. WordPress login probes (`/wp-login.php`), `.env` access attempts, `.git` directory scans, etc.
(http.request.uri.path matches "^/(wp-login\\.php|wp-admin|\\.env|\\.git|phpmyadmin)")
Then: BlockBot Score and how to use it
Cloudflare Pro and above assign a bot score from 1 (almost certainly a bot) to 99 (almost certainly human) to every request. The score appears in the `cf.bot_management.score` field in rules. We use it for nuanced rules: challenge bot scores under 30 on form pages, block under 10 on login pages.
Whitelisting legitimate bots
Search engine crawlers (Googlebot, Bingbot), uptime monitors (Pingdom, UptimeRobot), social previews (Twitter, LinkedIn) should all be allowlisted. Cloudflare’s “Verified Bots” categorization handles most of these automatically — make sure your rules don’t challenge verified bots. We add a custom rule at the top: `cf.bot_management.verified_bot is true → Skip remaining rules`.
What we DON’T block by default
- Specific IPs — IPs rotate, blocklists go stale. We block IPs only during active incidents.
- Entire user agent strings unless they’re obviously malicious. Legitimate scrapers can have weird UAs.
- Anything that breaks legitimate users 0.1% of the time. False positives compound; the cost of one missed lead is high.
Watching the dashboard
Cloudflare’s Security → Events tab shows everything the WAF caught — which rules fired, which IPs, which countries, what response. We check it weekly across the client book. The patterns repeat (same five attacker IPs probing the same five endpoints) and the volume tells us if we need a new rule or to tighten an existing one.
Page Shield: client-side script monitoring
Page Shield (Cloudflare Pro+) monitors every JavaScript file loaded by your site and alerts when a new domain shows up. This is how you catch a third-party script being hijacked (Magecart-style) or a CDN compromise. We enable it on every site. False positives are zero across the FH client book; it’s a no-cost win.
DDoS protection: it’s already on
Cloudflare’s DDoS protection runs automatically. We’ve been hit by L7 DDoS twice in the last 12 months across the client book — both were stopped at the edge without anyone needing to look at it. The free plan covers L3/L4 DDoS unconditionally; Pro covers L7.
When the WAF won’t save you
Application-layer logic bugs. A WAF can’t catch a misconfigured RLS policy that lets one tenant read another’s data. It can’t catch a server action that trusts the client’s claimed `site_id`. It can’t catch an exposed admin endpoint with no auth. Those are app-level issues that need app-level fixes — the WAF is the perimeter, not the building.
How this lands across FH client work
Every FH client site has the same six-rule set: rate-limit forms, challenge no-UA, block known-bad bot UAs, country-rules on sensitive paths, block bad URL patterns, allow verified bots. Configuration once, maintenance ten minutes monthly. If your site is unprotected or you’re running custom WAF logic that’s never been reviewed, book a consultation — the audit is a half-day engagement that almost always finds something.
