00 · Before you start
Three things to do before you write a single rule.
A WAF that blocks a real customer is worse than no WAF, because nobody will tell you it happened. They will just leave. The same principle runs through all of our WordPress security work.
Capture a baseline
Let Cloudflare run in front of your site for 24 to 48 hours with nothing configured beyond the defaults, then look at the firewall analytics. You need to know what normal traffic looks like on your site before you decide what abnormal looks like.
RuleWithout this you have no way of knowing whether anything you do afterwards worked.
Map your dynamic pages
List every URL that must never be cached and every endpoint that handles authentication or form submission. Login, registration, checkout, cart, account pages, application forms, anything posting data. You will need this list twice, once for cache rules and once for rate limits.
Know what your site talks to
Every third-party integration, API and webhook, with the IPs or user agents they use if you can get them. These are what a badly scoped rule breaks first, and it breaks them silently.
01 · SSL and managed rulesets
Get the transport right, then turn the rulesets on in log mode.
Stage 1
SSL and TLS
SSL mode Full (Strict), because Flexible is a security hole that looks like encryption and Full without Strict does not verify your origin certificate. Minimum TLS 1.2. HSTS enabled, starting with a short max-age since it is difficult to reverse. Automatic HTTPS rewrites and Always Use HTTPS on. Verify with an independent SSL test rather than trusting the dashboard.
Stage 2
Managed rulesets
Cloudflare Managed Ruleset on. OWASP Core Ruleset on, starting at a moderate sensitivity. WordPress platform ruleset on if your plan includes it. Then the step everyone skips: set the sensitive rules to Log, not Block, and leave them there for at least a few days. Read the logs, looking for legitimate traffic being caught: your own admin activity, your integrations, your payment provider callbacks. Only move rules to Block once the logs are clean.
Deploying the OWASP ruleset straight to Block on a busy site is how you find out at 5pm that your checkout has been failing since lunchtime.
02 · Rate limiting
Four rules, not one.
Test each one individually by deliberately triggering it, then confirm normal use does not. The admin rule is the one most likely to catch your own people.
03 · Custom rules
The WordPress-specific ones. Deploy them one at a time.
Block XML-RPC
The xmlrpc.php endpoint is one of the most abused in WordPress, used for brute force amplification and pingback-based attacks. Almost no modern site needs it. Check first whether you use the Jetpack mobile app or any service that authenticates through XML-RPC, because those will break.
Block sensitive file extensions
Requests for .env, .git, .sql, .bak, .log and similar. These files should not be publicly reachable in the first place, and a steady stream of requests for them is normal background scanning. Blocking them at the edge means the scanning does not cost you anything.
Block empty user agents
Legitimate browsers and crawlers identify themselves. An empty user agent is almost always automated and almost never something you want. Low risk rule.
Block known malicious user agents
Maintain a list of scanners and exploit tools. Moderate value, needs occasional updating.
Block suspicious URI patterns
Path traversal sequences, SQL injection patterns in query strings, common exploit paths.
RuleTest this one carefully. Overly broad patterns will catch legitimate URLs, especially on sites with search functionality or complex query strings.
Restrict admin access by IP
The strongest rule available and the most disruptive. Only workable where the team has static IPs or works from a defined set of locations.
RuleIf people work from home, from cafes or from mobile networks, this will lock them out and you will be the one they call.
Geographic restriction
If your business only serves certain markets, blocking everywhere else removes an enormous share of attack traffic at no commercial cost. Test from multiple countries with a VPN before going live.
RuleThis also blocks crawlers, monitoring services and integration partners operating from blocked regions. Allowlist them explicitly.
05 · Headers, bots, verification
The last three stages, in this order.
Security headers
X-Frame-Options set to DENY, or SAMEORIGIN if you embed your own pages. X-Content-Type-Options set to nosniff. Referrer-Policy set to strict-origin-when-cross-origin. A Permissions-Policy denying the browser features your site does not use.
RuleVerify in browser developer tools. A header configured in the dashboard is not the same as a header actually arriving.
Bot handling
Deliberately last, because this is where blanket settings do the most damage. Do not simply raise a global bot protection level. Verify the good bot allowlist covers search engine crawlers, then handle individual crawlers by name based on measured traffic.
Functional testing
Every page loads. Every form submits. Checkout completes. Logins work. Integrations sync. Mobile renders. Do this logged out, in a private window, from a normal connection.
Traffic verification
Confirm that all traffic is actually routing through Cloudflare. If DNS records are not proxied correctly, some requests reach your origin directly and none of your rules apply to them. Compare request volume at the edge against what your server logs see.
RuleYour rules will look perfect in the dashboard while doing nothing to a share of your traffic.
06 · Deployment order
Each step verified before the next.
It is slower, and it is the difference between a configuration that works and one that quietly costs you customers. If you would rather not spend the fifteen hours, that is what our Cloudflare setup service covers. And if you are reading this because the site is under attack right now, go to emergency response first and come back to the rules afterwards.
This checklist is reference material behind our WordPress security work. Keeping the ruleset current after deployment sits with maintenance.
Common questions
Which of these need Cloudflare Pro?+
The managed WAF rulesets and detailed firewall analytics are the main ones. Rate limiting is available on the free plan but with fewer rules and less control. Basic custom rules, cache rules and SSL configuration all work on free. If your site takes payments or applications, Pro is generally worth it.
Will these rules break my site?+
Some of them will, if deployed all at once without testing. That is why the order and the log-first approach matter more than the rule list. The three most likely to cause trouble are admin IP restriction, geographic blocking and broad URI pattern rules.
Do I still need a security plugin?+
Less than you did. Edge filtering rejects requests before they reach your server, which a plugin cannot do because it runs after WordPress has already loaded. Plugin features worth keeping are the ones Cloudflare does not cover, such as file integrity monitoring and malware scanning.
How often should I review these rules?+
Quarterly at minimum, and after any significant site change. New plugins add new endpoints, new integrations add new traffic sources, and crawler behavior shifts constantly.
Can I copy someone else ruleset?+
You can copy the structure, which is what this page is for. You cannot copy the specifics, because the rate limits, cache bypasses, geographic policy and integration allowlists all depend on your traffic, your markets and what your site connects to. A pasted ruleset either blocks nothing useful or blocks your own customers.
What if I break something and cannot work out which rule did it?+
This is the argument for deploying one at a time. If you are already in that position, use the firewall event log: it shows exactly which rule fired on which request. Filter to the affected URL and the answer is usually immediate.
