WordPress IP blacklist and whitelist guide

A WordPress IP blacklist and whitelist can restrict or exempt authentication traffic according to the network address WordPress or the surrounding server infrastructure sees for each request.

The basic idea is simple:

Blacklist
→ deny selected IP addresses

Whitelist
→ trust or exempt selected IP addresses

The implementation is less simple because an IP address is not necessarily a permanent identity and the address visible to WordPress may belong to:

• the real visitor;
• a reverse proxy;
• a CDN;
• a load balancer;
• a VPN exit;
• a corporate gateway;
• a mobile carrier.

A useful IP access-control system therefore needs more than a text box containing addresses.

You need to decide:

• what the blacklist actually blocks;
• what the whitelist actually bypasses;
• which authentication paths are covered;
• where the client IP comes from;
• how IPv4 and IPv6 addresses are validated;
• how conflicting rules are resolved;
• how administrators recover from accidental self-blocking;
• whether the control belongs in WordPress, the web server or a network edge layer.

This guide explains WordPress IP blacklists and whitelists, how application-level IP controls work, how to validate addresses safely, why reverse proxies complicate the problem, when server-level blocking is more appropriate and how IP rules fit into a broader WordPress login-security strategy.

What is a WordPress IP blacklist?

An IP blacklist, also commonly called a denylist, contains addresses that should not be allowed through a particular access-control layer.

For example:

198.51.100.27
→ blocked

203.0.113.42
→ blocked

The exact meaning of “blocked” depends on the implementation.

An IP rule might block:

• the complete website;
• only wp-login.php;
• only authentication attempts;
• only XML-RPC authentication;
• a particular REST authentication path;
• the WordPress administration area;
• a custom endpoint.

Never assume that a feature named “IP blacklist” automatically protects every request reaching the server.

What is a WordPress IP whitelist?

An IP whitelist, also called an allowlist or trusted-IP list, identifies addresses that receive special treatment.

Depending on the implementation, a trusted IP may:

• bypass login-attempt counters;
• bypass temporary lockouts;
• be allowed to reach a restricted login page;
• be allowed through a server access rule;
• receive another explicitly defined exemption.

Again, the important part is the exact rule.

This:

IP is whitelisted

does not automatically mean:

IP bypasses every security control

unless the implementation explicitly says so.

Blacklist and whitelist are policy concepts

A useful way to think about them is:

Blacklist
→ known address receives
a restrictive rule

Whitelist
→ known address receives
a trusted or exempt rule

The application still needs to define:

restrict from what?

exempt from what?

IP rules are different from login-attempt limiting

A blacklist can immediately deny a known source.

A login-attempt limiter usually responds dynamically after repeated failures.

For example:

Blacklist

198.51.100.27
→ immediately denied


Rate limiter

203.0.113.20
→ failure 1
→ failure 2
→ failure 3
→ temporary lockout

For the second mechanism, see How to Limit Login Attempts in WordPress.

Monitoring is another separate layer

An IP rule changes what happens to a request.

Monitoring records what happened.

Blacklist
→ enforcement

Whitelist
→ exemption

Rate limiting
→ abuse control

Login log
→ visibility

See How to Monitor WordPress Login Attempts for the logging side.

WordPress does not provide one universal IP blacklist API

WordPress Core provides authentication hooks and filters, but it does not contain a single built-in administration screen where site owners maintain a global IP blacklist and whitelist for all requests.

An application-level implementation therefore normally combines:

• WordPress hooks;
• validated IP configuration;
• custom plugin logic;
• optional rate limiting;
• optional logging.

Alternatively, IP controls can be implemented outside WordPress at the:

• Apache level;
• Nginx level;
• hosting firewall;
• WAF;
• CDN;
• load balancer;
• reverse proxy.

WordPress-level vs server-level IP blocking

This distinction matters because the request reaches different parts of the stack.

Internet
↓
CDN / WAF
↓
web server
↓
PHP
↓
WordPress
↓
authentication

A rule at the CDN can stop traffic before it reaches the origin server.

A WordPress plugin rule runs much later.

WordPress-level blocking

Advantages include:

• easy administration from wp-admin;
• integration with login attempts;
• integration with user-facing messages;
• integration with WordPress hooks;
• portable configuration across many hosting environments.

Limitations include:

• PHP and WordPress normally need to load before the rule can execute;
• the implementation must correctly identify the client address;
• it is not a general network firewall;
• other non-WordPress resources may remain accessible.

Server-level blocking

Server rules can reject requests before WordPress executes.

This can be useful when an address should be denied from an entire resource rather than merely from WordPress authentication.

For Apache 2.4, the official mod_authz_host documentation provides the:

Require ip

authorization provider.

Apache example: allow one IP

