Wordfence Rate Limiting: Accuracy and Effectiveness

“Wordfence is an extremely popular security plugin for WordPress. Among its features, Rate Limiting allows you to control how many pages visitors and automated crawlers can access your website per minute. If they exceed the limits you’ve specified, their access will be temporarily revoked, and they’ll receive a message indicating that their access to your site has been limited. Additionally, Wordfence provides the option to use rate limiting for handling 404 errors (page not found).

You can choose to either block users or bots immediately, which removes their access for a predetermined amount of time (as defined by the setting “How long is an IP address blocked when it breaks a rule”), or simply limit their access. The recommended rate limiting settings depend on your site’s configuration and design. For well-configured websites, you can set the rate limit as low as 30 requests per minute, or even 15 requests per minute if a crawler generates many “Not Found” (404 response status code) errors. However, be cautious, as overly strict settings may inadvertently block legitimate users or friendly bots.

Additionally, Wordfence treats Google’s crawlers differently, ensuring they have greater access than normal site visitors. Google crawlers are essential for indexing your site, so they are exempt from rate limiting restrictions.

Remember that this is a fun approximation and not a scientifically accurate measurement.

But how accurate is rate limiting? Does it work correctly when page caching is enabled?

For testing purposes, we have set a human/bot limit (anyone) to 15 requests per minute, with a block time of 1 minute (so we do not have to wait longer).

Below, you can see the number of page requests that Wordfence allowed before a block is enabled:

• NEVER indicates that we reached 50 hits without any block. Then we gave up :)
• The pages we manually visited repeatedly were 6.
• We used the Fastest Cache Page Caching Plugin in PHP mode (PHP directive in the WP configuration file).
• We also used WP Super Cache in Easy Mode (PHP Mode).
• Additionally, we employed the Redis Object Cache plugin and Docket Cache plugin.

No Caching	Fastest Cache	WP Super Cache	Redis Plugin	Docket Cache
16	* NEVER *	* NEVER *	17	16
16	* NEVER *	* NEVER *	16	16
19	*NEVER *	* NEVER *	19	16
20	*NEVER *	* NEVER *	16	17
16	*NEVER *	* NEVER *	16	18
18	*NEVER *	* NEVER *	18	16

Indeed, the interaction between page caching and rate limiting can be intricate. Let’s delve into this further:

Rate Limiting and Page Caching Interaction when page caching is enabled:

Positive Impact: Caching reduces server load, which indirectly benefits rate limiting by minimizing the number of requests reaching the server.

Challenges:

Predictability: As mentioned, page caching can sometimes make rate limiting less predictable. Cached pages may serve multiple requests without triggering rate limits.

Granularity: Rate limiting typically operates at the API or server level, whereas page caching operates at the page level. This granularity mismatch can lead to discrepancies.

Cache Hits: Cached pages are served directly from memory, bypassing rate limiting checks. If a page is cached, rate limiting won’t apply until the cache expires.

Mitigation Strategies:

Cache Exclusion: Exclude certain pages (e.g., login, checkout) from caching to ensure rate limiting still applies.

Dynamic Elements: Handle dynamic elements (e.g., user-specific content) separately from caching.

Cache Invalidation: Implement cache invalidation mechanisms to refresh cached pages when rate limits change or when specific events occur.

Plugin Behavior: Understand how caching plugins (e.g., Fastest Cache, WP Super Cache) interact with rate limiting features.

Redis & Docket Object Cache: Redis and Docket Cache, as object caches, don’t directly affect rate limiting. They store data in memory, improving overall performance, but rate limiting decisions still occur before caching.

Conclusion:

Wordfence Rate Limiting: While caching can impact its predictability, thoughtful configuration and testing can mitigate issues.

Redis & Docket Cache Object Caching: It works independently of rate limiting and can enhance performance by reducing database queries.

Balance: Striking the right balance between caching, rate limiting, and dynamic content handling is essential for optimal security and performance.

Remember that each website’s setup is unique, so thorough testing and monitoring are crucial to ensure both security and speed are maintained.