Cloudflare is a service that provides a comprehensive suite of internet services, primarily focusing on security, performance, and reliability for websites and online applications.
Cloudflare acts as an intermediary, or reverse proxy, sitting between a website’s hosting server and its end-users.
Cloudflare Firewall Rules are custom rules that you create to protect certain parts and files of your website.
On Cloudflare Free plan, you are allowed a total of 5 custom Firewall rules per zone (domain)
If you subscribe to newsletters of WordPress security services, you will find that vulnerabilities have been found even in popular plugins such as SEOPress, WP Fastest Cache, WP Code, Elementor Pro.
New vulnerabilities in WordPress plugins and themes are discovered and publicly reported every single week.
If you have a content site like mine, creating CloudFlare Firewall Rules will secure your sites better than some WordPress Security plugins do.
Let’s get started
Types of Attacks Made to WordPress Websites
To Protect your WordPress website, you will have to protect your site at the:
- Path Level.
- Query String Level.
Blocking attacks at the Path Level means that attackers often attempt to exploit vulnerabilities in specific paths, such as:
https://example.com/wp-admin.php/
Query string level refers to the parameters passed via URLs that can interact with your database or server. Attackers often exploit this level through SQL injection, cross-site scripting (XSS), and other similar attacks by inserting malicious code into query strings.
https://example.com/search?query=<script>alert('Hacked!');</script>
Attackers also combine a targeted path, such as a login page, with a malicious query string to execute XSS attacks.
https://example.com/wp-login.php?redirect_to=<script>alert('Hacked!');</script>
All attacks you may encounter, and which you should aim to mitigate, will be associated with malicious intentions targeting either the path or query string level.
Three Layers of Security
Let’s understand these concepts:
- CDN Security: Cloudflare provides a Content Delivery Network (CDN) that enhances your website’s security. CloudFlare Firewall Rules can stop most attacks
- Application security refers to the measures you take to protect your website. This includes practices like using strong, unique passwords, regularly updating your themes and plugins, and implementing security features such as application level firewalls and two-factor authentication.
- Server security focuses on securing the infrastructure that hosts your website. This includes configuring the server correctly, applying security updates, securing server files, using firewalls, and limiting server access to only authorized users.
So make the best (1) CloudFlare Firewall Rules possible (2) Learn about basic security measures with or without plugins (3) Use a reliable hosting provider and avoid shared hosting.
Wrong Approach to WordPress Security
Blocking access to specific folders, files, file extensions, user agents, query strings, and more.
Additionally, restricting access from certain ISPs and hosting providers.
That takes a lot of work and you will never succeed at it.
If you check logs, you will also find out that sometimes bots scan for stuff that exists on your site:
https://example.com/wp-admin.php/
Bots also scan for stuff that might not be on your site like
https://example.com/wordpress.zip
Why do they do that?
Because at some point, somebody ignorant enough stored a backup on the root of his/her website and that site got hacked.
A Better Approach to Security
A better approach is to learn the structure of your WordPress site well
Download WordPress, unzip it the folder and explore what’s in there?
You don’t have to be a coder to understand that there are three main folders:
| #1 | wp-content |
| #2 | wp-admin |
| #3 | wp-include |
The root also includes some files, most of them are PHP files.
- Do you where the images you upload to your site are stored?
- Where are the plugins installed?
You don’t need to be an expert to understand where things are on your WordPress installation.
If you go to your website, you can view the source code of your pages and you will see where scripts and stylesheets are.
The more you know about WordPress, the more that you will be able to protect your sites.
Whitelist your Home or Server IP Address
You have to whitelist some IP addresses to make sure you and others don’t get blocked by rules you are about to create
Add your IP address, allow it, and make sure this applies to all websites in your account and give the IP address access rule any name that you want.
Also, give the same treatment to your server IP address so CRON jobs are not blocked by CloudFlare.

If your home IP changes, do the process again and add your new home IP
This doesn’t count as part of your CloudFlare Rules.
Protect WordPress at the Path Level

