Protect WordPress Against Repeated Login Attempts
Every public WordPress login form can receive failed authentication attempts. Some are genuine users who mistyped their password, while others may come from automated systems repeatedly trying usernames and passwords in an attempt to gain access.
Limit Login Attempts introduces a controlled lockout system around WordPress authentication. Failed attempts are counted during a configurable observation window. Once the configured threshold is reached, further authentication from that scope is temporarily blocked.
By default, WP PowerSuite allows three failed attempts within a 60-minute observation window and then applies a 15-minute lockout. These values can be adjusted according to the needs of the website, with support for up to 20 attempts and configurable observation and lockout periods.
The module focuses specifically on authentication. A locked IP is not blocked from visiting the website, browsing content, or making unrelated requests. Only the relevant login and supported API authentication paths are restricted.
Make Persistent Login Attacks Increasingly Expensive
A basic lockout can slow automated login attempts, but an attacker can simply wait until a short lockout expires and begin again.
WP PowerSuite includes lockout escalation for repeated behavior.
The module tracks how many lockouts an IP has accumulated during a 24-hour period. Once the configured escalation threshold is exceeded, subsequent lockouts can use a longer duration than the normal penalty.
For example, your standard policy might lock authentication for 15 minutes after repeated failed attempts. If the same IP continues triggering lockouts, the next penalty could increase to 30 minutes.
This gives occasional legitimate mistakes a temporary recovery period while making persistent repeated attempts progressively less practical. The escalated duration is never configured shorter than the standard lockout, keeping the progression predictable.
Choose How Failed Login Attempts Are Counted
Different websites may prefer different ways of grouping failed authentication attempts.
The default IP mode maintains one failed-attempt counter for each IP address. If several usernames are attempted from the same address, they contribute to the same threshold.
Alternatively, IP + Username mode maintains separate counters for each username attempted from that IP.
The distinction can be useful on networks where many legitimate users share the same public IP address. A strict IP-only policy provides broader protection but can also mean that several users behind the same network contribute to one lockout. IP + Username mode gives each attempted login name its own counter within that address.
When a user successfully authenticates, WP PowerSuite clears the relevant failed-attempt and lockout state for that scope. A successful password does not, however, bypass an already active lockout; authentication remains unavailable until the lockout expires or an administrator removes it.
Protect XML-RPC Authentication Attempts
WordPress authentication can also happen through XML-RPC.
When XML-RPC remains enabled, failed XML-RPC login attempts can contribute to the same Limit Login Attempts protection. If the relevant scope is already locked, WP PowerSuite can stop the authentication request and return an HTTP 429 XML fault.
This prevents an attacker from simply moving from the normal login form to XML-RPC in an attempt to avoid the frontend lockout policy.
If your website does not use XML-RPC at all, the separate Disable XML-RPC module provides the stronger option of turning off that interface entirely. Limit Login Attempts is more relevant when XML-RPC needs to remain available but its authentication attempts should still be rate limited.
This distinction lets you choose between protecting an interface you need and disabling an interface you do not.
Protect REST Application Password Authentication
WordPress Application Passwords provide another authentication path for external applications using the REST API.
Limit Login Attempts can count failed Application Password authentication attempts and enforce a lockout when REST requests contain authentication credentials. Locked requests receive an HTTP 429 response rather than being allowed to continue repeatedly testing credentials.
Normal cookie-authenticated REST requests from logged-in WordPress users are not blocked by these REST lockouts. This keeps everyday dashboard and editor functionality separate from credential-based API authentication attempts.
If your website does not use Application Passwords at all, WP PowerSuite's Disable Application Passwords module can turn that authentication method off completely. If Application Passwords are required by legitimate integrations, Limit Login Attempts provides protection while leaving the functionality available.
Avoid Locking Trusted IP Addresses
Some websites have trusted networks or administrative locations where login lockouts are undesirable.
The Never Block IPs setting allows individual IPv4 or IPv6 addresses to bypass the lockout system. This can be useful for a trusted office connection, management server, or another known static address.
The allowlist intentionally accepts individual IP addresses rather than broad CIDR ranges. This keeps exceptions more narrowly scoped instead of allowing large network ranges to bypass authentication protection.
Care should still be taken with allowlisting. An address should only be excluded when it is genuinely trusted and sufficiently stable, particularly on shared or dynamic networks.
Handle Real Visitor IPs Behind Cloudflare and Proxies
Accurate IP identification matters for an IP-based lockout system.
WP PowerSuite can recognize Cloudflare's CF-Connecting-IP when it is available through the shared client-IP handling system. For other controlled proxy environments, a specific real-IP header can be configured when required.
Generic forwarding headers such as X-Forwarded-For are not blindly trusted. Those headers can contain multiple addresses or potentially be supplied by the client when the server infrastructure does not sanitize them correctly.
This conservative approach reduces the chance of allowing an attacker to manipulate the value used for login-attempt tracking simply by sending an arbitrary forwarding header.
If your WordPress installation sits behind a custom reverse proxy or load balancer, configure IP handling according to how that infrastructure passes the real client address.
