Skip to content

Restrict the WordPress admin area to your own IP addresses

Close wp-login.php and /wp-admin to every address except the ones you name, from the Security tab of a site. Which areas the filter covers, which address formats are understood, what a blocked visitor sees, how IP pools work across a fleet, and how to get back in if you lock yourself out.

Last updated

The WP Safer IP firewall is a per-site rule that decides, by network address alone, who may open the WordPress admin area of that site. It is applied by the WP Safer plugin on the site itself and managed from the Security tab of the site in your dashboard.

Most attacks on a WordPress site arrive at the same two doors: wp-login.php and /wp-admin. If the people who actually sign in to a site always come from a handful of addresses — an office line, a VPN, your own fixed connection — you can close those doors to everyone else from your WP Safer dashboard. Nobody has to touch a server configuration file.

This is a door in front of the WordPress admin area, not a web application firewall. It does not read requests, look for malicious patterns or scan anything. It asks one question about one thing: which address is this request coming from, and is that address on the list.

Which requests the filter checks

The filter is applied by the WP Safer plugin on the site itself, and it can cover four areas:

  • Login page (wp-login.php) — on by default.
  • Admin area (/wp-admin) — on by default.
  • XML-RPC (xmlrpc.php) — on by default.
  • admin-ajax.php and admin-post.php — off by default, for the reason explained below.

Everything else is left alone. The public pages of the site are never filtered, the WordPress REST API is never filtered, and neither is /wpsafer-api — the endpoint your dashboard talks to. That last one matters: the signed requests your dashboard sends — backups, updates, uptime checks — keep working exactly as before, whatever you put on the list. WP-CLI commands and WordPress cron runs are also exempt, because a command run on the server has no visitor address to judge.

How to turn it on

  1. Open the site in your dashboard and go to the Security tab.
  2. Under Rule, pick Allow list or Block list.
  3. Type the addresses into Addresses, one per line. The button underneath, Add my address, fills in the address you are connecting from right now; the card at the top of the tab shows it as well.
  4. Under Areas to protect, leave the defaults unless you have a reason to change them.
  5. Press Save and send to the site.

Saving and sending are two separate events. The dashboard writes its own record first and then sends it to the site. If the site cannot be reached at that moment, your list is not thrown away — the tab tells you it was saved here but did not go out, and it goes out the next time you save.

The site needs the WP Safer plugin on version 1.3.6 or newer. On anything older the tab says so, and it means it: the setting is stored, but the site filters nothing at all. Update the plugin first, then save the rule.

Allow list or block list

Allow list means only the addresses you wrote can reach the protected areas; everyone else is turned away. This is the strong setting, and the one that can lock you out, so read the section on that below before you save one.

Block list is the opposite: everyone reaches the admin area except the addresses you wrote. It is the right choice when you are shutting out one noisy network rather than reserving the site for a known office.

There is also Off. It stops the filtering but keeps the list, so you can switch a rule off for an afternoon and switch it back on without typing everything again.

Which address formats are understood

  • A single IPv4 address: 203.0.113.10
  • A single IPv6 address: 2001:db8::1 (the short and long spelling of the same address count as the same address)
  • A CIDR range, IPv4 or IPv6: 10.0.0.0/8, 2001:db8::/32
  • A wildcard, IPv4 only and only on the right: 192.168.1.* works, 1.*.3.4 does not
  • A range: 1.2.3.10-1.2.3.50, or the short form 1.2.3.10-50 inside the same block

A line that cannot be read is not dropped in silence. The message after saving names the lines that were left out, so a typo in one address never turns into a rule that quietly does something else. A list keeps up to 200 addresses; anything beyond that is not sent to the site.

Why admin-ajax.php and admin-post.php are off by default

Those two files are not only used by admin screens. The public side of a WordPress site uses them constantly: contact forms, cart updates, filters on a shop page, anything a plugin does in the background while an ordinary visitor is on the site.

Protect them with an allow list and you are not locking down the admin area — you are breaking the site for every visitor who is not on your list. Leave the switch off unless you know that nothing on the public side of that particular site touches those two files.

What a blocked visitor sees

By default, a plain 403 page: “Access to this area is restricted from your network address.” Nothing is revealed about the list or about the site.

If you prefer them to land somewhere else, fill in Send blocked visitors to with a complete address including the scheme — https://example.com/ — and the request is redirected there instead, with a temporary (302) redirect. The target does not have to be on the same domain. Anything that is not a valid address is refused when you save. Leave the field empty for the 403.

The decision is made on the address alone, before WordPress has any opinion about who you are. Being logged in as an administrator makes no difference: if your address is not allowed, the page is refused.

Which address the site actually sees