Take this into account:
- The rule name can be whatever you want
- There are plenty of options to choose from the “Field” drop-down menu,
- Choose URI Path.
- In Operator, choose “Contains”
- In Value, write .php
- And in action choose “Block”
This is how your CloudFlare Firewall rule should look:

The rule says that every time a request with the words .php is made, the visitor or bot will get blocked out from your site
This rule is protecting your default login pages, the wp-config file, the XML-RPC file, and the rest of the existing and non-existing PHP files on your WordPress sites.
To understand the importance of this rule, you can download WordPress from WordPress.org, unzip the file and see that most files from the installation are PHP files.
Most attacks to WordPress sites have to do with PHP files, so blocking access to those if visitors don’t need access to them is critical to your site security.
This is a report from WordFence in which the exploit have to do with a PHP file.

This is another report from WordFence telling users that .PHP were part of an attack campaign.

In case you have to let your users or a service have access to some .php files, consider whitelisting that file.
For example, If you want to get post comments, create a firewall rule to whitelist wp-comments-post.php
If you want to learn more about why you should block access to PHP files, consider reading tip #3 from 13 extra things we do for better WordPress Security
You can create more rules to discourage bots from visiting your site but you have to figure that out yourself.
Let’s think that you don’t have any of these files types on your site, you can easily block them following the same steps from before.
| #1 | .zip |
| #2 | .rar |
| #3 | .bak |
| #4 | .bat |
| #5 | .htacc |
| #6 | .tar |
| #7 | .env |
| #8 | .tgz |
| #9 | .7z |
| #10 | .sql |
| #11 | .xz |
| #12 | .yml |
| #13 | .aws |
| #14 | .alfa |
| #15 | .zlib |
| #16 | .bk |
| #17 | .bz2 |
| #18 | .dat |
| #19 | .gz |
| #20 | .py |
| #21 | .jsp |
| #22 | .asp |
| #23 | .cgi |
| #24 | .bash |
| #25 | .dll |
| #26 | .hg |
| #27 | .git |
| #28 | .cfg |
| #29 | .mdb |
| #30 | .htpas |
| #31 | .pass |
| #32 | .out |
| #33 | .cmd |
| #34 | .swp |
| #35 | .exe |
| #36 | .ini |
| #37 | .phtml |
| #38 | .md |
| #39 | .axd |
| #40 | .log |
| #41 | .sqlite |
| #42 | .hash |
| #43 | .cfm |
| #44 | .txt |
| #45 | .html |
This is the expression in case you want to modify it:
(http.request.uri contains ".zip") or (http.request.uri contains ".rar") or (http.request.uri contains ".bak") or (http.request.uri contains ".bat") or (http.request.uri contains ".htacc") or (http.request.uri contains ".tar") or (http.request.uri contains ".env") or (http.request.uri contains ".tgz") or (http.request.uri contains ".7z") or (http.request.uri contains ".sql") or (http.request.uri contains ".xz") or (http.request.uri contains ".yml") or (http.request.uri contains ".aws") or (http.request.uri contains ".alfa") or (http.request.uri contains ".zlib") or (http.request.uri contains ".bk") or (http.request.uri contains ".bz2") or (http.request.uri contains ".dat") or (http.request.uri contains ".gz") or (http.request.uri contains ".py") or (http.request.uri contains ".jsp") or (http.request.uri contains ".asp") or (http.request.uri contains ".cgi") or (http.request.uri contains ".bash") or (http.request.uri contains ".dll") or (http.request.uri contains ".hg") or (http.request.uri contains ".git") or (http.request.uri contains ".cfg") or (http.request.uri contains ".mdb") or (http.request.uri contains ".htpas") or (http.request.uri contains ".pass") or (http.request.uri contains ".out") or (http.request.uri contains ".cmd") or (http.request.uri contains ".swp") or (http.request.uri contains ".exe") or (http.request.uri contains ".ini") or (http.request.uri contains ".phtml") or (http.request.uri contains ".md") or (http.request.uri contains ".axd") or (http.request.uri contains ".log") or (http.request.uri contains ".sqlite") or (http.request.uri contains ".hash") or (http.request.uri contains ".cfm") or (http.request.uri contains ".txt") or (http.request.uri contains ".html")
I collected those from my Cloudflare firewall logs.
If you have to give access to files such as robots.txt, ads.txt or any other important, include them on the whitelist rule and let Cloudflare block the rest of them.
Protect WordPress at the Query String Level
In case you might want to block malicious query strings, here are some keyword to block with your firewall.
| #1 | script |
| #2 | user |
| #3 | select |
| #4 | cast |
| #5 | concat |
| #6 | pass |
| #7 | shell |
| #8 | panel |
| #9 | passwd |
| #10 | config |
| #11 | md5 |
| #12 | flush |
| #13 | alert |
| #14 | password |
| #15 | union |
| #16 | from |
| #17 | convert |
| #18 | api |
| #19 | mod |
| #20 | eval |
| #21 | char |
| #22 | login |
| #23 | pwd |
| #24 | domain |
| #25 | author |
| #26 | var |
if you are using the query string option, you don’t have to worry about the word being present on your post URL.
(http.request.uri.query contains "script") or (http.request.uri.query contains "password") or (http.request.uri.query contains "user") or (http.request.uri.query contains "union") or (http.request.uri.query contains "select") or (http.request.uri.query contains "from") or (http.request.uri.query contains "cast") or (http.request.uri.query contains "convert") or (http.request.uri.query contains "concat") or (http.request.uri.query contains "api") or (http.request.uri.query contains "pass") or (http.request.uri.query contains "mod") or (http.request.uri.query contains "shell") or (http.request.uri.query contains "eval") or (http.request.uri.query contains "panel") or (http.request.uri.query contains "char") or (http.request.uri.query contains "passwd ") or (http.request.uri.query contains "login") or (http.request.uri.query contains "config ") or (http.request.uri.query contains "pwd") or (http.request.uri.query contains "md5") or (http.request.uri.query contains "domain") or (http.request.uri.query contains "flush") or (http.request.uri.query contains "alert") or (http.request.uri.query contains "attr=") or (http.request.uri.query contains "array")
You can create a rule and then copy and paste the expression from above using the “Expression builder” option.