Require ip 203.0.113.20

Apache also supports IPv4 and IPv6 network ranges.

For example:

Require ip 192.0.2.0/24

Require ip 2001:db8:1::/48

The official Apache Access Control guide documents these formats.

Apache example: deny one address

Modern Apache configurations should use Require rather than copying old tutorials based on deprecated:

Order
Allow
Deny

A deny rule can be expressed using authorization containers:

<RequireAll>
    Require all granted
    Require not ip 198.51.100.27
</RequireAll>

The Apache documentation specifically recommends the modern authorization system instead of obsolete access-control directives.

Nginx provides allow and deny directives

Nginx includes the:

ngx_http_access_module

for access control by client address.

The official Nginx access module documentation supports rules such as:

deny 192.0.2.20;

allow 198.51.100.0/24;

allow 2001:db8::/32;

deny all;

Nginx processes these access rules in order until the first matching rule is found.

Order matters

Whenever a system supports both allow and deny rules, define the precedence deliberately.

Consider:

Blacklist:
203.0.113.20

Whitelist:
203.0.113.20

What should happen?

Possible policies include:

Blacklist always wins

or:

Whitelist always wins

or:

configuration conflict rejected

The software should define the behavior rather than leave administrators guessing.

TheOneWP Access Manager gives blacklist priority on the login page

TheOneWP Access Manager implements distinct IPv4 and IPv6 blacklist and whitelist controls.

In the current implementation, the blacklist check occurs first when the normal WordPress login page is accessed.

A blacklisted IP is therefore stopped before whitelist exemptions or login-attempt logic become relevant on that path.

What does the TheOneWP whitelist do?

Trusted addresses added to the Access Manager whitelist are exempt from:

• failed-login attempt counting;
• temporary lockout checks.

This is useful for explicitly trusted administrative networks where accidental password errors should not trigger ordinary rate-limit enforcement.

The whitelist does not mean that the address receives:

automatic WordPress authentication

or:

administrator permissions

The user still needs valid credentials and the normal WordPress authorization model still applies.

Whitelist does not mean bypass authentication

This distinction is critical.

Trusted IP
≠
authenticated user

and:

Trusted IP
≠
WordPress Administrator

IP rules operate on network context.

WordPress authentication operates on account credentials.

WordPress roles and capabilities then determine what an authenticated account may do.

For that final layer, see WordPress User Roles and Capabilities, Explained.

Validate IP addresses before storing them

Do not accept arbitrary strings as trusted or blocked addresses.

PHP provides:

FILTER_VALIDATE_IP

for IP-address validation.

The official PHP filter documentation supports both:

FILTER_FLAG_IPV4

FILTER_FLAG_IPV6

Simple IPv4 and IPv6 validation

function project_validate_ip(
    $value
) {

    $value = trim(
        (string) $value
    );

    if (
        false === filter_var(
            $value,
            FILTER_VALIDATE_IP
        )
    ) {
        return false;
    }

    return $value;
}

The official filter_var() documentation describes PHP’s validation interface.

Validate, do not merely sanitize

An IP configuration should answer:

Is this a valid IP address?

rather than attempting to transform arbitrary text into something that resembles one.

For example:

999.999.999.999

should be rejected.

It should not be modified into another value and silently accepted.

Support IPv6

An implementation that assumes every client address looks like:

192.0.2.10

is incomplete.

IPv6 addresses can look like:

2001:db8:1234::42

Use validation and storage structures that support both protocols.

Do not store IP addresses in an undersized database column

If IP rules are stored in a custom table, do not design the field around only the maximum length of an IPv4 string.

A general textual implementation might use enough space for a normalized IPv6 representation.

Alternatively, larger systems can use binary address storage and explicit conversion.

The appropriate structure depends on the application.

Exact IP rules vs CIDR ranges

There is an important difference between:

203.0.113.42

and:

203.0.113.0/24

The first refers to one address.

The second represents a network range.

Do not advertise CIDR support unless the implementation actually parses and compares networks correctly.

TheOneWP Access Manager currently uses validated individual addresses

The current Access Manager interface is built around validated IPv4 and IPv6 blacklist and whitelist entries.

Do not assume that an arbitrary CIDR value can be entered merely because Apache or Nginx supports CIDR at the server level.

These are different systems.

When CIDR is useful

Network-range rules make sense when access should be controlled for:

• an office network;
• a VPN subnet;
• a trusted hosting network;
• a known corporate range.

For large ranges, firewall, proxy or web-server controls are often more appropriate than maintaining hundreds of individual WordPress entries.

Where does the client IP come from?

In PHP, the immediate remote address is normally available through:

$_SERVER['REMOTE_ADDR']

A defensive helper can validate it before use:

