Cloudflare Security Rules Every Site Owner Must Set Up Updated Step By Step

Last updated: 21 June 2026

Cloudflare gives basic protection when you set up your website. You can do more to keep it secure. In this tutorial, I’ll walk you through how to configure Cloudflare security rules that every site owner should have. We’re going to look at how to block specific countries, protect your WordPress admin area, and prevent abuse of XML-RPC. These rules help keep your website safe from automated attacks and unwanted visitors. Whether you’re managing a small business site or a large WordPress platform, these Cloudflare security rules will help you maintain better control over who accesses your content.

Setting Up Cloudflare Security Rules and Country-Based Access Control

When I first set up Cloudflare for my website CloudyWP.xyz, I went into the security section and then into the security rules area. That’s where you can add your custom security rules. I already had one rule in place that I want to explain to you. It’s a rule that uses a managed challenge for visitors not from Australia. The idea is that if someone is visiting from a country other than Australia, they’ll be shown a Cloudflare challenge to verify they’re not a bot. This helps reduce automated attacks while still allowing legitimate visitors from other countries.

For example, when I first set up Cloudflare, I added a rule that challenges visitors not from Australia. This means they must prove they are not a bot. It helps reduce attacks while still letting real visitors through.

I started by editing the rule and giving it a name. In the field, I selected “country” and used the operator “is not in” to specify that I’m not allowing visitors from countries other than Australia. This is a simple but effective way to apply a challenge to non-Australian visitors. I also explained how to order your rules so that the first rule runs first. In this case, I set it to run first so that if someone is from Australia, they skip all other rules. This is important because it prevents Australian visitors from being challenged unnecessarily.

When you’re setting up these rules, you can also use the “skip” functionality for specific conditions. For example, if you want to skip all rules for Australian visitors, you can mark that condition and set it to skip. This ensures that your rules only apply to the intended audience. I also mentioned that managed challenge requires careful configuration to avoid accidentally blocking legitimate Australian visitors.

Configuring DNS Records and Proxy Settings

Cloudflare’s security rules provide a powerful way to protect your website from malicious traffic. By combining country-based access control with IP-based restrictions, you can create a robust defense system that only allows legitimate visitors to access your content. This approach means that if one rule fails, others still protect your site.

After setting up the security rules, I went back to the DNS settings to make sure all records were properly configured. One important thing I want to highlight is the difference between proxied and DNS-only records. When you see the orange proxy icon next to a DNS record, it means that Cloudflare is protecting that record. It’s going through Cloudflare’s network, which provides security, caching, and DDoS protection.

Records with a gray icon are DNS-only, meaning they don’t go through Cloudflare. This is fine for things like mail records, such as MX records, which need to be DNS-only to function correctly. For your domain records, you want them to be proxied so that your website gets full Cloudflare protection. I showed how to check if records are proxied by looking at the icons in the Cloudflare dashboard.

For example, when I looked at the DNS records for my domain, I saw that both the main domain and the www version were proxied. This ensures that all traffic to my website is protected by Cloudflare. If you’re setting up mail records, make sure those are DNS-only so that email functions properly. I emphasized that domain records should be proxied for full Cloudflare protection, while mail records must remain DNS-only.

Blocking Specific Countries Using Cloudflare Expressions

For country blocking, I showed how to create a rule that blocks visitors from specific countries. I used the expression:

ip.geoip.country in {"CN", "RU"}

This expression blocks visitors from China and Russia. You can modify the country codes to block other countries as needed.

Now I wanted to expand on the country-based rule by adding more conditions. I went back to the security rules and added another rule that blocks visitors from specific countries. I showed how to add multiple conditions using the “and” or “or” operators. For instance, if you want to block visitors from both Australia and the United States, you can set up a condition that checks for both countries.

Instead of using the visual rule editor, I demonstrated how to use the “edit expression” feature for more advanced rule configurations. This feature allows you to paste expressions directly into the rule. I showed how to create an expression that blocks visitors from specific countries like China or Russia. The expression I used was something like:

http.request.uri.path contains "/wp-admin/" and ip.src not in {"127.0.0.1"}