You can add it, deploy and remove words that might be blocking visitors.
As far as I know, If you have a content site, I don’t see why somebody would visit links containing those words but you never know.
Let me be honest here.
- Most query string attacks are blocked at the path level if you have a robust firewall.
- When it comes to query string attacks, you have to understand that those attacks can use encoded characters that will bypass the Firewall.
- So in addition to words, you should add some common character used for encoding.
- If you have a 100% with no forms connected to the database, consider redirecting all query strings to the URL at the path level.
My CloudFlare Firewall Rules

I donβt really need to rely on Cloudflare Firewall rules anymore since my websites are now fully static and no longer expose dynamic attack surfaces. Even so, I still genuinely enjoy learning about WordPress security.
I have use several approaches to secure my WordPress sites but this is probably my best foundation for the CloudFlare Firewall.
First Firewall Rule
I block every single folder and file that only admins need.
These are the contents of the root folder of one of my sites.
I am using a different location for the uploads folder, I call it “assets” now and I moved all images and scripts and stylesheets there.
Why do I do that?
So I could block wp-admin, wp-content and wp-includes entirely.
It is easy for me to do this because I am using a custom theme and only mu-plugins
But it is doable. You just have to inspect the source and see what links have wp-content in them and create a mu-plugins to move them to the assets’ folder or whatever you want to call it.
wordpress-root/
βββ ads.txt
βββ assets/
βββ index.php
βββ license.txt
βββ readme.html
β
βββ wp-admin/
βββ wp-content/
βββ wp-includes/
β
βββ wp-activate.php
βββ wp-blog-header.php
βββ wp-comments-post.php
βββ wp-config.php
βββ wp-config-sample.php
βββ wp-cron.php
βββ wp-links-opml.php
βββ wp-load.php
βββ wp-login.php
βββ wp-mail.php
βββ wp-settings.php
βββ wp-signup.php
βββ wp-trackback.php
βββ xmlrpc.php
I am also blocking all php files and other files.

