Stopping WordPress comment and search spam with CloudFlare

How to prevent WordPress spam comments (and DDOS by abusing the search option) using CloudFlare, without relying on Google and its reCAPTCHA system, and why I think that’s such a brilliant idea? 🙂
Note:
See my forum’s discussion thread about “Cloudflare being shady” – and consider that before deciding whether to go with Cloudflare.

Table Of Contents (T.O.C.):

Why I opted for CloudFlare instead of Google’s reCAPTCHA
Blocking SPAM using CloudFlare’s JS challenge
Preventing comment and contact form spam
Conclusion
Search form spam prevention

1. Why I opted for CloudFlare instead of Google’s reCAPTCHA

I already wrote an article about how to stop WordPress comment spam. Most of the info I shared there still stands, especially the part about configuring WordPress anti-spam settings, and using The SEO Framework Pro’s Honeypot extension.

However, I wanted to not rely on Honeypot alone, but to create an extra layer and reduce the number of spam bots that post a comment (regardless of the fact that they all get sent to the spam box immediately).

Google’s reCAPTCHA does a decent job with this, but it slows down the site’s performance to a degree, and solving the captcha images is a hassle for any legit visitors. Now, I’ve been using CloudFlare’s free tier for years (and gave the CloudFlare Pro and WordPress APO a test in the meantime). So, I decided to see if I could use CloudFlare to prevent some spam from reaching my site.

If you are new to CloudFlare, I already covered these topics to help you get started:

The here-described methods require that CloudFlare’s proxy is active for your website.

– T.O.C. –

2. Blocking SPAM using CloudFlare’s JS challenge

Even with the free tier, I can still configure 5 CloudFlare firewall rules. Since many bots can not process JavaScript, creating a JavaScript challenge on the DNS level could block most of those.

First thing is to figure out the relevant “handle” to use for the firewall rule. Pressing F12 on your browser and looking at the network tab when posting a comment shows the needed info:

Now, we need to log into the CloudFlare’s dashboard and go to:
Security -> WAF
Then click on the “+ Create rule” button and create the following rule:

For easier copy-pasting:

Field: URI Path
Operator: contains
Value: wp-comments-post.php

JS challenge will not bother your legit readers with solving puzzles like “click on all the boat pictures on the screen” and similar. It will just show a brief notification (a few seconds):

You can test this (to confirm it works) by opening an incognito browser window (CTRL+SHIFT+N) and trying to post a comment on your site.

Note:
If you have more than one firewall rule, only one of those will be activated: the first rule whose criteria are met.

For example, if you have another rule that is triggered if say “Referrer matches your website’s domain,” that criteria may be satisfied when someone tries to post a comment. And, if that rule is placed above the anti-spam rule we’ve just created, your anti-spam rule will never work, it will never get triggered.

However, since only posting comments satisfies the criteria “URI-Path contains wp-comments-post.php” rule, the solution is to place this rule on top, since no other event will trigger this rule (allowing us to have well-functioning other firewall rules).

Apart from the list order, there is also priority order for CloudFlare firewall rule execution (CloudFlare knowledge base link).

If this sounds a bit confusing, don’t sweat it, just place the here-described rule at the top and see if it works after an hour or so. How to confirm it works? It will show stats:

If you’ve done it all correctly, you will be able to confirm that your firewall rule gets triggered as easily as social justice warriors. 🙂

Firewall rules work nicely alongside CloudFlare Zero Trust security settings and rules.

– T.O.C. –

3. Preventing comment and contact form spam

You could make a rule similar to the above-described one to prevent your website’s contact form spam.

The first thing you need to do is figure out which link or URI is used for your contact form. For example, my sites have “/newsletter/” in their newsletter subscription links. So, I could just append that to the existing firewall rule, using the “OR” option to add additional criteria to the existing firewall rule:

– T.O.C. –

4. Conclusion

Using the here-described method provides a very good spam protection. It is also a lot more comfortable to use for the visitors – no boring CAPTCHA challenges to solve.

Also, it unloads your hosting server, because the check is executed by CloudFlare before reaching your server: if the challenge fails (i.e. it’s most probably a bot), your server doesn’t even receive the “comment attempt.”

Based on my experience so far, this can effectively replace any anti-spam WordPress plugins, and it is always better to have fewer plugins.
Having said this, I still love the TSF plugin which is the best SEO plugin I’ve tried so far, and its Honeypot anti-spam extension is super light weight, and a nice extra layer to catch any spammers who “slip through” the firewall protection so I don’t get bothered with dozens for “approve new comment” email notifications.

If you have any questions, additions or corrections, please use the comment section below. 🙂
You could also join the discussion on this topic on my favourite IT-related forum, LowEndSpirit:
WordPress comment and contact form spam blocking using Cloudflare (the LES forum discussion link).

– T.O.C. –

5. Search form spam prevention

Almost forgot to mention this little bugger. See, even if you disable any search icons on your site, anyone can add “?s=” (or “/search/”) to the end of your site’s URL and make WordPress execute a search. For example:

io.bikegremlin.com/?s=best wordpress theme

That’s why it’s a good idea to add these to your rules (the ones shown in picture 5 above):

URI Full | contains | ?s=
URI Path | contains | /search/

You could also add this to your robots.txt file (what is the “robots.txt” file and how to make it?):

User-agent: *
Disallow: *?s=*
Allow: /

That will tell Google (and other search engines and web crawlers) not to visit or index any search results pages of your website.

– T.O.C. –

Last updated:

14/10/2024

Originally published:

17/08/2023

Author

Relja Novović

Relja is an avid cyclist, a pretty good bike mechanic, and a professional computer systems administrator – with decades of experience in both those fields (computers and bikes 🙂 ). Relja Novović’s credentials and a short biography