When I pasted this expression into the rule, I set the action to “block”. This means that anyone trying to access the WordPress admin area from an IP address not in the allowed list will be blocked. I explained that this type of expression must be pasted as bare text and that you need to be careful with the syntax.

http.request.uri.path contains "/xmlrpc.php" and ip.src not in {"127.0.0.1"} and http.user_agent contains "jetpack"

This expression blocks access to the xmlrpc.php file unless the request comes from a whitelisted IP address or user agent. I explained that the order of rules is important, especially when you have blocking rules. You want to place blocking rules first so they are applied before other rules.

Pro Tip: When working with Cloudflare expressions, always test your rules carefully. Since I’m in Australia, I had to be careful not to accidentally block myself while testing country-based blocking. I recommend creating a test environment or using a VPN to verify that your rules work as intended before deploying them live.

Protecting WordPress Admin Pages with Cloudflare Rules

Once I had the country blocking rules set up, I wanted to add another layer of security for WordPress admin pages. I created a rule called “guard god admin” to protect access to the WordPress admin area. This rule is based on IP address access control, which is a common method for securing WordPress admin pages.

For example, I created a rule that blocks access to the WordPress admin area unless the visitor comes from a known IP address. This stops unauthorized access even if someone gets past the country check.

The expression I used for this rule was:

This expression checks if the request path contains “/wp-admin/” and if the IP address is not in the allowed list. If both conditions are met, the request is blocked. I set the action to “block” and made sure this rule ran second, after the country blocking rule.

I explained that this approach works well for WordPress sites because it allows only specific IP addresses to access the admin area. This is particularly useful if you’re the only person who needs to access the admin, or if you have a small team with known IP addresses. I also noted that you can add more IP addresses to the allowed list if needed.

When testing this rule, I refreshed the website and confirmed that I could access the main site but was blocked when trying to access the admin page. This confirmed that the rule was working correctly. I also showed how to disable a rule if you encounter any issues, which is useful for troubleshooting.

Blocking XML-RPC Abuse and Implementing Rate Limiting

For rate limiting, I demonstrated how to create a rule that limits requests to WordPress admin pages. The expression I used was:

For example, I used a command line tool to send 10 requests to the login page. The first five were allowed, but the sixth and beyond were blocked. This shows the rate limiting is working.

http.request.uri.path contains "/wp-login.php" or http.request.uri.path contains "/xmlrpc.php" or http.request.uri.path contains "/wp-admin/admin-ajax.php"

This rule applies to WordPress login, XML-RPC, and admin AJAX files. I set the action to “block” and configured it to block for 10 seconds.

Another important security rule I set up was for protecting against XML-RPC abuse. WordPress has an xmlrpc.php file that allows external applications to connect with your site. This file can be exploited by attackers to perform brute-force attacks, especially on login pages. I demonstrated how to create a rule that blocks access to xmlrpc.php unless it comes from a whitelisted service.

I used the following expression to protect against XML-RPC abuse:

This expression blocks access to xmlrpc.php unless the request comes from a whitelisted IP address or user agent. I explained that I allowed services like Jetpack to access the file while blocking all others. This lets legitimate services work while blocking abuse.

I also showed how to implement rate limiting for login and admin pages. I created a rule that limits the number of requests to 5 per 10 seconds. This helps prevent brute-force attacks by blocking repeated login attempts. The expression I used was:

This rule applies to WordPress login, XML-RPC, and admin AJAX files. I set the action to “block” and configured it to block for 10 seconds. I noted that Cloudflare’s free plan limits rate limiting to 10 seconds, so if you need longer blocks, you’ll need a paid plan.

To test the rate limiting, I used a curl command to simulate multiple requests to the login page. I showed how to run a loop that sends 10 requests and observed the response codes. The first five requests returned 200 (allowed), but the sixth and beyond returned 429 or 403 (blocked). This confirmed that the rate limiting was working as expected.

Conclusion

Setting up Cloudflare security rules is an essential step in protecting your website from automated attacks and unwanted visitors. In this tutorial, I showed you how to create rules for country-based access control, protect WordPress admin pages, and block XML-RPC abuse. These security measures will help keep your site safe while maintaining good performance.