Block access to everything that won’t break how WordPress works
Second Firewall Rule
I dedicate the second rule to block URLs with uncommon patterns.
Additional I block requests methods such as POST and DELETE
| URI Full | contains | .php |
| URI Full | contains | @ |
| URI Full | contains | $ |
| URI Full | contains | ) |
| URI Full | contains | ( |
| URI Full | contains | .. |
| URI Full | contains | % |
| Request Method | equals | POST |
| Request Method | equals | DELETE |
You have to know what you are doing to add or remove from this list
Third Firewall Rule
What do visitors need access to?
| Images | Assets Folder |
| Scripts | Assets Folder |
| Stylesheets | Assets Folder |
| Ads.txt File | Root |
| Robots.txt | Root |
| Sitemap | URL |
| Sitemap Stylesheet | URL |
I whitelist stuff that people 100% need access to.
If you are an organized person, you could whitelist content dedicated to a custom post type:
https://wpsurfer.org/wordpress-security/wordfence
https://wpsurfer.org/wordpress-speed/perfmatters
https://wpsurfer.org/wordpress-hosting/cloudways
If that’s the case, you could use these keyword to allow all content on those post types
| wordpress-security | URL |
| wordpress-speed | URL |
| wordpress-hosting | URL |
That won’t be the case with already-established with content ranking or trying to rank on Google
Fourth Firewall Rule
So far:
- Everything that it is supposed to be blocked will be blocked by the first or second rule.
- Everything that it is supposed to be public will be whitelisted by the third rule.
There is not much you have to do now
You can create a rule to present an interactive or non-interactive challenge to visitors that match or don’t match a certain criteria.
Fifth Firewall Rule
The last one could be a Firewall Log to check if something to see if something was not being target by none of the previous rules
Log matching requests of any request not coming from your IP.
(ip.src ne 222.5.48.162)
You can check those logs to strengthen your previous rules.
Don’t forget to find patterns, don’t block anything suspicious you find on those logs
Frequently Asked Questions
These are my answers to some of the most common questions you might have:
Why don’t I Share my Firewall Rules?
Sharing my Firewall Rules doesn’t really help anybody. My Firewall Rules are custom firewall rules that would probably conflict with your set up.
Do I Block Tor?
No, If you are legitimate user trying to check my content, I don’t care what you do to do it.
Sometimes I use Tor. I use it for privacy concerns.
If Tor is used for malicious purposes, my rules should be able to block those attacks.
Should I focus on Query Strings?
Malicious query strings are usually part of bot attacks, but most of them are blocked at the Path Level. Since I turned my site into a static, all of query strings are redirected to its path.
Do I Block User Agents?
I have blocked user agents in the past but I don’t do that anymore
why?
Cause legit companies are being transparent and show you who they are.
Besides that, the only real user agents you will be able to spot are the ones who are not smart enough to change their user agent for a fake one.
You can change your user agent to whatever you want.
Do I Block Countries?
I have challenged countries in the past but I don’t feel good about that anymore.
If you are protecting the sensitive areas of your site, let people visit your site, specially if your content serves a worldwide audience.
I don’t want to stop people from my checking my sites.
If your rules are as robust as you think they are, let people in.
Do I Block Hosting, VPN or other Internet companies by AS number?
I donβt block hosting providers outright, because a lot of legitimate services rely on them too.
For example, Ahrefs uses OVH, and if you make money with display ads, chances are some services you depend on run on Amazon Web Services.
Trying to build a list of βbadβ hosting providers or ISPs is a ton of work, and youβll never get it 100% right anyway. Doing that also requires a deep understanding of how the internet works, otherwise youβll end up with unintended consequences.
If youβre going to spend time making lists of companies and blocking them by AS number, youβd probably be better off learning your site inside and out and building a solid firewall instead like I did.
Conclusion
I hope this has been helpful. If you still want to use a security plugin, stick with something lightweight and make sure youβre also following basic security best practices.
Just keep in mind that no security setup is 100% foolproof especially if you make poor decisions when it comes to protecting your WordPress site.
Using nulled plugins or running pirated software on your computer is risky, and sooner or later it can come back to bite you.
The same goes for hosting: if youβre using a low-quality provider, youβll likely end up dealing with the consequences eventually.