About this plugin
Most WordPress firewalls start with everything open and look for known bad requests.
Deny All Firewall turns that idea around.
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
- Reject routine /wp-admin/ scanner traffic unless the request presents this website’s WordPress logged-in cookie
- Work with Cloudflare visitor IP addresses when the request genuinely came through Cloudflare
- Send refused requests to the plugin’s lightweight blocked page
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. 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 reject routine /wp-admin/ scanner traffic unless the browser presents this website’s WordPress logged-in cookie. Apache checks only for the cookie’s presence; WordPress still validates it and requires users to sign in normally.
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
txt output when the firewall is refreshed. Search engines can then read the same instructions without repeatedly loading WordPress and PHP. 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
- Records a small selection of blocked suspected malicious requests and summarises the last 60 minutes for administrators on the Dashboard
- 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.