Remember to test your rules carefully before deploying them live. Use a VPN or different IP addresses to verify that your rules work as intended. You can also disable rules if you encounter any issues with your site’s functionality.

For more detailed information and additional security rules, check out our post on Cloudflare Setup Tutorial and Secure WordPress Site Against Common Threats. These resources provide additional tips and best practices for securing your website with Cloudflare.

Putting It All Together: A Complete Cloudflare Security Setup

Now I want to show you how to put all these rules together for a complete Cloudflare security setup. I have three main rules running on my website: country-based access control, WordPress admin protection, and XML-RPC abuse prevention.

The first rule is the country-based access control. I set this to run first in the rule order. It blocks visitors from specific countries while allowing everyone else to access the site. I’m using a managed challenge for visitors from countries other than Australia, which means Cloudflare will analyze their requests before allowing them through.

The second rule is the WordPress admin protection. This runs second in the order and blocks access to the admin area unless the visitor comes from an IP address I’ve explicitly allowed. This is important because even if someone gets past the country blocking, they still can’t access the admin unless they’re coming from a trusted IP.

The third rule is the XML-RPC protection. This runs last and blocks malicious XML-RPC requests while still allowing legitimate services like Jetpack to access the file. I also have rate limiting in place to prevent brute force attacks on login pages.

I want to emphasize that the order of these rules matters. I have the country blocking first, then admin protection, and finally XML-RPC protection. This ensures that visitors from unwanted countries are blocked immediately, and then the other rules only apply to those who make it past the first check.

When I test the setup, I can see that visitors from Australia can access the site normally. If I try to access the admin page from an IP not in my allowed list, I get blocked. If I try to access the XML-RPC file from an unauthorized service, it’s also blocked.

One thing I notice is that Cloudflare’s caching can sometimes interfere with immediate rule changes. If I make a change to a rule and don’t see it taking effect immediately, I need to wait for the cache to clear or manually clear the cache in the Cloudflare dashboard.

I also want to mention that you can always disable individual rules if you encounter issues. For example, if you’re having trouble with a specific service, you can simply disable the rule that’s causing the problem and keep the rest of your security setup active.

The key to a successful Cloudflare security setup is testing each rule individually and then combining them. You want to make sure that legitimate users can still access your site while unauthorized access is blocked. I recommend starting with the basic rules and then adding more complex protections as needed.

Pro Tip: Always keep a backup plan when implementing security rules. If you block legitimate users, you should be able to quickly disable a rule or adjust the IP address list to restore access.

For those who want to implement more advanced security rules, I’ve written a detailed post that covers additional expressions and configurations. You can find this in the CloudyWP blog where I provide the exact expressions for various security scenarios.

The beauty of Cloudflare’s security rules is that they’re flexible and can be customized to fit your specific needs. Whether you’re protecting a small business website or a large e-commerce platform, you can use these rules to create a robust security setup that protects your site from common threats.

Setting Up Rate Limiting for WordPress Admin Pages

Now I want to show you how to protect your WordPress admin pages from brute force attacks using Cloudflare’s rate limiting feature. This is one of the most important security rules you can set up, especially when you’re dealing with login pages and admin access. I’m going to create a rule that limits how many requests can come from a single IP address to your admin pages.

First, I navigate to the security rules section in Cloudflare and create a new rule. I name it something like “Rate Limit Admin Pages”. Then I go to the edit expression section, which is where you can write custom Cloudflare expressions. The expression I use here checks if the request is going to specific WordPress admin files like /wp-login.php, /xmlrpc.php, or /wp-admin/admin-ajax.php. If those paths are hit, then the rule triggers.

For the action, I select “Block” and set the rate limit to five requests per ten seconds. This means that if someone tries to make more than five requests to your admin page within ten seconds, Cloudflare will block them. This is a good balance between security and usability. You don’t want to block legitimate users who might be trying to log in, but you also don’t want to leave your site open to automated attacks.

One thing to note is that on the free Cloudflare plan, you’re limited to a maximum of ten seconds for blocking users. If you need longer blocking periods, you’ll have to upgrade to a paid plan. But for most small to medium-sized sites, this is more than enough to stop most brute force attempts.