function project_remote_ip() {

    if (
        empty(
            $_SERVER['REMOTE_ADDR']
        )
    ) {
        return '';
    }

    $ip = wp_unslash(
        $_SERVER['REMOTE_ADDR']
    );

    if (
        false === filter_var(
            $ip,
            FILTER_VALIDATE_IP
        )
    ) {
        return '';
    }

    return $ip;
}

REMOTE_ADDR may be the proxy address

This becomes important when the request path is:

Visitor
↓
Cloudflare
↓
origin server
↓
WordPress

The origin may see the Cloudflare edge address unless the server is configured to restore the original visitor IP.

The same problem can occur with:

• reverse proxies;
• load balancers;
• container ingress layers;
• managed hosting proxies.

Apache explicitly warns about proxy environments

The official Apache mod_authz_host documentation notes that when content is proxied, the client address may be the proxy server rather than the original client.

Apache provides:

mod_remoteip

for environments that need to restore the original client address from a trusted proxy architecture.

Cloudflare requires origin configuration too

Cloudflare’s official original visitor IP documentation explains how supported web servers can be configured to restore the visitor address.

For Nginx, this normally involves:

ngx_http_realip_module

and a trusted:

CF-Connecting-IP

source from Cloudflare’s own proxy ranges.

Do not blindly trust X-Forwarded-For

A request header is not automatically trustworthy simply because its name contains:

Forwarded

A client can potentially send its own:

X-Forwarded-For

unless your proxy and origin architecture overwrites or validates the header correctly.

This means code such as:

$ip = $_SERVER[
    'HTTP_X_FORWARDED_FOR'
];

should not be copied into a security control without understanding the infrastructure.

Fix the network layer instead of guessing in plugin code

The more robust architecture is:

trusted edge proxy
↓
trusted origin configuration
↓
REMOTE_ADDR contains
expected client address
↓
WordPress consumes REMOTE_ADDR

rather than:

WordPress accepts whatever
forwarding header arrived

TheOneWP deliberately uses REMOTE_ADDR

The current Access Manager implementation uses:

REMOTE_ADDR

and deliberately does not automatically trust:

X-Forwarded-For

for IP enforcement.

If your site is behind a proxy, CDN or load balancer, verify what the hosting stack exposes through REMOTE_ADDR before enabling restrictive IP policies.

Why this matters for a blacklist

Imagine Cloudflare sits in front of the server and WordPress sees:

172.64.150.10

for hundreds of visitors because that address belongs to the proxy layer.

If you blacklist it, you may block many legitimate requests at once.

Why this matters for a whitelist

The opposite error can be even more serious.

If the proxy address is incorrectly whitelisted and every request appears to WordPress as coming from that address, many visitors could receive the trusted-IP exemption.

Never configure a whitelist until you know which address your application is actually evaluating.

Verify the observed IP first

Before creating production rules, inspect:

REMOTE_ADDR

from the same production architecture where the security control will run.

Do not assume:

local development
=
production proxy behavior

Test IPv4 and IPv6 separately

A user may connect over:

IPv4 today
IPv6 tomorrow

depending on:

• ISP;
• mobile carrier;
• VPN;
• network;
• device;
• DNS and routing.

If a trusted administrator has both connectivity types, a whitelist containing only one address may not behave as expected on every network.

Dynamic IP addresses make whitelists fragile

Residential and mobile connections frequently use addresses that can change.

A whitelist works best with:

• static corporate IPs;
• controlled VPN exit addresses;
• fixed administrative networks;
• stable infrastructure addresses.

It is less suitable as a permanent identity mechanism for a constantly changing mobile connection.

An IP address is not a user account

Do not confuse:

source IP
with
human identity

One IP can represent many people.

One person can use many IPs.

This happens because of:

• NAT;
• corporate gateways;
• carrier-grade NAT;
• VPNs;
• mobile networks;
• shared Wi-Fi;
• proxies.

IP controls should complement authentication

A whitelist should not replace:

• strong passwords;
• two-factor authentication;
• least privilege;
• account lifecycle management.

The broader architecture is covered in WordPress Login Security Layers, Explained.

Two-factor authentication remains important

A trusted office IP can still contain a compromised device.

An attacker can also obtain access through:

• a VPN account;
• a compromised workstation;
• malware;
• an internal network breach.

TheOneWP Two-Factor Authentication protects a different layer by requiring an additional authentication factor.

A whitelist should not disable 2FA by default

These policies answer different questions:

IP whitelist
→ Is this network source trusted
for a particular exemption?

2FA
→ Can this person provide
the required second factor?

Do not weaken account authentication merely because the network address appears familiar.

Changing the login URL is separate too

A custom login URL may reduce automated traffic targeting:

/wp-login.php

but it does not replace IP controls.

