Security
What a WordPress firewall does, and what it does not
11 August 2026 · 6 min read
On this page
"Firewall" suggests a wall. It is closer to a bouncer with a list of known troublemakers — useful, and limited in ways the name obscures.
What it actually does
A web application firewall inspects incoming requests and blocks those matching known attack patterns: SQL injection attempts, requests targeting a specific vulnerable plugin, obvious probing for files that should not be reachable.
The key word is known. A WAF works from rules describing attacks someone has already catalogued. It is pattern matching, not comprehension.
Two kinds, and the difference matters
Plugin firewalls — Wordfence, Solid Security — run inside WordPress. The request reaches your server, PHP starts, WordPress loads, and then the firewall decides.
That means it can see everything WordPress sees, including who is logged in, which makes its rules smarter. It also means every blocked request still consumed your server's resources. Under a sustained attack, your site can slow down while successfully blocking everything.
Cloud firewalls — Sucuri, Cloudflare — sit in front of your site at DNS level. Traffic reaches them first and never touches your server unless it passes.
Better protection and better performance, because bad traffic is stopped before it costs you anything. The trade-offs are that your DNS points at them, they see all your traffic, and it is a monthly cost rather than a plugin.
Where it genuinely earns its place
Virtual patching. This is the best argument for one. When a vulnerability is disclosed in a plugin you run, a good WAF can block requests exploiting it before the plugin author ships a fix. That buys you days during the window that matters most.
Blocking the obvious. Scanners probing for known-vulnerable paths, requests with injection payloads, traffic from networks with nothing to do with your business.
Rate limiting and bot control. Keeping your server from doing pointless work.
Where it does not help
Against a vulnerability it does not have a rule for. A novel exploit passes straight through.
Against a legitimate-looking request. If an attacker has valid credentials, the firewall sees a normal login.
Against anything already on the server. A WAF inspects incoming traffic. Malware sitting in your uploads folder is not incoming traffic.
Against your own outdated plugins. It may block one exploitation route while the plugin stays vulnerable to others.
The failure mode to avoid: a firewall creating enough confidence that updating feels optional. It is a delay mechanism, not a fix. Sites with a firewall and eighteen-month-old plugins get compromised regularly.
Do you need one?
Probably not, if your site is a small brochure site, you update weekly, you have two-factor on, and you are not seeing attack volume that affects performance. The basics genuinely cover most of the risk.
Yes, if you run a shop, handle customer data, have been compromised before, run plugins that receive frequent disclosures, or your host resources are being eaten by bot traffic.
Cloud rather than plugin, if performance under attack matters, or if you are already using a CDN — in which case you may effectively have one already. Cloudflare's free tier includes basic protection most people never turn on.
Order of operations
If you are deciding where to spend effort, this is the honest ranking:
- Update weekly
- Two-factor and unique passwords
- Off-site tested backups
- Delete unused plugins and themes
- Then a firewall
A firewall bought instead of items 1 to 4 is money spent on the wrong problem. Bought in addition to them, it is a reasonable extra layer — particularly the virtual patching.
That is how we treat it: our advanced security add-on includes a WAF at $29 a month, on top of the weekly updating that does the heavy lifting. The order matters more than the products.