Warning: WordPress Caching Plugins and Wordfence
According to WordPress.org, if you do the math, more than 9 millions of WordPress sites use a page caching plugin. Page caching plugins help budget hosting plans to perform better and also make high traffic websites to be faster.
Page caching plugins use two “methods” to serve the cached static pages, PHP or the most popular via “mod_rewrite” within your .htaccess file.
A few months ago, we installed Wordfence on a medium traffic travel site, since the site owner was fixated on Wordfence. This was probably because he saw that Wordfence had over 4 million active installations on WordPress.org.
We had the opportunity to see how Wordfence performed on a live medium traffic site, as it is the number one choice for a security plugin for WordPress. With four million active installations, it can’t be that wrong.
Installation was smooth. However, an unneeded file (.user.ini) was created during the optimized firewall activation, since the PHP prepend of WAF was already in the .htaccess file.
The settings are clear and, to our surprise, a lot of features are included in the free version. We mean a lot. Features like Rate Limiting, Advanced Blocking, and a great live traffic viewer. The Live Traffic page can get you addicted and you can spend hours just looking.
Apart from the fact that Wordfence is a heavy plugin, we didn’t notice any other issues or problems.
Well… until we did.
At some point, a fast scraper from Russia made the website very slow for a few hours. This was rather strange because Wordfence’s rate limit was activated for bots and humans with a maximum of 60 visits per minute and then BLOCK (not rate limit but block). Also, the website was using a page caching plugin, so that was a double mystery.
It was clear that something was wrong with Rate Limiting. So we made some very strict settings just for testing purposes, with 10 visits per minute and we tested that from some external IP. And we were surprised to see that rate limiting didn’t work at all.
Searching the Wordfence site, we didn’t find any related information. So we had to disable some plugins one by one and test.
And then someone mentioned the page caching plugin. And he was right. It was the page caching plugin that made Wordfence Rate Limiting unusable. And it makes sense since Litespeed caching plugin is using mod_rewrite and mod_rewrite in .htaccess has priority. So the page is served to the visitor before WordPress and rate limiting doesn’t work.
We tested other caching plugins like Fastest Cache (mod_rewrite mode) and WP Super Cache (PHP mode) and they all behaved the same. So even with PHP mode, the results for some reason are the same: Rate Limiting didn’t work with page caching. We don’t know how Wordfence behaves with other types of caching like memcached or redis. Also, we don’t know if Wordfence Rate Limiting is the only feature not working when a page caching plugin is active. Maybe other features don’t work properly and we just didn’t find them. And that is scary for a security and firewall plugin.
So if you use Wordfence, do not use any page caching plugin, free or commercial. Wordfence must include a warning in their knowledge base about it. The vast majority of WordPress site owners and webmasters have no idea about all that and they could be unprotected.
As you can see in the capture, WordPress is not an “exact science” when it comes to rate Limiting and probably other features.
https://www.valueweb.gr/wp-content/uploads/2023/11/2023-11-30-17_08_46-Live-Traffic-‹-Tools.jpg
Yeap, Rate Limiting can’t be exact science when a storm comes in. Racing issues and other technical matters. Still it works most of the time.
I use WP Supercache for years, along with Wordfence and never had an issue.
There is a very short mention about all that in their FAQ but very very generic:
Worst … now they try to push a paid license to everyone.
If you want a caching plugin for WordPress that works 100% well with Wordfence, get WP Rocket plugin.
The best commercial caching plugin.
WP Rocket cache plugin makes no difference with Wordfence.
It has the very same issues and there is no reason to pay for that.
Their support at WordPress.org sucks. Everytime we are asked to send a diagnostic email within Wordfence and after people do, they get some vague replies usually from copy paste faqs.Sometimes they get no replies at all.
If you check the support forum, you will notice that. Getting real help is rare.
Wordfence is a heavy beast, always that has conflicts with other plugins or themes.
There are better security plugins and firewalls for WordPress …..
There are some topics about that at WordPress.org
https://wordpress.org/support/topic/page-caching-issue-with-wordfence/
https://wordpress.org/support/topic/wp-fastes-cache-and-rate-limiting/
but the replies do not offer any kind fix for that.
Some reports in there are left unanswered
https://wordpress.org/support/topic/cache-and-rate-limiting/
Apparently no caching plugin, in any mode, work with Wordfence correctly,
Thanks for clearly pointing that out.
Yes, they do that a lot, if some question is somehow compicated … you never get a clear answer…..
I guess ANY firewall and security plugin will have some issues when a page caching plugin for WordPress is active.
When mod_rewrite mode is used to serve the pages, it is guaranteed that the visitor is NOT always blocked.
I write “not always” because the firewall will still work for attacks, 404s probes (if 404s are not cached), NEW not yes cached posts and anything that is NOT cached for some reason.
Several years back, Wordfence had a caching mechanism for Wordfence, called Falcon Engine.
For some reason that project was abandoned and then removed from the plugin. So they should know all about caching.
Maybe you should contact them with all that information?
Those were the days ….
https://www.wordfence.com/blog/2014/04/wordfence-5-with-falcon-engine-released/
We have seen that before with WordPress and some php script we wanted to auto-prepend. While the visitor was logged in the script as blocked, the visitor was able to normally visit and browse the site.
BUT that happened only with WordPress page caching plugins in mod_rewrite mode (Litespeed cache, Faster Cache in mod_rewrite mode and WP Super Cache in mod_rewrite mode).
As soon as we used caching plugins in PHP mode, the issue is gone. Fastest cache has a php option via a wp-config directive and also WP Super cache in Simple mode is actually in PHP mode.
That makes me believe that this could be a BUG of Wordfence and not an issue with all caching plugins. But those complicated issues will never be verified and tested by developers, so it is better not to use ANY caching along with Wordfence. And Wordfence SHOULD warn users about it.
There is a logic in what you say, that if a caching plugin is using php mode to serve the cached pages, it should work well.
But i assure you, it doesn’t. We have a very knowledge guy in the company i work for, in Belgium, and he had even tried WP Super Cache with Late Init option enabled. And still it doesn’t work.
So yeap, maybe it is a WordPress bug. Wordfence prepends the waf before WordPress, in .htaccess. I don’t know if that waf is for the firewall only or also controls somehow the rate limit.