See How to Change the WordPress Login URL.

Do not treat obscurity as access control

A hidden login endpoint and an IP blacklist solve different problems.

For the limits of changing the endpoint, see Does Hiding wp-login.php Actually Help Security?.

Implementing an application-level blacklist

WordPress provides the:

authenticate

filter during authentication.

The official authenticate documentation allows callbacks to return a WP_Error and stop authentication.

Basic demonstration

add_filter(
    'authenticate',
    'project_ip_access_check',
    5,
    3
);

function project_ip_access_check(
    $user,
    $username,
    $password
) {

    $ip = project_remote_ip();

    if ( ! $ip ) {
        return $user;
    }

    $blocked_ips = array(
        '198.51.100.27',
        '203.0.113.42',
    );

    if (
        in_array(
            $ip,
            $blocked_ips,
            true
        )
    ) {
        return new WP_Error(
            'ip_access_denied',
            __(
                'Authentication is not available from this network address.',
                'project'
            )
        );
    }

    return $user;
}

This demonstrates the authentication layer.

It is not a complete production blacklist system.

Why use an early authenticate priority?

The authenticate filter receives:

$user
$username
$password

and WordPress’s own username/password authentication handlers run through the same filter chain.

An access-control callback can therefore run before ordinary credential verification when registered with an appropriate early priority.

The official wp_authenticate() implementation documents this authentication process.

Never log the password from authenticate

The filter receives the plaintext submitted password.

Your IP rule does not need it.

Do not store, transmit or log it.

Blocking before the login form is different

If the requirement is:

blacklisted address
must not even see
the normal login form

the implementation must also run on the login-page lifecycle rather than only during credential authentication.

Those two controls are conceptually:

login-page access
and
authentication access

Cover every authentication path you actually need

A site can contain authentication paths other than a person typing credentials into the visible login page.

Depending on the installation, authentication can involve:

• normal wp-login.php;
• XML-RPC;
• REST authentication;
• application passwords;
• custom API authentication;
• SSO;
• third-party plugins.

An IP rule attached only to the visual login form does not automatically govern every one of those paths.

The authenticate filter operates deeper in the authentication stack

Blocking at the authentication filter level can cover WordPress authentication calls that use the standard authentication pipeline.

That is why an implementation may combine:

login-page check
+
authentication check

rather than relying on presentation alone.

Custom authentication systems need separate testing

Single sign-on and external identity-provider plugins may change the normal WordPress flow.

Test the exact authentication stack installed on the site.

Do not claim that one hook protects an external SSO provider unless you have verified that integration.

TheOneWP Access Manager checks more than the visible login form

The current Access Manager architecture checks blacklist and lockout conditions around the normal login flow and also applies lockout enforcement during WordPress authentication.

This allows locked-out IPs to be rejected when authentication uses WordPress’s standard authentication pipeline rather than only when the visible login page is rendered.

Blacklist and rate limiter should remain conceptually separate

A permanent administrator-defined blacklist entry is different from a temporary rate-limit lockout.

For example:

Blacklist
→ manual security policy

Temporary lockout
→ automatic response
to repeated failures

Keep separate data structures and management actions where possible.

Do not automatically turn every lockout into a permanent blacklist

A temporary threshold can be triggered by:

• a real user entering an old password;
• a stale password manager;
• a shared office address;
• an integration using expired credentials.

Escalating every temporary lockout into a permanent IP block creates unnecessary risk.

Progressive lockouts are another option

Instead of permanent blocking, repeated lockout cycles can increase the temporary lockout duration.

Conceptually:

first lockout
→ 5 minutes

second lockout
→ longer

third lockout
→ longer again

The current Access Manager supports optional progressive lockout behavior alongside static blacklist and whitelist rules.

Whitelisting should be conservative

A blacklist failure affects a blocked source.

A badly designed whitelist can affect the entire security policy.

Add only addresses that have a clear reason to be trusted.

Good whitelist candidates

Possible examples include:

• a fixed office IP;
• a controlled agency VPN exit;
• a monitoring service requiring a specific exemption;
• a known administrative network.

Document why each entry exists.

Use labels for IP entries

A rule such as:

203.0.113.20

will mean very little six months later.

A better administrative record is:

203.0.113.20
Agency office VPN
Added 2026-09-22

Labels make audits and cleanup easier.

Review whitelist entries periodically

Trusted IPs can become obsolete when:

• an office changes ISP;
• a contractor leaves;
• a VPN provider changes;
• hosting architecture changes;
• a temporary project ends.

Remove entries that no longer have a documented purpose.

Review blacklist entries too

A permanent blacklist can grow indefinitely if every suspicious address is added forever.

Addresses can be reassigned.

Attack infrastructure changes constantly.

