Block brute force on wp-login with CloudFlare page rules
As a WordPress user, developer or web host you may have experienced the pain of a brute force attack targeting wp-login.php.
What is a brute force attack?
It’s when a malicious script hammers your wp-login.php page, trying usernames and passwords, over and over again, trying to break in.
If you have a weak username or password, the attacker gets in. Bad times.
If you have a strong username and password, the attacker can’t get in (yay) but the server gets hammered (with http requests), typically causing memory spikes and often crashing under the load. Also bad times.
The wordpress.org codex points out, “this sort of attack is not endemic to WordPress, it happens with every webapp out there, but WordPress is popular and thus a frequent target.” Totally true, but not much consolation if you’re on the receiving end of a brute force attack on your WordPress site!
Here’s the solution that worked best for me…
Use Cloudflare page rules to block brute force attacks.
- Login to your CloudFlare account.
- On the Websites page look for your target domain then click on the gear icon on the right side. Select Page Rules.
- Add the following URL patterns.
The asterisks are wildcards used to take account for login urls that uses a sub-domain like
blogor urls that end like
- *Most important step* Set the Security and Browser Integrity Check to ON and the Security Level to I’m Under Attack. Then click Add Rule.
These page rules do a browser integrity check on the wp-login page and treat everything going to that page like it’s a potential attack. Real visitors to your site won’t be affected at all. Any legitimate users who need to login to WP Admin will see a Cloudflare browser check for a few seconds.
Why recommend this over other methods?
There are many other methods of stopping brute force attacks as outlined in the codex here. But I love this method of blocking brute force attacks using Cloudflare page rules because it is incredibly simple to understand, and to implement. It does not require mucking with your .htaccess, or with other server side solutions such as .htpasswds, modsecurity, Nginx etc. Nor does it rely on plugins, which work by executing code… when you’re under brute force attack the last thing you want is yet more http requests generated by a plugin.