Pro Tip: When setting up rate limiting, always test it with a few requests to make sure it’s working correctly. You can use the command line to simulate multiple requests and see how Cloudflare responds. This helps you avoid accidentally blocking yourself or legitimate users.

Testing and Monitoring Your Cloudflare Security Rules

Once you’ve set up your security rules, it’s important to test them to make sure they’re working as expected. I always recommend testing your rules in a controlled environment before deploying them live. For example, after setting up the country-based blocking rule, I refresh the website and check if visitors from other countries are being challenged or blocked correctly.

When I tested the rule, I noticed that I was getting a managed challenge because I’m in Australia. That’s exactly what I wanted — it means the rule is working. But I also made sure to remove Australia from the list of countries that get challenged so that legitimate Australian visitors aren’t affected.

For testing the admin page protection, I tried accessing the /wp-admin/ path directly. I was blocked, which is the expected behavior. Then I tried to access the login page and again, it was blocked after a few attempts. This confirms that the rate limiting is working correctly.

Cloudflare also provides detailed logs and analytics that you can use to monitor your security rules. You can see how many requests are being blocked, which IP addresses are causing issues, and how often your rules are being triggered. This information is invaluable for fine-tuning your security setup and identifying potential threats.

Another important thing to remember is to regularly review your security rules. As your website grows and evolves, you might need to adjust your rules or add new ones. For instance, if you notice that a certain country is consistently trying to access your site in a suspicious way, you might want to add that country to your blocking list.

Few Of the Rules



Allow My IP

(ip.src in {203.0.113.45})

Block Admin Access Except Allowed IPs

(http.request.uri.path contains "/wp-admin/" or http.request.uri.path eq "/wp-login.php") and not http.request.uri.path contains "/wp-admin/admin-ajax.php" and not ip.src in {203.0.113.45}

Block xmlrpc.php

(http.request.uri.path eq "/xmlrpc.php") and not ip.src in {192.0.64.0/18}

Block Exploit Probes

(http.request.uri.path contains "/.env") or (http.request.uri.path contains "/.git/") or (http.request.uri.path contains "/wp-config.php") or (http.request.uri.path contains "/.aws/") or (http.request.uri.path contains "/phpmyadmin") or (http.request.uri.path contains "/.ssh/") or (http.request.uri.path contains "/.DS_Store") or (http.request.uri.path contains "/config.php.bak") or (http.request.uri.path contains "/.htaccess") or (http.request.uri.path contains "/vendor/phpunit") or (http.request.uri.path contains "/wp-config.php.bak") or (http.request.uri.path contains "/.svn/") or (http.request.uri.path contains "/backup.sql") or (http.request.uri.path contains "/database.sql")

Block PHP Execution in Upload Directories

(http.request.uri.path contains "/wp-content/uploads/" and http.request.uri.path contains ".php") or (http.request.uri.path contains "/wp-content/uploads/" and http.request.uri.path contains ".phtml")

Block Malicious User Agents

(lower(http.user_agent) contains "sqlmap") or (lower(http.user_agent) contains "nikto") or (lower(http.user_agent) contains "masscan") or (lower(http.user_agent) contains "nmap") or (lower(http.user_agent) contains "fuzzer") or (lower(http.user_agent) contains "wpscan") or (lower(http.user_agent) contains "havij") or (lower(http.user_agent) contains "acunetix") or (lower(http.user_agent) contains "netsparker") or (lower(http.user_agent) contains "openvas") or (lower(http.user_agent) contains "zgrab") or (lower(http.user_agent) contains "masscan") or (http.user_agent eq "")

Block High-Risk Countries

(ip.geoip.country in {"CN" "RU" "KP" "IR" "BY"})

Block SQL Injection Patterns in URLs

(lower(http.request.uri.query) contains "union select") or (lower(http.request.uri.query) contains "concat(") or (lower(http.request.uri.query) contains "/etc/passwd") or (lower(http.request.uri.query) contains "..%2f..%2f") or (lower(http.request.uri.query) contains "../../") or (lower(http.request.uri.query) contains "<script") or (lower(http.request.uri.query) contains "base64_decode")