How to Use Cloudflare WAF for WordPress Security

Introduction: Why I Use Cloudflare WAF for WordPress Security

When I started managing WordPress websites, one of my top concerns was keeping the sites safe from common attacks. I saw first-hand how vulnerable WordPress sites can be. Brute-force login attempts, bot-driven scraping, and automated exploitation of XML-RPC were all things I had to defend against. I wanted a solution that could handle these threats without putting extra strain on WordPress itself. That’s when I began using Cloudflare WAF for WordPress as my first line of defense.

In this article, I’ll share my process for setting up Cloudflare Web Application Firewall (WAF) rules to protect WordPress sites.

This approach works even on the free plan. My goal is to help other WordPress site owners understand how to create effective rules that challenge or block bad actors while letting real visitors and search engine crawlers through without a problem.

Many WordPress site owners assume these kinds of protections are only necessary for big businesses or high-traffic websites. But the reality is that automated attacks target WordPress sites of all sizes. Whether you run a personal blog, a small business site, or an online store, your site is likely being scanned and tested for weak points. These WAF rules are designed to give any WordPress site owner a way to stay ahead of those threats, without adding more plugins or slowing down the site.

Understanding What Cloudflare WAF Does for WordPress

A Web Application Firewall filters traffic before it hits your site. Cloudflare WAF sits in front of your WordPress installation and inspects incoming requests. It looks for patterns that match known attack vectors or behaviors. This includes things like SQL injection attempts, cross-site scripting, brute-force login attacks, or bot scraping.

Why I Choose Cloudflare WAF Over WordPress Security Plugins

Many WordPress security plugins offer useful features like login protection, brute force prevention, and bot blocking. These tools help defend your site, but they work at the application level, which means the unwanted request has already reached WordPress before anything happens.

What I like about using Cloudflare WAF for WordPress is that it works upstream. Instead of relying on WordPress itself to decide whether to allow or reject traffic, Cloudflare handles that decision at the network edge. This approach lets me filter out bad requests earlier in the process and keeps my site focused on serving real visitors.

While security plugins add valuable options inside WordPress, I prefer the simplicity of handling threats before they ever get to the site. For me, Cloudflare WAF serves as the first layer of protection. If I need additional layers, I can always supplement with plugin features, but my primary defense stays at the edge.

Why the Free Plan of Cloudflare WAF for WordPress Is a Good Starting Point

You don’t need to pay for Cloudflare’s premium plans to get meaningful protection. The free plan includes the ability to create five custom firewall rules. While that’s a limit you have to work around, I’ve found that with careful planning, five rules can go a long way.

The free plan gives me access to:

Managed Challenge works by asking suspicious visitors to prove they are human, using CAPTCHAs, JavaScript challenges, or other verification methods before they can access your site.

Most importantly, I can control how Cloudflare reacts to specific types of traffic, like bots hitting my login page or bad actors from high-risk networks.

Watch my Cloudflare WAF Fules for WordPress on YouTube

How to Create Cloudflare WAF Rules for WordPress

If you’re ready to set up Cloudflare WAF for WordPress, here’s the process I follow to create the firewall rules that keep my sites protected. These steps work on the free plan, and you can always expand them if you upgrade later.

If you’re new to writing firewall rules, here’s a simple example to get started. One of the easiest and most effective rules you can create is to challenge any POST request to your WordPress login page. This helps prevent brute-force bots from trying to guess passwords.

Example expression for this rule:

http.request.uri.path contains “wp-login.php” and http.request.method eq “POST”

I recommend starting with Managed Challenge for this rule so you can monitor activity before deciding whether to block these requests entirely.

Step 1: Enable Cloudflare for Your WordPress Site

First, make sure your WordPress site is using Cloudflare for DNS and proxy services. You can sign up for a free account at cloudflare.com, add your domain, and change your DNS nameservers to point to Cloudflare. Once the setup is complete, Cloudflare will sit between your visitors and your server, giving you access to the firewall tools.

Step 2: Navigate to the Firewall Rules Section

In your Cloudflare dashboard, select your site and go to Security > WAF > Firewall Rules. In your Cloudflare dashboard, select your website from the list of domains. From the left-hand menu, click on Security, then WAF, and choose Firewall Rules. This is where you can view existing rules or create new ones.

On the free plan, you can create up to five custom firewall rules.

Step 3: Identify Your Rule Priorities

Decide which threats you want to handle first. My priority list usually looks like this:

I didn’t create this list. This article from Web Agency Hero inspired my version.

So why not just use their rules? Well, different sites have different needs. While their plan is comprehensive, I found that it could block tools that use REST API or AJAX. It also failed to protect a sensitive path like WP-ADMIN. That’s why I ended up making my own modifications to their great work.