A giant historical denylist may provide little value while increasing administrative complexity.

IP blacklisting is less effective against distributed attacks

An attacker can spread attempts across:

IP A
IP B
IP C
IP D
IP E
...

through:

• botnets;
• proxy networks;
• cloud infrastructure;
• compromised devices.

Blocking one source does not stop the overall campaign.

Use account-level and authentication-level protections too

OWASP’s Authentication Cheat Sheet recommends controls such as login throttling and multi-factor authentication against password-guessing attacks.

The useful model is:

IP controls
+
rate limiting
+
strong passwords
+
2FA
+
monitoring

Monitor whether the blacklist is actually useful

A blacklist without monitoring can accumulate entries with no evidence that they still matter.

Use authentication events to determine:

• which sources repeatedly fail;
• which accounts are targeted;
• whether attacks are distributed;
• whether trusted IPs trigger unusual activity;
• whether lockouts are affecting legitimate users.

See How to Monitor WordPress Login Attempts.

Do not store login-log IPs unnecessarily in plaintext

An enforcement list needs the actual address because the software must compare future requests against it.

A historical login log may have different requirements.

If the goal is only:

Was this the same source?

a deterministic keyed hash may be enough.

TheOneWP separates enforcement data from log data

The current Access Manager implementation stores actual validated IP addresses for blacklist and whitelist entries because those addresses are required for enforcement.

Authentication-event IP values, however, are stored as salted SHA-256 hashes.

This allows source correlation without keeping the original address directly readable in the login-event table.

Hashed does not automatically mean anonymous

A deterministic identifier still exists specifically so events from the same source can be associated.

Treat authentication logs as potentially sensitive operational data even when IP values have been transformed.

Limit log retention

The current Access Manager authentication log is capped at:

500 events

and removes the oldest excess rows after new events are inserted.

The purpose is to prevent the event table from growing without limit.

IP blacklist entries need real addresses

Do not hash the blacklist itself if the application must perform:

incoming IP
===
blocked IP

unless your implementation deliberately hashes both values using the same secure deterministic process before comparison.

For an ordinary configurable IP list, storing the validated address is simpler and easier to manage.

Prevent administrators from locking themselves out accidentally

This is one of the most important operational concerns.

Before adding your current address to a blacklist, make sure you have:

• another administrator session;
• server or hosting access;
• database access;
• a plugin-disabling recovery method;
• another trusted network;
• a documented rollback process.

Do not test destructive rules from your only access path

This sequence is unwise:

one administrator
+
one network
+
no hosting access
+
blacklist own IP

Maintain a recovery path before testing.

Whitelist yourself before aggressive rate-limit testing

If the implementation defines whitelist entries as exempt from lockout counters, a trusted testing address can prevent accidental temporary lockouts while you validate other authentication behavior.

Only do this after confirming the IP visible to WordPress is actually yours.

Do not whitelist a dynamic address permanently without reviewing it

If your ISP later assigns that IP to someone else, the exemption can apply to a different subscriber.

Stable infrastructure is a much better whitelist target.

Block User Login solves a different problem

Sometimes the risk is not a network address.

The problem is a specific WordPress account.

For example:

former contractor
still has account
↓
access should stop

Blocking the contractor’s current IP is fragile because the person can connect from somewhere else.

TheOneWP Block User Login addresses the account directly instead.

Choose the control that matches the object you want to restrict

Bad network source
→ IP rule

Abusive repeated attempts
→ rate limit

User should not authenticate
→ account block

Account needs stronger proof
→ 2FA

User has excessive permissions
→ role/capability change

Restrict Login Identifier is different again

TheOneWP Restrict Login Identifier controls whether WordPress accepts particular login identifier types.

That concerns:

username
or
email

not the client’s network address.

For the security implications of identifiers, see WordPress Login: Username vs. Email, Which Is More Secure?.

IP blocking does not fix dormant accounts

If an old administrator account remains active, blocking yesterday’s suspicious IP does not eliminate the account risk.

Review old identities directly.

See Auditing Dormant WordPress User Accounts.

Last Login can provide useful context

TheOneWP Last Login records successful authentication context for users.

This can help distinguish:

active administrator
from
account unused for two years

when reviewing security policies.

Audit roles after suspicious account activity

A compromised account with:

Subscriber

permissions has a different potential impact from one with:

Administrator

capabilities.

Review access through How to Audit User Roles on a WordPress Site.

Server-level allowlisting can protect wp-admin

In highly controlled environments, administrators may choose to restrict the complete administration area at the web-server or network level.

For example:

/wp-admin/
→ office VPN only

This can be effective when every legitimate administrator connects through a known stable network.

It can be impractical when editors work from:

• home;
• mobile connections;
• travel networks;
• changing ISP addresses.

