What the WordPress firewall plugin refuses in Block mode
The firewall has three modes. Off does nothing. Monitor records what it would have refused and lets everything through. Block refuses requests that match a critical rule.
Only the critical rules refuse anything. Warning rules, which cover cross-site scripting patterns, bad bots and weaker SQL injection or code-execution patterns, are recorded so you can see them, but they don't stop the request. The fuzzier rules can't take your site down that way.
The firewall is one part of WP SecureGate, which also covers sign-in security, malware scanning and WooCommerce checkout.
Block mode on new installs. A site that ran an older version keeps the mode it had, which may be Monitor.
A learning week before it gets strict
For its first 7 days on a new install, the firewall blocks attacks while it learns your team's own requests. When a signed-in editor or admin trips a rule doing normal work, it learns a narrow exception: one rule, at one endpoint, in one part of the request. No one else can teach it.
After at least 3 days of learning it suggests two limits based on your real traffic. The rate limit is three times your peak requests per minute, kept between 60 and 600. The 404 limit is three times your peak 404s, kept between 10 and 100. Applying either takes one click.
Runs for 7 days on new installs. Existing sites keep their current mode.
Rate limiting for WordPress
Rate limiting caps how many requests one address can make per minute: 240 in general and 30 on sensitive endpoints. It's enforced only in Block mode. Jetpack and WordPress.com addresses are exempt.
A separate 404 throttle limits scanners that probe for files you don't have, and auto-block can shut out an address that keeps tripping the firewall.
Rate limiting, the 404 throttle and auto-block are all off by default. Rate limits apply only in Block mode.
Attacker scoring
Attacker scoring looks for an address doing more than one kind of bad thing. Over an hour, an address builds a score from at least 2 different kinds of bad behaviour; one kind on its own never counts. At 10 points its suspicious requests are refused as well. At 20 it is blocked for an hour.
Some addresses are never scored: your allowlist, WordPress.com, private addresses, and any address your editors and admins signed in from in the last 30 days.
On for new installs and offered in Recommended for existing sites. Works only in Block mode.
The signed attacker list and network learning
Each day the plugin downloads a list of known attacker addresses and checks its Ed25519 signature. A list signed more than 7 days ago isn't used. In Block mode, addresses that come from public threat feeds are refused.
Network learning adds addresses that other WP SecureGate sites have seen. Once a day, a licensed site reports the addresses its firewall blocked for an attack, with the attack type, rule and count and nothing else about the request. Only attack-tool traffic and scripts that don't name themselves count. Browsers, link previews and crawlers never do. An address joins the network list only after 3 or more separate customer accounts report it. The privacy page sets out what a report contains.
In Block mode, a network-only listing is refused in a few places, and nowhere else. In Monitor mode it is only recorded. The places are:
- sign-in, registration and password reset;
- XML-RPC, the user list and ?author= enumeration;
- requests that match the SQL injection, code-execution, file-inclusion or path-traversal rules.
Both on by default and need an active licence. Turn off reports at Firewall → Settings → Threat intelligence; you still get the list.
Extended protection before WordPress loads
By default the firewall runs early in WordPress. Extended protection moves it in front of WordPress entirely, so it checks every PHP request. How it's installed depends on your host: PHP-FPM uses .user.ini, Apache with mod_php uses .htaccess and undoes itself if the site breaks, and LiteSpeed uses both. Other hosts need one php.ini line added by hand.
Cached pages pass through the firewall only when the cache is WPCacheX. Other page caches serve their copies without it.
Opt-in, one button. Needs a licence.
WordPress bot protection, Cloudflare and proxies
Two user-agent rules target bots. One records requests that send no browser name, a weak signal that is never refused on its own. The other checks anything claiming to be a search-engine crawler against DNS and, in Block mode, refuses the ones whose address doesn't match. Real crawlers aren't touched.
Cloudflare is detected automatically and other proxies are learned from traffic. That matters because a firewall that mistakes a proxy for the visitor would limit or block the wrong address. For per-address and country rules, see IP blocking.
Both user-agent rules are off by default.
Part of WP SecureGate: the all-in-one WordPress security plugin →