Step 4: Write and Test Your Firewall Expressions

Use the Expression Editor inside Cloudflare to write your rule logic. The visual builder might not display complex expressions, but the rules still work as written. Here’s an example expression that challenges login POST attempts:

http.request.uri.path contains “wp-login.php” and http.request.method eq “POST”

Start with Managed Challenge instead of Block so you can monitor how the rule performs without locking out legitimate users.

Step 5: Add Exceptions for Critical WordPress Functionality

Some requests need to be allowed to keep your site working smoothly. Make sure your rules include exceptions for:

Also, allow Cloudflare Verified Bots so that search engine crawlers and uptime monitors aren’t affected by your rules.

When I create my Allow Good Bots rule in Cloudflare WAF for WordPress, I use specific skip settings to make sure that verified good bots like Googlebot, Bingbot, and uptime monitors aren’t caught up in my custom firewall rules, rate limiting, or bot fight protections. However, I still want Cloudflare’s core security features like Managed Rules, Browser Integrity Check, and Zone Lockdown to stay active.

Here’s how I configure the Skip settings for this rule:

This setup allows good bots to crawl the site freely without unnecessary challenges while still protecting my WordPress site from critical security threats at the edge. It’s another variation from the Web Agency Hero rules.

Step 6: Monitor the Firewall Events Log

Once your rules are active, go to the Security section of your Cloudflare dashboard. Open Events to see which requests have been challenged or blocked.

Watch the log to see which requests are being challenged or blocked. Look for patterns that show abuse, but also keep an eye out for false positives. Adjust your rules or exceptions as needed.

Now that I’ve shared how to create firewall rules, I want to explain the thinking behind the specific threats I focus on for WordPress sites.

The Real Threats I Target With Cloudflare WAF for WordPress

When I started using Cloudflare WAF for WordPress, I focused on blocking the attacks that target WordPress sites most frequently. Certain types of abuse recur, regardless of the size of your site. These aren’t just theoretical risks — I’ve seen these kinds of requests in my own firewall logs and across client sites I’ve worked on.

The biggest threat I deal with is brute force login attempts. Bots constantly hammer the wp-login.php page, guessing usernames and passwords in an attempt to break in. Even failed attempts can waste server resources and clutter up the system with repeated login activity. This is why my first rule always targets login abuse.

The next issue I plan for is XML-RPC abuse. WordPress has a feature called XML-RPC that allows remote publishing and other functions. The problem is that attackers often use XML-RPC for brute force attacks or to amplify DDoS attacks through pingbacks. Some plugins need XML-RPC, but many WordPress sites don’t. With Cloudflare WAF for WordPress, I can challenge these requests before they become a problem.

Another common threat is bad bots and aggressive crawlers. Not every bot is friendly like Googlebot or Bingbot. Some bots scrape content, probe for vulnerabilities, or send unnecessary requests to your server. If you’ve ever checked your logs and wondered why some unknown bot is hitting every page on your site, this is the kind of behavior I’m talking about. I use firewall rules to allow verified good bots while challenging or blocking the rest.

Finally, I look at where the traffic is coming from. A lot of abuse comes through VPNs, TOR exit nodes, and cheap hosting providers. Attackers use these networks to hide their identity and location. By using Autonomous System Numbers (ASNs), I can identify and challenge traffic from these sources automatically. Blocking entire regions like China or Russia can also reduce a lot of unwanted traffic if your audience doesn’t come from those countries.

When I put these rules together in Cloudflare WAF for WordPress, I’m not guessing about threats. I’m responding to the actual patterns I’ve seen in the wild. These rules give me a way to stop bad actors early, keep my bandwidth focused on real visitors, and reduce the chances of dealing with a compromised site.

How I Build Effective Rules in Cloudflare WAF for WordPress

When I build WAF rules for WordPress, I’m not just guessing at what might work. I write these rules based on the kinds of attacks I’ve actually seen. My approach is to use the limited number of rules available on the free Cloudflare plan as effectively as possible. That means each rule has a job to do, and every exception is intentional.

The first thing I always do is make sure that good bots can get through without trouble. Search engines like Googlebot and Bingbot are important for my site’s visibility. I also rely on uptime monitors and performance tools to make sure the site is healthy. Cloudflare helps here by identifying verified good bots, so I can skip some protections for them without exposing the site to unnecessary risk. I allow these bots to bypass rate limiting and bot fight mode, but I still keep my core managed rules active to protect against real security threats like SQL injection or cross-site scripting.