The site judges the address its own web server reports. The one exception is a request that genuinely arrives from a Cloudflare edge or from a reverse proxy on the same machine: there the address Cloudflare passes along is used instead, so a site behind Cloudflare still sees real visitor addresses. A header claiming to be from Cloudflare on a request that did not come through Cloudflare is ignored — otherwise anyone could walk through a block list by inventing one.

If the site sits behind some other proxy or CDN that reports visitor addresses in its own way, WordPress may see that proxy for every request instead of the visitor. An allow list is worth nothing in that situation: either everybody matches or nobody does. The safest check is the Recently blocked list on the Security tab — it shows the addresses the site really saw.

Blocked attempts

The site keeps a counter and the last 20 addresses it turned away; both are shown on the Security tab as Blocked so far and Recently blocked. The same address is written at most once a minute — a brute-force run can send hundreds of requests a minute, and writing each one would hammer the site’s database. So read that number as a count of attempts, not of requests.

How to avoid locking yourself out

A wrong allow list shuts the owner out of their own site. Four things stand in the way:

  1. An empty allow list cannot be saved. Both the dashboard and the plugin refuse it, because it would turn everyone away, including you.
  2. You are asked to confirm if the address you are connecting from is not written in the list letter for letter. The question is asked even when a range you added might cover it — the dashboard does not try to work that out on your behalf.
  3. If the address cannot be read at all, the request is let through. That happens when the web server reports no usable address — a command run on the server, or an unusual server configuration. “I do not know” never becomes “blocked”.
  4. There is a recovery switch that does not need the dashboard. See below.

Two more things worth knowing before you save an allow list:

  • Your home connection may not have a fixed address. Most consumer lines and every mobile network hand out an address that changes. Use a range or a CIDR block if you know what your provider uses, or use the block list instead of the allow list.
  • One-click admin login goes through the same door. The login button in your dashboard opens the site in your browser, so the address that matters is yours, not ours. Sign-in itself succeeds, and then the admin page it lands on is refused if the admin area is protected and your address is not on the list.

How to get back in if you are locked out

You do not need to reach wp-admin to undo this. Open wp-config.php over FTP, SFTP, SSH or your hosting file manager and add this line near the top, above the line that says “That’s all, stop editing”:

define('WPSAFER_FIREWALL_OFF', true);

The filter stops being applied immediately. Nothing is deleted — the rule and the list stay exactly as they were, so you can sign in, fix the list from your dashboard, and remove the line afterwards.

If you would rather clear the rule instead of keeping it, open the Security tab and press Remove the firewall.

How to reuse address sets across sites: IP pools

If you look after several sites, typing the same office and VPN addresses into every one of them is how mistakes happen. Open IP Pools in the dashboard menu and save each set once, with a name and an optional note.

A pool can then be dropped into a site’s list from the Security tab, or pushed to many sites at once with Apply to sites on the pool itself. When you apply a pool you choose the rule (allow list or block list), whether the addresses are added to what each site already has or replace each site’s list, which areas to protect, and which sites are included.

Two things behave the way they do on purpose:

  • The addresses are copied. There is no live link between a pool and the sites you applied it to. Editing a pool afterwards changes nothing on those sites — which is the point: one careless edit should not be able to lock a whole fleet out at once.
  • The settings are saved at once, and sent on the next queue run. Sending ten requests to ten sites while you wait would tie your browser to the slowest site of the ten. The queue also retries a site that did not answer.

Applying an allow list to several sites always asks for confirmation first, and names the address you are connecting from.

When the site holds something different

The site is the source of truth, not the dashboard. Every time you open the Security tab it reads the setting that is actually in force on the site, and if it differs from the record here you get a warning with both values side by side. Read from the site asks again at any time.

A difference is not a fault in itself. The site may have been restored from a backup taken before the rule existed, someone may have edited things on the site directly, or the recovery switch above may be in place. Saving again sends what is on your screen to the site.

Deactivating or deleting the WP Safer plugin also stops the filtering: no plugin, nothing to apply. The rule stays in your dashboard and in the site’s own settings, so it starts being applied again the moment the plugin is active again.

Turning it off, and removing it

Off keeps the list on both sides and simply stops applying it. Remove the firewall deletes the rule here and on the site, and the admin area is open to every address again.

The blocked counter and the recent-blocks list survive a removal on purpose: they are the history of the site, not part of the rule, so they are still there if you switch the firewall back on later.

On a multisite network

The setting is stored for the whole network, not for one site inside it. Even if you set it from the row of a single subsite, it governs the admin area of every site in that network, and the blocked counter and the recent-blocks list are shared in the same way. Bear that in mind when the subsites belong to different people.