Most WordPress firewalls start with everything open and look for known bad requests.

Deny All Firewall turns that idea around.

It examines your WordPress site and creates Apache .htaccess rules that allow its genuine public content and normal WordPress functions. Requests outside those rules are refused by the web server before WordPress, PHP, the database, your theme or your other plugins need to process them.

That means less work for your server and fewer opportunities for automated scanners to explore files and addresses your website does not need to expose.

A deny-by-default firewall for WordPress

Deny All Firewall generates rules specifically for the site on which it is installed. Depending on your content and configuration, those rules can:

Allow published pages, posts, products, media, archives, feeds and sitemaps
Keep the WordPress REST API, WP-Cron and admin-ajax.php available
Allow the public files required by your active theme and plugins
Refuse direct access to PHP and other files that should not be requested publicly
Reject unsupported HTTP methods before they reach WordPress
Reduce common reconnaissance such as user enumeration and plugin or theme probing
Restrict /wp-admin/ to IP addresses used by active signed-in sessions when practical
Work with Cloudflare visitor IP addresses when the request genuinely came through Cloudflare
Send refused requests to the plugin’s lightweight blocked page

This is not a generic list copied into every .htaccess file. The firewall is built around the content and features WordPress reports for your website.

Automatic protection that adapts to your site

Content Protection uses individual rules on smaller sites. When the number of rules would make .htaccess too large or slow, the plugin automatically switches to broader public-content matching. If the site becomes smaller again, exact protection can return automatically.

Admin Access Protection can limit /wp-admin/ to IPv4 ranges and exact IPv6 addresses associated with active WordPress sessions. If a site has several active non-administrators or would require too many IP rules, this extra restriction is relaxed automatically. WordPress authentication still protects the administration area.

These decisions are made when the firewall rules are refreshed, not on every page view.

Optional Extra Request Protection

Extra Request Protection checks information added after a ? in a page request and blocks unexpected form submissions. Normal WordPress requests and anything you explicitly allow remain available.

This is intentionally strict. Forms, shops, webhooks and third-party integrations can have site-specific requirements, so test them carefully after enabling it.

Clear troubleshooting when something genuine is blocked

Temporarily enable Blocked Request Troubleshooting to record refused addresses. The settings page explains common requests and lets you add a recognised request directly to Allowed Requests and Redirects.

Allowed entries can:

Match one exact address
Use an advanced pattern when genuinely needed
Permanently redirect an old address elsewhere with a 301 response

Troubleshooting is intended to be temporary. Its log is limited to approximately 10 MB and is deleted when troubleshooting is disabled.

Less repeated work

The plugin creates a physical copy of WordPress’s filtered robots.txt output when the firewall is refreshed. Search engines can then read the same instructions without repeatedly loading WordPress and PHP. An existing robots.txt file that was not created by Deny All Firewall is preserved.

WordPress’s standard sitemap remains available, along with supported sitemap files created by SEO plugins.

The plugin also:

Alerts administrators when content changes may require refreshed firewall rules
Offers an optional HTTPS redirect for sites on which HTTPS is already working
Removes WordPress version information from page and feed metadata
Removes its generated .htaccess rules, generated robots.txt file and runtime files when properly deactivated

Security, performance and unnecessary carbon emissions

Refusing nonsense at the web-server level is much cheaper than loading an entire content-management system merely to decide that the requested content does not exist.

On a heavily scanned WordPress site blocking around 50,000–100,000 unwanted requests per day, we estimate that Deny All Firewall could avoid approximately 100 kg of CO2 emissions per year—roughly comparable to the direct emissions attributable to one passenger on a one-way flight from London to Ibiza!

Read the calculation, assumptions and limitations.

Important requirements

Deny All Firewall currently supports Apache, using mod_rewrite and .htaccess
Your site’s .htaccess file must be writable; the website root must also be writable when the plugin needs to create its static robots.txt file
Because this is a deny-by-default firewall, test important forms, checkout journeys, webhooks and integrations after enabling it
Keep a normal backup and know how to edit .htaccess through your hosting control panel or file manager before enabling any firewall

If the plugin blocks a genuine request that is not covered by its troubleshooting tools, please report it through the support forum.