My WordPress site got hammered with 2,000+ brute-force login attempts in a single week. Server resources drained. Legitimate visitors faced slow loading times. That’s when I implemented Cloudflare WAF Rules—and the attacks dropped to near zero overnight.
You don’t need a cybersecurity background to pull this off. The Cloudflare Free plan gives you five custom WAF rules, and I’m sharing the exact four rules running on my site right now. Complete with testing commands, expected results, and the mistakes I made so you don’t have to repeat them. For the fifth rule (bot blocking), which gets complicated fast, I wrote a separate guide.
Why Cloudflare WAF Rules Matter for WordPress
Here’s the uncomfortable truth: 1 in every 25 WordPress sites will get hacked or attacked. The most common attack vectors? Brute-force login attempts, XML-RPC exploitation, and sensitive file scanning.
Cloudflare WAF sits between your site and the internet. Every request gets analyzed before reaching your server. Bad traffic? Blocked at the edge. Good traffic? Passes through without delay. Your server never wastes resources on malicious requests.
The Free plan doesn’t include Cloudflare’s premium Managed Rules. But these four custom rules I’ve tested cover the most critical vulnerabilities without costing a dime.
The Five Cloudflare WAF Rules Running on My Site Right Now
After months of testing and tweaking, these five rules block the most common attacks while maintaining site performance. Zero issues with search engine bots. Zero problems with plugin functionality.
| Rule | What It Protects | Threat Blocked | False Positive Risk | Coverage |
|---|---|---|---|---|
| Rule 1: Admin Area Protection | wp-admin, wp-login.php | Brute-force attacks | Low | First Article |
| Rule 2: Critical System Files | wp-config.php, xmlrpc.php | Credential theft, DDoS | Very Low | First Article |
| Rule 3: Readme File Protection | Plugin/theme version files | Reconnaissance scanning | Very Low | First Article |
| Rule 4: Exploit Pattern Blocking | .env, debug logs, SQL injection | Command injection, SQLi | Low | First Article |
| Rule 5: Bot & Spam Traffic Blocking | Empty User-Agents, AI bots, scrapers | Automated attacks, resource drain | Medium | Separate Guide* |
Caption: Overview of all five Cloudflare WAF Rules: Rules 1-4 are implemented in the main guide, while Rule 5 requires a separate detailed guide due to its complexity.
Rule 1: Admin Area Protection
The problem: Bots hammer wp-admin and wp-login.php thousands of times daily. Each failed login attempt consumes server resources.
Rule Name: Critical WP Exploit Files (you can set the name as per your understanding)
Expression:
(
http.request.uri.path eq "/wp-login.php" or
http.request.uri.path wildcard "/wp-admin/*"
)
and not (
http.request.uri.path eq "/wp-admin/admin-ajax.php" or
http.request.uri.path eq "/wp-admin/admin-post.php" or
http.request.uri.path eq "/wp-admin/load-styles.php" or
http.request.uri.path eq "/wp-admin/load-scripts.php" or
http.request.uri.path wildcard "/wp-admin/css/*" or
http.request.uri.path wildcard "/wp-admin/js/*"
)
Action: Block
Why the exceptions matter: I learned this the hard way. Block wp-admin entirely, and plugins like Imagify stop working. The admin-ajax.php and admin-post.php files handle legitimate plugin requests. Block those, and you’ll spend hours troubleshooting why your optimization tools suddenly broke.
Testing Your Rule:
Open Command Prompt (Windows key + R, type cmd, press Enter.
Press Windows key + R, type cmd, then press Enter (or click OK). Run the following command.
- Replace yourdomain.com with your actual domain in all test commands.
- Important: Remove your IP from the whitelist before testing. Otherwise, you’ll get false results.
- Expected Result: HTTP/1.1 403 Forbidden with Cloudflare headers (If your PC IP is not whitelisted.
- My results: After implementing this rule, brute-force attempts on my login page dropped from 15-20 daily to essentially zero. The bots still try—they just never reach my server.
Locked yourself out? Don’t panic. Add your IP to the allow list: Security > WAF > Tools > Your IP address (Action: Allow). See Step 4 below for details.
Run All Commands like this
Why It Works: This rule blocks direct access to your admin areas while explicitly allowing requests to admin-ajax.php and admin-post.php — files essential to many WordPress plugins functioning correctly. This stops brute-force attacks on your login page while maintaining full site functionality.
Rule 2: Critical System File Protection
The problem: wp-config.php contains your database credentials. xmlrpc.php is a favorite target for DDoS and brute-force attacks. Neither file should ever be publicly accessible.
Rule Name: Block WP Config & XML-RPC
Expression:
(http.request.uri.path eq "/xmlrpc.php" or http.request.uri.path wildcard "*/wp-config.php")
Action: Block
Command: curl -I “https://yourdomain.com/xmlrpc.php”
Expected Result: HTTP/1.1 403 Forbidden with Cloudflare headers
Why this matters: Attackers can’t steal what they can’t reach. Blocking at Cloudflare’s edge means malicious requests never touch your server. This is probably the highest-impact rule on this list—these files are never legitimately accessed by visitors.
Rule 3: Readme File Protection (Optional)
The problem: Hackers scan readme.txt files to discover which plugins and themes you’re running—and their versions. Outdated software with known vulnerabilities? Easy target.
Name: Plugin/Theme Readme Scans
Expression:
( http.request.uri.path wildcard "/wp-content/plugins/*/readme.txt" or http.request.uri.path wildcard "/wp-content/themes/*/readme.txt" or http.request.uri.path eq "/readme.html" )
Action: Block
Command: curl -I “https://yourdomain.com/wp-content/plugins/your-plugin/readme.txt”
Expected Result: HTTP/1.1 403 Forbidden with Cloudflare headers
False positive risk: Virtually zero. Real visitors never access readme files. Only automated scanners do.
Rule 4: Exploit Pattern Blocking
The problem: Attackers probe for .env files and debug logs, and try SQL injection attacks. These requests are never legitimate on a WordPress site.
Name: Exploit Pattern Blocking
Expression:
( ends_with(http.request.uri.path, "/.env") or http.request.uri.path contains "/.env." or ends_with(http.request.uri.path, "/debug.log") or http.request.uri.path contains "/.git/" or ends_with(http.request.uri.path, "/composer.lock") ) or ( lower(http.request.uri.query) contains "cmd=" or lower(http.request.uri.query) contains "exec=" or lower(http.request.uri.query) contains "union select" or lower(http.request.uri.query) contains "union+select" or lower(http.request.uri.query) contains "union%20select" or lower(http.request.uri.query) contains "' or 1=1" or lower(http.request.uri.query) contains "information_schema" )
Testing Commands:
- curl -I “https://yourdomain.com/.env”
- curl -I “https://yourdomain.com/wp-content/debug.log”
Expected Result: HTTP/1.1 403 Forbidden (with Cloudflare headers)
What this catches: Environment files with API keys, debug logs with sensitive errors, Git repositories, dependency files, and common SQL injection attempts like ' or 1=1 and union+select. None of these appear in legitimate WordPress traffic.
Rule 5: Bot and Spam Traffic Blocking
This one’s tricky. Bot detection involves data center identification, threat scoring, and proper whitelisting of legitimate crawlers like Googlebot. Get it wrong, and you’ll block search engines or let malicious bots through.
I’ve written a complete guide specifically for Rule 5 because it deserves its own detailed coverage.
Setting Up Cloudflare WAF Rules: Step by Step
Step 1: Access Cloudflare WAF
- Log into Cloudflare dashboard
- Select your website
- Navigate to Security > WAF > Custom Rules
- Click “Create rule.”
Step 2: Rule Order Matters
Implement rules in the order presented. Cloudflare processes top to bottom. If a block rule fires before an allow exception, legitimate requests get blocked. I made this mistake early on—spent an hour figuring out why Imagify stopped working.
Step 3: Test Every Rule
After each rule, test with the provided curl commands. Verify:
- Malicious requests return
403 Forbidden - Legitimate traffic returns
200 OK - Plugins like Imagify still function
Step 4: Whitelist Your IP
Before testing: Add your IP to Security > WAF > IP Access Rules. This prevents locking yourself out.
For accurate testing: Use a VPN or mobile connection (non-whitelisted IP). Whitelisted IPs bypass all rules—you won’t see real results otherwise.
Testing Legitimate Traffic
Blocking attacks is half the job. The other half? Making sure you didn’t break anything.
Search Engine Bot Test
Googlebot must access your content without interruption:
curl -I -H "User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" "https://yourdomain.com/"
Point to be noted: In Rule 1, I blocked all WordPress sensitive paths like /wp-admin but allowed specific plugin paths (Imagify in my case) using the ‘and not’ syntax.
For Example
If you need to allow additional paths for other plugins? Just add them to the in {} list. For example, if WP Rocket needs /wp-admin/rocket-ajax.php, append it to the exceptions.
Imagify or any other related service functionality Testing
Since Imagify requires access to admin-ajax.php and /wp-admin/admin-post.php, verify it’s still accessible:
For Example:
admin-ajax.php and /wp-admin/admin-post.php paths are required by Imagify (the image optimization tool). You can also allow any required services just like I allow Imagify plugin services to work properly.
curl -I "https://yourdomain.com/wp-admin/admin-ajax.php"
Expected Result: HTTP/1.1 400 Bad Request – This is normal! A 400 response means the file is accessible but awaiting proper parameters (which Imagify provides).
WebP Image Delivery Testing
Verify that Imagify is correctly serving optimized images:
curl -I -H "Accept: image/webp" "https://yourdomain.com/wp-content/uploads/example-image.jpg"
Expected Result:
HTTP/1.1 200 OK Date: Fri, 16 Jan 2026 16:31:51 GMT Content-Type: image/webp
When Things Go Wrong: Troubleshooting Cloudflare WAF Rules
Rules Not Working?
- Check DNS settings: Your domain must be proxied through Cloudflare (orange cloud icon). Grey cloud = traffic bypasses Cloudflare WAF Rules entirely.
- Check rule order: Allow exceptions must come before block rules in your Cloudflare WAF Rules setu
- Check your IP: If whitelisted, you won’t trigger blocks. Test from a different IP.
Blocking Legitimate Traffic?
- Check Security Events: Security > Events shows which rules triggered and why.
- Narrow the rule: Add more specific conditions to reduce scope.
- Switch to Managed Challenge: For borderline cases, challenge instead of block. Humans can solve it; bots typically can’t.
Performance Impact?
None. Cloudflare processes rules at the edge—before traffic hits your server. Well-configured rules actually improve performance by stopping malicious requests from consuming server resources.
Limitations You Should Know
These rules provide solid protection, but they’re not bulletproof:
- Five-rule limit on the Free plan. Complex security needs may require paid plans.
- No advanced threat intelligence. Enterprise features like Bot Management and DDoS mitigation aren’t included.
- Limited logging. Free plan analytics are basic compared to paid tiers.
- Quarterly maintenance required. Attack patterns evolve. Review and update rules every few months.
- Not a complete solution. WAF rules work best combined with server-level security, regular updates, and strong passwords.
Beyond These Five Rules
Cloudflare Managed Rules
On paid plans, enable Managed Rulesets for protection against OWASP Top 10 vulnerabilities and advanced SQL injection patterns.
Rate Limiting
Consider rate limiting on your login page. Stops bots from making hundreds of login attempts per minute.
WordPress Hardening
- Keep core, themes, and plugins updated
- Remove unused plugins and themes
- Use strong, unique passwords
- Enable two-factor authentication
Server-Level Security
- Allow only Cloudflare IP ranges through your server firewall
- Keep server software updated
- Implement fail2ban for additional brute-force protection
Your Action Plan
- Implement Rules 1-4 in the Cloudflare dashboard
- Test each rule with provided commands
- Whitelist your IP to avoid lockouts during setup
- Monitor Security Events for false positives
- Read the Rule 5 guide for advanced bot blocking.
- Review quarterly as attack patterns change.