Cloudflare WAF Rules Every Business Website Should Consider

A lot of business websites are “on Cloudflare” in the sense that DNS goes through it and the orange cloud is on. That gets you a CDN and DDoS absorption, which is worth having. It does not, by itself, stop the traffic that actually causes problems for a small business site: credential stuffing against the login page, vulnerability scanners probing for known plugin bugs, and bots hammering uncached pages until PHP falls over.

These are the rules we apply, roughly in order of value. Most are available on the free plan. None of them require you to understand Cloudflare’s full feature set.

First: make sure the WAF can’t be bypassed

Before any rule matters, the origin server must only accept traffic that came through Cloudflare. If the server’s real IP is public and answers directly, an attacker (or a scanner that found the IP in an old DNS record or a certificate transparency log) simply talks to it and every rule below is decoration.

Restrict the origin’s firewall to Cloudflare’s published IP ranges, or use Cloudflare Tunnel so the origin has no public inbound port at all. Then confirm it: from outside, try to load the site by IP address. It should fail.

1. Managed rules: on

Cloudflare maintains rulesets that block known exploit patterns — SQL injection, remote file inclusion, known CVE signatures for popular software. On paid plans this is the “Cloudflare Managed Ruleset” and, for WordPress sites, the OWASP Core Ruleset at a moderate sensitivity. On the free plan you get a smaller “Free Managed Ruleset” that still covers a lot.

Turn them on. Start in log mode for a week if the site has unusual traffic (an API, a mobile app), then switch to block. For a typical brochure or e-commerce site, blocking from day one is fine.

2. Rate limit the login and XML-RPC endpoints

This is the single highest-value rule for WordPress. Brute-force and credential-stuffing attacks against /wp-login.php and /xmlrpc.php are continuous, automated and cheap for the attacker. Each attempt is an uncached PHP request, so they cost you server capacity as well as risk.

A rate-limiting rule: if a single IP makes more than, say, 5 requests to /wp-login.php in one minute, block that IP for ten minutes. Legitimate users mistype a password twice, not fifty times. A similar rule for /xmlrpc.php — or, if nothing uses XML-RPC (the Jetpack app and a few mobile clients do; most sites don’t), block it outright with a custom rule.

3. Challenge or block obvious scanners

Custom rules using the request’s user agent, path and Cloudflare’s own bot score. The patterns we see constantly on business sites:

• Requests for .env, .git/, wp-config.php.bak, phpinfo.php, and other files that should never be requested by a browser. Block.
• Requests to /wp-admin/ or /wp-login.php from countries the business never does business with. Managed Challenge (a lightweight, usually invisible check), not a block — the owner might travel.
• Empty or clearly fake user agents. Managed Challenge.
• Any request with a bot score below a threshold that is not from a verified crawler (Google, Bing). Managed Challenge on paid plans; on the free plan, the “Bot Fight Mode” toggle does a coarser version of this.

The aim is not to block every bot. It is to stop the cheap, noisy ones from reaching PHP at all, so the server’s resources go to visitors and the logs are readable.

4. Protect the admin with an extra layer

For sites with a small, known set of administrators, put /wp-admin/ and /wp-login.php behind Cloudflare Access (Zero Trust). A person must authenticate with their Google or Microsoft account — or a one-time code to an allowed email — before the request ever reaches WordPress. Unauthorized traffic never sees the login form, which removes the entire class of login attacks.

Access is free for up to 50 users. It is the closest thing to a silver bullet on this list, and it is under-used because it lives in a different part of the dashboard.

5. Cache more, expose less

Not strictly WAF rules, but they belong in the same review:

• Cache rules for static assets with long edge TTLs, and — carefully — for anonymous HTML on sites where that is safe. Every cached response is one the origin never sees.
• SSL mode: Full (strict). “Flexible” mode means Cloudflare talks to your origin over plain HTTP, which is a problem in itself and a common cause of redirect loops.
• Hide the origin in headers and errors. The origin’s error pages and Server header should not reveal the real host or IP.

6. Watch what the rules do

Security Events (Security → Events in the dashboard) shows every blocked, challenged and logged request. Check it after enabling anything new, and again a week later. Two things to look for: legitimate traffic being caught (a customer’s country being challenged, a payment webhook being blocked), and a pattern of attacks that suggests a rule you don’t yet have.

A realistic sequence

If you do these in order over an afternoon — lock the origin, enable managed rules, rate-limit the login, block the scanner paths, put Access on the admin — a typical WordPress business site goes from receiving thousands of attack requests a day at the server to receiving almost none. The server gets faster, the logs get quieter, and the next plugin vulnerability has a much smaller window to be exploited.

This is part of what managed IT and website management covers for our clients: setting these up, reviewing the events, and adjusting the rules as the attacks change. If you are checking your own setup, items 18 and 19 on the Website & Infrastructure Health Checklist are the ones to look at.