Next, I focus on challenging aggressive crawlers and known bad bots. These include services like Ahrefs, Semrush, MJ12bot, and others that are notorious for scraping sites too aggressively. I write my WAF rules to look for these bots by their user agent strings. I also include broad terms like “bot,” “crawl,” and “spider,” but with careful exceptions so I don’t accidentally block useful services like RSS readers or my own tools.

One of the most effective strategies I’ve used is ASN matching. Cloudflare lets me create rules that match traffic from specific Autonomous System Numbers. This allows me to challenge or block requests from hosting providers and VPN services, where abusive traffic often comes from. Instead of blocking them outright, I usually start with Managed Challenge. This gives legitimate users a chance to prove they’re human while stopping most automated attacks in their tracks.

The login page is one of the most sensitive areas on any WordPress site, so I give it special attention. I challenge POST requests to wp-login.php, as this is where brute-force login attempts typically occur. I also apply challenges to other sensitive paths like /wp-admin/ and xmlrpc.php, which attackers often target. For these rules, I again use Managed Challenge as my first line of defense. This approach allows me to keep the login page available to real users while increasing the difficulty level for bots and attackers.

I’ve learned that writing effective WAF rules isn’t about blocking everything. It’s about controlling who gets through, challenging suspicious visitors, and allowing legitimate traffic without getting in the way. That’s the balance I try to strike every time I sit down to tune my Cloudflare WAF for WordPress.

Writing rules is only part of the process. The real challenge is making sure they work without getting in the way of the people or services you actually want to allow.

Handling Special Cases and Exceptions in My Cloudflare WAF for WordPress

When I first started writing WAF rules, I made the mistake of thinking tighter security was always better. The problem is that if you lock things down too hard, you can break your own site or block legitimate visitors. Over time, I learned that good firewall rules aren’t just about what you block — they’re also about what you allow.

There are certain paths and services that I always make exceptions for when I use Cloudflare WAF for WordPress. One of the most important exceptions covers the REST API. Many WordPress plugins rely on the REST API to function properly. Without access to it, things like form submissions, plugin settings, and even some theme features can break. That’s why I make sure that my WAF rules allow traffic to the /wp-json/ path.

Another critical exception is the admin AJAX handler. WordPress uses admin-ajax.php for various backend tasks, including features such as real-time updates, notifications, and plugin communication. If I block or challenge these requests, I risk breaking features that I or my site visitors depend on. So I specifically exclude admin-ajax.php from my more aggressive firewall rules.

I also make room for Google Search Console verification. Google often asks site owners to place a verification file on their server, usually named something like google123456789.html. If my firewall rules block that file, my site can lose its verification status. To prevent this, I add an exception that allows requests to paths that include “google” so that Search Console can still do its job.

While I focus a lot on stopping bad bots, I always leave the door open for verified good bots. Cloudflare helps by identifying these services, but I still review my exceptions to make sure I’m not blocking something useful. At the same time, I stay cautious about giving too much access to anything that isn’t clearly verified or necessary.

Getting these exceptions right is one of the most important steps in writing effective WAF rules. If I challenge or block the wrong requests, I risk frustrating my own users — or worse, locking myself out of my own admin area. But by taking the time to allow the right traffic, I can enforce strong security without breaking my site.

Monitoring My Cloudflare WAF Rules for WordPress and Adjusting Over Time

When I set up my first batch of Cloudflare WAF rules for WordPress, I knew the job wasn’t finished just because the rules were in place. Security isn’t something you configure once and then forget about. What makes these firewall rules truly effective is paying attention to what happens after they go live.

I regularly check the Firewall Events log in Cloudflare to see which requests are getting challenged or blocked. This log shows me the details of each event — the IP address, the country of origin, the matched rule, and the request path. I review these events to ensure my rules are doing what I intended and to catch any false positives before they cause real problems.

One of the best lessons I learned early on was to start with Managed Challenge instead of going straight to blocking. Managed Challenge lets me see who’s getting caught by my rules without fully blocking them right away. It gives suspicious visitors the chance to prove they are human by completing a JavaScript challenge or CAPTCHA. This approach helps me gather data on the kinds of requests hitting my site before I decide whether a block is justified.

When I review the events, I look for patterns. If I see the same IP range, ASN, or user agent repeatedly showing up as challenged, I consider whether that source should be blocked outright. On the other hand, if I notice legitimate services or visitors getting caught, I know it’s time to adjust my exceptions.

I also make a habit of checking which ASNs I’m targeting every few months. Autonomous System Numbers can change over time, and some hosting providers shift their IP allocations or ownership. Keeping my list of targeted ASNs up to date helps ensure my rules stay effective without overreaching.

Firewall rules aren’t something I just set and forget. They’re part of an ongoing process where I watch how the site is being accessed, tune the rules to match the actual threats, and make sure I’m not getting in my own way. This monitoring step is what helps me strike the right balance between strong security and a smooth experience for real users.