Remember admin-ajax.php dependencies

Be careful when restricting the entire:

/wp-admin/

directory at the server level.

Some frontend functionality and plugins can depend on:

/wp-admin/admin-ajax.php

even for visitors who are not using the WordPress backend.

Test the real site rather than applying a blanket rule copied from a generic hardening checklist.

REST API and wp-admin are not the same thing

Blocking:

/wp-admin/

does not automatically block:

/wp-json/

and vice versa.

Understand which entry point your policy is intended to protect.

XML-RPC is another separate endpoint

Some WordPress installations still expose:

/xmlrpc.php

depending on configuration and integrations.

If IP enforcement is intended to cover authentication globally, test whether your implementation also reaches authentication occurring through that path.

Application Passwords change the authentication landscape

WordPress supports Application Passwords for programmatic authentication.

An interactive login-page restriction is not automatically equivalent to an API authentication restriction.

Define which authentication paths are in scope.

Do not make claims broader than the control

If your implementation protects:

wp-login.php

say that.

Do not describe it as:

blocking the IP from WordPress entirely

unless every relevant request path is actually covered.

Firewall blocking is stronger in scope, not automatically better in every case

A WAF or server firewall can reject traffic earlier.

WordPress-level rules can provide richer application context and easier site-specific administration.

The correct layer depends on the objective.

Use edge controls for large-scale abusive traffic

If a website is receiving extremely high request volumes from abusive networks, allowing all traffic to reach PHP merely so a plugin can reject it is inefficient.

Use:

• CDN firewall rules;
• hosting security controls;
• WAF policies;
• server access controls;

where appropriate.

Use WordPress controls for application-aware policies

A plugin-level rule becomes useful when you need:

• an admin-manageable list;
• login-attempt integration;
• temporary lockouts;
• login-event reporting;
• WordPress-specific user feedback.

Do not create thousands of manual blacklist entries

A constantly growing list of individual attacker addresses becomes difficult to maintain and may have little value against rotating botnet infrastructure.

Use rate limiting and network-level abuse controls for large-scale patterns.

Do not blacklist an entire network casually

A CIDR block can represent:

• many customers;
• a hosting provider;
• a university;
• a company;
• a mobile carrier;
• a VPN provider.

Understand the scope before denying a range.

Do not blacklist private addresses without understanding the architecture

Addresses such as:

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

belong to private address space.

If one unexpectedly appears as the apparent client address on a public WordPress installation, investigate the proxy or internal network architecture before creating access policies around it.

Loopback addresses need similar care

Addresses such as:

127.0.0.1
::1

represent the local host.

Seeing them as the apparent remote client in production can indicate that a local proxy layer is involved.

PHP can distinguish address classes

FILTER_VALIDATE_IP supports flags including:

FILTER_FLAG_NO_PRIV_RANGE

FILTER_FLAG_NO_RES_RANGE

FILTER_FLAG_GLOBAL_RANGE

depending on the validation requirement and PHP version.

Do not automatically reject private or reserved addresses in every plugin, however.

Internal WordPress installations can legitimately use private networks.

Validation rules should follow the product’s scope

A public-login protection tool may expect internet-routable addresses.

An internal corporate WordPress installation may intentionally use:

10.0.0.0/8

addresses.

Security validation should reflect the intended deployment rather than applying arbitrary internet-only assumptions.

Keep a recovery mechanism

Any access-control system capable of blocking administrators needs a documented recovery method.

Possible methods include:

• hosting panel access;
• SSH;
• SFTP;
• database administration;
• WP-CLI;
• disabling the responsible plugin;
• editing the relevant server rule.

Document where the IP rules live

An agency can easily end up with:

Cloudflare rule
+
hosting firewall rule
+
Nginx rule
+
WordPress plugin blacklist

When someone is blocked, determining which layer caused it becomes unnecessarily difficult.

Document the owner of each access rule.

Use one clear policy per layer

A maintainable architecture might be:

Cloudflare / WAF
→ large-scale network abuse

web server
→ infrastructure restrictions

WordPress Access Manager
→ login-specific IP policies
and rate limiting

WordPress accounts
→ user access

roles and capabilities
→ permissions

Do not duplicate the same blacklist everywhere without a reason

If an address is blocked at the CDN, adding the same address to:

• Nginx;
• Apache;
• WordPress;

may add operational complexity without improving the actual result.

Testing a WordPress blacklist

Use a controlled address and a recovery path.

Verify:

1. address validates

2. entry saves

3. expected request is blocked

4. unrelated visitors still work

5. rule can be removed

6. access returns after removal

Testing a whitelist

For a whitelist exemption, confirm the exact promised behavior.

For example, if the whitelist is designed to bypass rate limiting:

