75 guides published Start a blog Fix my site How we test
SECURITY

Lock Down wp-admin Without Locking Yourself Out

The admin area is the highest-value target on a WordPress site and the easiest to over-restrict. Every measure here is reversible from the filesystem, which is the property that matters when something goes wrong at eleven at night.

The short version

  • Confirm SFTP access before you start. It is your way back in.
  • Apply one measure at a time and verify login after each.
  • Server-level rules beat plugin-level rules, and survive a broken install.
  • Never restrict by IP on a connection with a dynamic address.

Before anything: your way back

Every lockout below is fixable by renaming a file or editing one over SFTP. Confirm you can reach the filesystem and that you know where the relevant files live. If you cannot, stop here.

1. Two-factor, done carefully

1. Install a plugin supporting app-based codes

Avoid SMS where you can. Codes from an authenticator app are both more secure and more reliable.

2. Enable it on your own account only

Do not enforce it site-wide yet.

3. Save the backup codes somewhere outside the site

A password manager, not a note in the dashboard.

4. Log out fully and log back in

In a private window, so you are testing the real flow and not a cached session.

5. Only then enforce it for administrators

And tell every administrator before you do, not after.

2. Rate-limit failed logins

The aim is to make credential stuffing expensive rather than to block it. Limit failed attempts per IP with a lockout measured in minutes, not hours, and make sure there is an allowlist you control.

Watch out

Long lockouts are a denial-of-service against yourself. An attacker can deliberately fail logins against your username to keep you locked out. Short windows plus two-factor is the better combination.

3. Restrict by IP, only if your address is static

If you always work from a fixed address, restricting /wp-admin and wp-login.php at the server level is the strongest single measure available. If your address changes, this will lock you out at the worst moment.

# Nginx
location ~ ^/(wp-admin|wp-login\.php) {
    allow 203.0.113.10;
    deny all;
}

# Apache, in .htaccess at the web root
<Files wp-login.php>
  Require ip 203.0.113.10
</Files>

Note that admin-ajax.php lives inside wp-admin and is used by front-end functionality on many sites. Exclude it from the rule or you will break things for logged-out visitors.

4. HTTP authentication as a second layer

A server-level password prompt in front of the login page stops automated tools before WordPress loads at all, which also saves resources during an attack. It is slightly inconvenient and extremely effective.

5. Audit users regularly

  • Remove accounts for people who have left.
  • Downgrade anyone who does not need administrator. Editor is sufficient for most content work.
  • Watch for administrator accounts you did not create — this is a primary indicator of compromise.
  • Regenerate salts after removing anyone, to invalidate their sessions immediately.

What not to bother with

Changing the login URL is the most commonly recommended measure and among the least useful. It reduces log noise, which has some value, but it is trivially discoverable and it breaks password managers for everyone on the site.

Common questions

What if I lock myself out?

Rename the plugin’s folder over SFTP to disable it, or remove the server rule. Both take under a minute if you confirmed filesystem access first.

Is two-factor worth the friction?

Yes. It is the single most effective measure against the most common attack, and app-based codes add about five seconds to a login.

Should I use a security plugin’s firewall?

A plugin firewall runs after WordPress has loaded, so it cannot stop resource exhaustion. Server-level or CDN-level filtering is meaningfully better.

S

Sumit

Writes everything on TechMozz.

More in Security