WordPress Firewall Plugins: What They Do and Which to Use

A WordPress firewall, also called a Web Application Firewall or WAF, inspects incoming requests and blocks malicious ones before they can exploit vulnerabilities in your plugins, themes, or WordPress core. It's a different layer of protection from login limiting or malware scanning, and it's one of the most effective defences against the automated exploit tools that scan WordPress sites at scale.

What a WordPress WAF actually does

A WAF examines the characteristics of each incoming HTTP request: the URL path, query parameters, POST body, HTTP headers, and cookies. Requests that match known attack patterns are blocked before they reach your PHP code. Examples of what a WAF intercepts:

• SQL injection: Requests with SQL syntax in parameters attempting to query or modify your database directly (e.g., ?id=1 UNION SELECT user_pass FROM wp_users).
• Cross-site scripting (XSS): Attempts to inject JavaScript into form inputs or URL parameters that would execute in other users' browsers.
• Directory traversal: Requests trying to access files outside the web root using path manipulation (../../wp-config.php).
• Known plugin exploits: Requests matching the signature of publicly documented vulnerabilities in specific plugin versions, for example, a request pattern matching a known file upload exploit in a specific version of a form plugin.
• Remote code execution: POST requests attempting to pass PHP code through vulnerable parameters in outdated plugins.

The result is that even if you have a vulnerable plugin installed and haven't yet updated it, many exploit attempts are blocked at the firewall level before they can execute. A WAF buys you time, it's not a substitute for keeping plugins updated, but it reduces your exposure window between vulnerability disclosure and patching.

Plugin-level WAF vs DNS-level WAF

Plugin-level (Wordfence, iThemes Security, All In One WP Security): The firewall runs as PHP code on your server. It hooks into WordPress's early bootstrap process, before most of WordPress has loaded, and inspects each request. Effective, but the web server still receives the request, PHP still initialises, and your server still processes it before the firewall can block it. Under a high-volume attack, your server consumes resources for every blocked request.

DNS-level (Cloudflare WAF, Sucuri WAF): Traffic is routed through the provider's network before reaching your server. Your DNS records point to the WAF provider's IP, and your real server IP is hidden. Malicious requests are filtered and dropped at the network edge, your origin server never receives them. This approach handles DDoS protection more effectively since attack traffic is absorbed at the edge rather than at your server.

Both are better than neither. For most sites, a plugin-level WAF is sufficient and simpler to configure. High-traffic sites or sites that face regular DDoS or scraping attacks benefit from moving to a DNS-level WAF.

Wordfence Security (free and premium)

Wordfence is the most widely installed WordPress security plugin. Its WAF uses a rules database updated by Wordfence's threat intelligence team. Configuration steps for the WAF:

• Install Wordfence from the plugin repository and activate it.
• Go to Wordfence > Firewall. The WAF starts in "Learning Mode" for a week, which allows it to observe your site's normal traffic patterns before enabling blocking mode. After the learning period, Wordfence will recommend switching to "Enabled and Protecting."
• Go to Wordfence > All Options > Firewall Options. Enable "Web Application Firewall Status" as "Enabled and Protecting." Set "Protection Level" to Extended if your server supports it, this makes the firewall run earlier in the PHP lifecycle, before some WordPress hooks.
• Under "Brute Force Protection," enable all options: lock out after X failed attempts, lock out after X forgot password attempts, and block IPs that send invalid usernames.
• Set up email alerts (All Options > Email Alert Preferences) for: WAF blocks exceeding a threshold, new admin users created, and core file changes detected.

The free version receives firewall rule updates 30 days after the premium version. This delay matters for zero-day vulnerabilities discovered in popular plugins, the 30-day window is when active exploitation is most common. If you manage multiple sites or high-value sites, Wordfence Premium (~£90/year) closes this window.

Cloudflare WAF (free and paid)

Cloudflare operates at the DNS level. Configuring Cloudflare involves pointing your domain's nameservers to Cloudflare, after which all traffic passes through Cloudflare's network before reaching your origin server. The free plan includes:

• DDoS mitigation (automatic for the most common attack types)
• Basic managed WAF rules covering OWASP Top 10 attack patterns
• Bot traffic challenges via browser integrity check
• IP reputation blocking (known malicious IPs blocked automatically)
• Custom firewall rules (5 rules on the free plan, 20 on Pro)

A particularly useful free-tier custom rule for WordPress: create a rule that challenges (shows a CAPTCHA to) any IP that makes more than 5 requests per 10 seconds to /wp-login.php. In Cloudflare > Security > WAF > Rate Limiting Rules, this handles the most common brute force attack pattern before it ever reaches your server.

Cloudflare Pro ($20/month) adds OWASP managed rulesets, WordPress-specific managed rules, and more granular rate limiting. For most WordPress sites, Cloudflare free plus Wordfence free provides adequate coverage without paid tiers on either.

Sucuri's WAF option

Sucuri operates a DNS-level WAF similar to Cloudflare, starting at around £199/year. It's a CDN plus WAF with WordPress-specific rules maintained by Sucuri's security team. The Sucuri WAF includes virtual patching, when a vulnerability is discovered in a popular plugin, Sucuri pushes a WAF rule to block exploits before the plugin developer even releases a patch. For sites that can't patch immediately (due to compatibility concerns or change control processes), this is a meaningful safety net.

Sucuri's paid plans also include malware removal as part of the subscription, which changes the risk calculation significantly. Sucuri's free plugin (available on wordpress.org) provides security monitoring and hardening but not the WAF, the WAF is a paid feature requiring DNS changes.

Don't run multiple competing firewalls

Installing Wordfence, iThemes Security, and All In One WP Security simultaneously is counterproductive. Each plugin hooks into the same WordPress events, producing conflicting rules, duplicate log entries, false positives from one plugin blocking another, and significant PHP overhead per request. Pick one comprehensive security plugin and configure it thoroughly rather than installing multiple incomplete ones and relying on them to collectively cover the gaps.

The exception is combining a plugin-level WAF with a DNS-level solution: Cloudflare (DNS level) plus Wordfence (application level) work well together. They operate at different layers without conflicting. Disable Wordfence's brute force protection if you're already doing rate limiting at the Cloudflare level to avoid double-counting and conflicting lockout states.

Verifying your WAF is active and blocking

In Wordfence, go to Wordfence > Firewall > Firewall Status. You should see "Enabled and Protecting" with a count of blocked attacks in the stats. The "Blocked Attacks" count updating over time confirms the WAF is actively intercepting requests. In the firewall log (Wordfence > Firewall > Blocked IPs & Attacks), you can see individual blocked requests with the rule that matched them, this gives you a live view of what's being caught.

For Cloudflare, go to Security > Overview in your Cloudflare dashboard. The "Security Events" chart shows events over time. Drill into individual events to see which rules matched, what the request contained, and whether it was blocked or challenged.