What should a small-business WAF actually block?

Traffic with no plausible legitimate purpose: known-bad sources, obvious injection patterns, and automated hammering of login or form endpoints. Beyond that, rules become a false-positive generator, and a blocked customer costs more than most of the traffic being stopped.

How should bot score be used?

As an input to a graduated response rather than a switch. Challenge the middle range, block only the clearly automated, and leave the rest alone. Treating the score as a binary is what produces the reports of customers being blocked while the spam continues.

Which bots must be allowed through?

Search engine crawlers, the AI crawlers you want to index you, monitoring and uptime services, and any partner integration that fetches your pages. All of them look automated because they are, and blanket bot blocking removes you from search and from assistant answers with no error anywhere.

What should not be blocked by default?

Anything you cannot name a threat model for. Default-deny is right for a database and wrong for a public marketing site, whose entire purpose is to be fetched. The cost of over-blocking here is invisible: nobody reports the customer who could not reach you.

How do I know a rule is causing harm?

Watch blocked-request volume alongside enquiry volume. A rule that fires constantly on a form endpoint is either stopping a real attack or stopping real customers, and only sampling the blocked requests tells you which. A rule nobody reviews is a rule nobody can defend.

What is Page Shield for?

Watching which client-side scripts your pages actually load, so an unexpected third-party script appearing is visible. That is the class of compromise most sites never notice, because it works perfectly for the attacker and looks like nothing from the server side.

Do I need to configure DDoS protection?

The baseline is already on and covers the ordinary case. What benefits from attention is rate limiting on the specific endpoints that hurt when abused, meaning login, forms, and search. Those are application-shaped decisions rather than network ones.

How should form endpoints be protected?

In layers: a honeypot field, a verification check, rate limiting per address, and server-side validation. Each is cheap and each catches a different class. Relying on one control means the day it fails you learn about it from your inbox.

When will a WAF not save you?

When the vulnerability is in your own application logic, when credentials have leaked, or when the abuse is a human doing legitimate-looking things. A firewall filters traffic patterns; it does not fix an endpoint that trusts input or a key that is already public.

How often should rules be reviewed?

Quarterly, and after any report of a customer being unable to reach the site. Rules accumulate, the reason for each is forgotten, and the set slowly becomes something nobody will touch for fear of breaking it, which is when it starts causing more harm than it prevents.

Should managed rule sets be enabled wholesale?

Not without watching what they catch first. Run in a logging mode, review a week of matches, then enforce the ones with clean records. Enabling everything on day one is the fastest route to blocking a legitimate integration you did not know existed.

What is the biggest risk of over-configuring security?

Silence. Every failure mode here is quiet: a search engine that stops crawling, an assistant that stops citing you, a customer who assumed you were out of business. Unlike an outage nobody pages you, which is why review cadence matters more than rule count.

Cloudflare DevOps How-to

Cloudflare WAF and Bot Management for SMB Sites: The Rules That Actually Work

WAF isn’t set-and-forget. Here’s the configuration that catches the real attacks without breaking legitimate traffic.

John Cravey with AIFounderMar 25, 20265 min readUpdated Jul 6, 2026

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.

Free estimate · 2 minutes

Read the playbook. Now see it for your business.

The posts are the mechanism. The estimate below sketches the version we'd actually ship for your business, at your scale. About a minute, no opt-in.

#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: Challenge

#Custom 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 Challenge

#Custom 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 Challenge

#Custom 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: Block

#Bot 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.

Answers

Frequently asked questions

What should a small-business WAF actually block?: Traffic with no plausible legitimate purpose: known-bad sources, obvious injection patterns, and automated hammering of login or form endpoints. Beyond that, rules become a false-positive generator, and a blocked customer costs more than most of the traffic being stopped.
How should bot score be used?: As an input to a graduated response rather than a switch. Challenge the middle range, block only the clearly automated, and leave the rest alone. Treating the score as a binary is what produces the reports of customers being blocked while the spam continues.
Which bots must be allowed through?: Search engine crawlers, the AI crawlers you want to index you, monitoring and uptime services, and any partner integration that fetches your pages. All of them look automated because they are, and blanket bot blocking removes you from search and from assistant answers with no error anywhere.
What should not be blocked by default?: Anything you cannot name a threat model for. Default-deny is right for a database and wrong for a public marketing site, whose entire purpose is to be fetched. The cost of over-blocking here is invisible: nobody reports the customer who could not reach you.
How do I know a rule is causing harm?: Watch blocked-request volume alongside enquiry volume. A rule that fires constantly on a form endpoint is either stopping a real attack or stopping real customers, and only sampling the blocked requests tells you which. A rule nobody reviews is a rule nobody can defend.
What is Page Shield for?: Watching which client-side scripts your pages actually load, so an unexpected third-party script appearing is visible. That is the class of compromise most sites never notice, because it works perfectly for the attacker and looks like nothing from the server side.
Do I need to configure DDoS protection?: The baseline is already on and covers the ordinary case. What benefits from attention is rate limiting on the specific endpoints that hurt when abused, meaning login, forms, and search. Those are application-shaped decisions rather than network ones.
How should form endpoints be protected?: In layers: a honeypot field, a verification check, rate limiting per address, and server-side validation. Each is cheap and each catches a different class. Relying on one control means the day it fails you learn about it from your inbox.
When will a WAF not save you?: When the vulnerability is in your own application logic, when credentials have leaked, or when the abuse is a human doing legitimate-looking things. A firewall filters traffic patterns; it does not fix an endpoint that trusts input or a key that is already public.
How often should rules be reviewed?: Quarterly, and after any report of a customer being unable to reach the site. Rules accumulate, the reason for each is forgotten, and the set slowly becomes something nobody will touch for fear of breaking it, which is when it starts causing more harm than it prevents.
Should managed rule sets be enabled wholesale?: Not without watching what they catch first. Run in a logging mode, review a week of matches, then enforce the ones with clean records. Enabling everything on day one is the fastest route to blocking a legitimate integration you did not know existed.
What is the biggest risk of over-configuring security?: Silence. Every failure mode here is quiet: a search engine that stops crawling, an assistant that stops citing you, a customer who assumed you were out of business. Unlike an outage nobody pages you, which is why review cadence matters more than rule count.

Question we did not answer? Ask us directly and we will answer it here.

Tagged#Cloudflare #DevOps #How-to

Written by

John Cravey

Founder

Founder of Frontend Horizon. Writes most of the long-form work on the FH blog.