1. add controlled trusted IP

2. perform controlled failed logins

3. confirm counter does not
trigger normal lockout

4. verify credentials are
still required

5. remove whitelist entry

6. confirm standard policy returns

Do not test with real user passwords

Use a dedicated test account.

Security testing does not require exposing or repeatedly mistyping a production administrator password.

Test the blacklist before adding many entries

One correctly tested rule provides more confidence than importing a large blocklist and hoping the interpretation is correct.

Test from a second network

A mobile hotspot or controlled VPN can help verify that:

blocked source
→ denied

different source
→ still works

provided the test environment itself is understood.

Test proxy behavior in production-like infrastructure

A local WordPress environment that directly sees your workstation IP does not reproduce:

browser
↓
Cloudflare
↓
load balancer
↓
container
↓
WordPress

Verify the real deployment chain.

Test both successful and failed authentication

A whitelist should not accidentally:

bypass password validation

and a blacklist should block according to its intended scope regardless of whether the submitted password would otherwise be correct.

Test API authentication where it matters

If the policy is supposed to cover:

• REST authentication;
• XML-RPC;
• Application Passwords;

test those paths explicitly.

Do not infer coverage from the normal login form.

Monitor after deployment

After enabling IP controls, review:

• failed logins;
• blocked events;
• lockouts;
• unexpected administrator complaints;
• proxy-address anomalies;
• repeated attempts against privileged accounts.

For a structured monitoring model, use How to Monitor WordPress Login Attempts.

Audit account security alongside IP rules

Network controls should not distract from the accounts themselves.

Review:

• old users;
• administrator count;
• unused accounts;
• role assignments;
• 2FA coverage.

See A WordPress Login Hardening Checklist for the wider process.

Common mistake: trusting X-Forwarded-For without a trusted proxy configuration

A forwarding header should become security input only when the surrounding infrastructure guarantees its meaning.

Fix the proxy chain rather than selecting the first IP-looking string in a request header.

Common mistake: confusing a whitelist with passwordless access

A trusted network source should not automatically authenticate a WordPress user.

Network trust and account authentication are separate layers.

Common mistake: whitelisting the proxy IP

If all users appear to originate from the same edge proxy, whitelisting that address can accidentally exempt everyone reaching WordPress through the proxy.

Common mistake: blocking the proxy IP

The reverse mistake can block legitimate traffic at large scale.

Common mistake: assuming IPs never change

Residential, mobile and many business connections can receive new addresses.

Periodically validate trusted entries.

Common mistake: assuming one IP equals one attacker

An address can represent many unrelated people behind NAT or shared infrastructure.

Common mistake: assuming one attacker equals one IP

Attackers can rotate through many addresses.

Use more than static blacklisting against distributed authentication attacks.

Common mistake: supporting IPv4 only

Modern access-control systems should validate and handle IPv6 where the surrounding stack supports it.

Common mistake: storing arbitrary strings as IP addresses

Validate input before saving it.

Do not rely on visual inspection alone.

Common mistake: claiming CIDR support without implementing it

An exact string comparison cannot correctly evaluate:

203.0.113.0/24

against:

203.0.113.42

Network-range support requires actual CIDR matching logic.

Common mistake: using an IP blacklist as the only brute-force defense

Distributed attackers can change addresses faster than an administrator can manually add entries.

Use rate limiting and 2FA.

Common mistake: keeping every blacklist entry forever

Review whether historical rules still provide value.

Common mistake: keeping obsolete whitelist entries

Trusted rules deserve even more frequent review because they relax normal controls.

Common mistake: no recovery plan

Never deploy restrictive access rules without knowing how to disable them outside the blocked path.

Common mistake: blocking all of wp-admin without testing admin-ajax.php

Some frontend functionality can depend on the WordPress AJAX endpoint.

Test the live application before enforcing a broad server rule.

Common mistake: treating IP controls as authorization

An allowed IP does not grant:

edit_posts
manage_options
install_plugins

WordPress capabilities remain responsible for authorization.

Common mistake: treating IP controls as authentication

Likewise:

IP allowed
≠
user authenticated

Credentials and other authentication factors still matter.

Common mistake: ignoring logs after adding a blacklist

Measure whether the rules actually affect the traffic pattern you were trying to control.

Common mistake: applying WordPress rules to a volumetric attack

If massive abusive traffic is consuming origin resources, move enforcement farther toward the network edge.

TheOneWP Access Manager workflow

The current Access Manager combines several related but separate controls:

IP Blacklist
→ explicitly denied addresses

IP Whitelist
→ trusted addresses exempt
from rate-limit lockouts

Rate Limiter
→ failed-attempt thresholds

Progressive Lockout
→ longer temporary lockouts
after repeated cycles