I recommend taking a few minutes each week, especially after setting up new rules, to check your Firewall Events log. Look at which requests are getting challenged or blocked and see if any legitimate visitors are being affected. This is one of the best ways to fine-tune your WAF rules over time and learn more about the kinds of traffic hitting your site. Watching these patterns helps you stay proactive, rather than reacting only after something goes wrong.

Why Some of My Rules Don’t Show Up in the Cloudflare Visual Builder

One thing that can confuse people when they start writing more advanced firewall rules in Cloudflare is that not every expression shows up in the visual builder. I ran into this myself the first time I wrote a rule using logic like the example below:

not cf.client.bot

When I went back into the editor later, the rule looked blank. At first, I thought the rule wasn’t active, but that’s not the case.

Cloudflare’s visual rule builder is designed for simple conditions that use dropdown menus and basic options. But when I write rules directly in the expression editor, especially when I use more complex logic like not, and, or ASN matching, the builder often can’t display that logic in the visual view. The important thing to know is that the rule still works exactly as written. It just doesn’t appear in the point-and-click editor.

This matters because it helps avoid a lot of second-guessing. When I create a rule that includes conditions like the example below, I know it won’t show up visually, but I trust the expression editor and confirm with the Firewall Events log that the rule is active.

not cf.client.bot and (http.user_agent contains “crawl”)

Expressions like this let me safely allow good bots through while challenging or blocking aggressive crawlers. They also give me the flexibility to match user agent patterns, ASNs, or country codes without the limitations of the visual builder.

If you decide to work with Cloudflare WAF for WordPress and use expressions like these, remember that the builder might not show them, but the logic still runs exactly as written. I always double-check my expressions before saving and rely on the Firewall Events log to confirm that they’re doing their job.

What I Learned From Using Cloudflare WAF for WordPress

After working through the process of setting up and fine-tuning my Cloudflare WAF rules for WordPress, I learned a few valuable lessons that have shaped how I approach website security.

The first thing I learned is that you don’t need to block everything to stay safe. In fact, trying to block too much too fast usually leads to frustration — either for your visitors or for yourself when you accidentally lock yourself out of your own site. Managed Challenge became my favorite tool because it gives me a middle ground between ignoring a threat and blocking it outright. This approach lets me slow down bad actors without punishing legitimate users who might be caught in the middle.

I also learned the importance of starting with what I know. Rather than guessing at what bots or IP ranges might cause problems, I focused on the login page, XML-RPC abuse, and aggressive crawlers — the kinds of threats I could actually see happening in my logs. By building rules based on real data, I avoided wasting time on edge cases that didn’t affect my site.

Watching the Firewall Events log taught me that my rules are never really finished. Patterns change, new bots show up, and attackers find new ways to sneak through. Instead of setting my rules and forgetting about them, I check my logs regularly and stay ready to adjust. Security isn’t about locking the door once and throwing away the key. It’s about paying attention and adapting as needed.

One more lesson I took away from this process is how much easier it is to manage threats at the edge. I’ve used WordPress security plugins in the past, and while they have their place, I find that handling these issues upstream through Cloudflare WAF keeps my WordPress environment simpler and faster. I don’t have to rely on plugins to clean up problems after they reach the server because I’m stopping most of those problems before they ever get that far.

The peace of mind I get from knowing that Cloudflare WAF protects my login page, admin paths, and sensitive endpoints for WordPress makes the setup time well worth it.

Conclusion: Why I Recommend Cloudflare WAF for WordPress

If you run a WordPress site and you’re serious about protecting it, I recommend setting up Cloudflare WAF for WordPress. Even on the free plan, the firewall rules you create can make a real difference in reducing spam, blocking brute-force login attacks, and keeping abusive bots away from your site.

What I appreciate most about this approach is that it doesn’t require extra plugins or complicated server-side configurations. I don’t have to worry about performance issues from a bloated security plugin or spend time sorting through endless settings. Instead, Cloudflare handles the heavy lifting at the network edge, stopping bad traffic before it ever reaches my WordPress installation.

In my opinion, Cloudflare WAF provides the first line of defense. I still use other good security habits like strong passwords, two-factor authentication, and regular backups, but the WAF rules help prevent many of the common problems from showing up in the first place.

If you’re looking for a straightforward way to strengthen your site’s security, starting with Cloudflare WAF for WordPress is one of the best moves you can make. It only takes a few thoughtful rules to challenge bad bots, protect your login page, and keep your bandwidth focused on your real visitors.

If you’re ready to get started, log in to your Cloudflare account and set up your first WAF rule today. Focus on protecting your login page and challenging suspicious traffic. This small step can make a big d