=== Deny All Firewall ===
Contributors: domainsupport
Donate link: https://webd.uk/product/support-us/
Tags: security, firewall, htaccess, performance, carbon footprint
Requires at least: 5.0
Tested up to: 7.1
Requires PHP: 7.0
Stable tag: 2.0.1
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

Stop unwanted requests before WordPress loads. Deny All Firewall uses .htaccess to allow genuine content and refuse everything else.

== Description ==

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 and generated `robots.txt` file 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](https://webd.uk/can-a-wordpress-firewall-really-help-save-the-planet/).

= 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.

== Installation ==

1. Install and activate **Deny All Firewall** through the WordPress Plugins screen.
2. Open **Settings → Deny All Firewall**.
3. Select **Firewall Enabled** and review the settings that appear.
4. Save the settings to generate the firewall rules.
5. Test the public site, forms, search, sign-in, administration area and any shop or third-party integrations.
6. If something genuine is refused, temporarily enable **Blocked Request Troubleshooting**, reproduce the request and review it before allowing it.

You should also refresh the firewall rules after making significant content or configuration changes. The plugin displays a reminder when it detects relevant changes.

== Frequently Asked Questions ==

= Is this a replacement for WordPress updates, secure passwords or backups? =

No. Deny All Firewall reduces the public attack surface and unnecessary processing. Continue to update WordPress, themes and plugins, use strong authentication, maintain backups and follow normal server-security practices.

= Why deny everything instead of searching for known attacks? =

Attack signatures can identify known bad input, but they must continually account for new variations. Deny All Firewall begins with the smaller question: which public requests does this particular website genuinely need?

Requests outside that answer can be refused before WordPress processes them. This complements other security layers rather than making them unnecessary.

= Could it block part of my website? =

Yes. Strict rules can expose unusual requirements in forms, ecommerce extensions, webhooks, membership systems and third-party integrations.

The plugin preserves normal WordPress functionality and known public content, but it cannot predict every custom implementation. Test the site after enabling the firewall and use Blocked Request Troubleshooting to investigate genuine requests before allowing them.

= Does it block the WordPress REST API? =

No. The configured WordPress REST API path and `rest_route` requests remain available. Write methods such as `PUT`, `PATCH` and `DELETE` are refused elsewhere because ordinary public WordPress pages do not normally need them.

= Will it block robots.txt or WordPress sitemaps? =

No. The plugin generates a static `robots.txt` file from WordPress's filtered output so crawlers do not need to load WordPress repeatedly. The standard WordPress sitemap remains allowed.

If the website already has a physical `robots.txt` file that Deny All Firewall did not create, it is left unchanged.

= What information does Blocked Request Troubleshooting record? =

The temporary log records information needed to identify a refused request, including the requested address, time and originating IP address. Logs may therefore contain personal data under some privacy laws.

Logging is disabled automatically when the firewall is disabled. The log is limited to approximately 10 MB and is deleted when troubleshooting is turned off.

= What happens when I publish new content? =

Exact Content Protection may need a refreshed rule for newly published content. The plugin monitors relevant content changes and displays an administrator notice when its rules should be refreshed.

Larger sites use broader automatic matching and do not require an individual rule for every public item.

= What if I am locked out? =

Use your hosting control panel, FTP or file manager to edit the site's `.htaccess` file. Remove only the section between:

`# BEGIN Deny All Firewall`

and:

`# END Deny All Firewall`

Do not delete unrelated WordPress or hosting rules. Once access is restored, review the firewall settings and refresh its rules.

= Does it support Nginx, IIS or servers that ignore .htaccess? =

Not currently. The generated rules require Apache with `mod_rewrite` and `.htaccess` support.

= Does disabling or deactivating the plugin remove its rules? =

Disabling the firewall through its settings removes the generated `.htaccess` section. Properly deactivating the plugin also removes its generated rules and its own generated `robots.txt` file.

An existing `robots.txt` file that was not created by the plugin is preserved.

== Changelog ==

= 2.0.1 =
* Removed an unnecessary Block wp-login exception so public administration-email confirmation requests remain blocked
* Prevented activation or enabling when an incompatible server or unusable `.htaccess` location can be confirmed
* Added refresh locking to prevent simultaneous requests from duplicating, replacing or restoring firewall rules

= 2.0 =
* Improved the accuracy and compatibility of generated `.htaccess` rules, including HTTP-method handling, REST requests, Cloudflare
* Added automatic Content Protection and Admin Access Protection that adapt before content or active-session IP rules become too large
* Improved active-session IP handling with broader IPv4 matching, exact IPv6 matching and removal of expired sessions
* Replaced the legacy sitemap with a static filtered `robots.txt` file while preserving WordPress sitemaps and adding automatic deactivation cleanup
* Redesigned the settings and troubleshooting experience with clearer guidance, safer allowed requests, redirects and numerous reliability improvements

== Upgrade Notice ==

= 2.0.1 =
* Improves Block wp-login compatibility, checks server requirements and prevents simultaneous firewall-rule updates.