Login Log
→ authentication-event visibility

This produces a layered flow rather than treating every suspicious request as a permanent blacklist candidate.

Blacklist entries

The module accepts validated IPv4 and IPv6 addresses and stores the actual address because future requests must be compared against the rule.

Whitelist entries

Trusted IPv4 and IPv6 addresses can bypass failed-attempt counting and lockout checks.

Authentication credentials are still required.

Login events

Login-event IP values are stored differently from enforcement entries: they are transformed into salted hashes for correlation rather than kept as directly readable addresses.

Access to the module is restricted

The current Access Manager administration page and protected management operations require:

manage_options

and its AJAX actions also require the module’s nonce checks.

This is important because blacklist and whitelist configuration itself is a sensitive administrative capability.

Use each TheOneWP module for one responsibility

Access Manager handles network-source rules, attempts, lockouts and authentication-event visibility.

Two-Factor Authentication adds another identity factor.

Block User Login suspends authentication for selected user accounts.

Restrict Login Identifier controls accepted username/email login methods.

Last Login provides successful-access context for user audits.

WordPress IP blacklist and whitelist checklist

• Define exactly what the blacklist should block.
• Define exactly what the whitelist should exempt.
• Document rule precedence.
• Validate every IPv4 and IPv6 address before saving it.
• Do not claim CIDR support unless network ranges are actually implemented.
• Confirm the address WordPress receives through REMOTE_ADDR.
• Verify proxy, CDN and load-balancer behavior before enabling IP enforcement.
• Do not blindly trust X-Forwarded-For.
• Configure trusted proxy infrastructure correctly.
• Use labels for permanent IP entries.
• Review blacklist entries periodically.
• Review whitelist entries even more carefully.
• Avoid permanent trust for unstable dynamic IPs.
• Keep a recovery path before testing restrictive rules.
• Do not test self-blocking from your only administrative connection.
• Test IPv4 and IPv6 separately where applicable.
• Test the normal WordPress login form.
• Test authentication APIs separately when they are in scope.
• Do not assume blocking the login page protects every authentication method.
• Do not assume an allowed IP is an authenticated user.
• Do not assume an IP identifies one person.
• Do not assume one attacker uses one IP.
• Combine IP controls with login rate limiting.
• Use two-factor authentication for sensitive accounts.
• Review dormant accounts.
• Audit user roles and capabilities.
• Monitor successful and failed authentication events.
• Avoid unlimited log retention.
• Do not expose authentication-event data publicly.
• Move large-scale blocking to the CDN, WAF or server layer where appropriate.
• Document which system owns each IP rule.
• Test server-level restrictions against admin-ajax.php and other required WordPress endpoints.
• Retest access rules after infrastructure migrations.
• Retest after adding or changing a reverse proxy or CDN.

Related guides

• How to Limit Login Attempts in WordPress
• How to Monitor WordPress Login Attempts
• WordPress Login Security Layers, Explained
• A WordPress Login Hardening Checklist
• Does Hiding wp-login.php Actually Help Security?
• Auditing Dormant WordPress User Accounts

Final recommendation

A WordPress IP blacklist and whitelist can be useful, but only when the rules are based on a reliable understanding of the network path.

Start with the question:

Which IP address does
WordPress actually see?

Do not create security policy around REMOTE_ADDR, X-Forwarded-For or another header until you understand how your CDN, reverse proxy, load balancer and origin server handle the client address.

Once the source is reliable, define the policies explicitly:

Blacklist
→ addresses that should be denied

Whitelist
→ addresses that receive
a defined exemption

Rate limiter
→ temporary response
to repeated failures

Login log
→ authentication visibility

Keep those responsibilities separate.

Do not treat a whitelist as passwordless access. Do not treat a blacklist as complete brute-force protection. Do not treat an IP address as a permanent user identity.

Use WordPress-level rules where application awareness and easy administration matter. Use Apache, Nginx, hosting firewall or WAF controls when requests should be rejected earlier in the stack or when abuse volume makes application-level processing inefficient.

Most importantly, combine network-source controls with actual authentication security:

validated IP rules
+
login rate limiting
+
strong passwords
+
two-factor authentication
+
login monitoring
+
user-account review
+
least privilege

TheOneWP Access Manager brings the login-specific pieces together by providing validated IPv4 and IPv6 blacklist and whitelist entries, configurable failed-attempt limits, timed or progressive lockouts and a capped authentication-event log.

Use the blacklist for addresses that have a clear reason to be denied. Use the whitelist only for known, stable and documented trusted sources. Verify REMOTE_ADDR before relying on either, especially when the site sits behind a CDN or reverse proxy.

IP rules work best as one carefully defined layer in a wider login-security architecture, not as the identity system on which every other control depends.