Brute force / rate limiting protection
Rate limiting on the login page prevents an attacker from automatically trying thousands of email/password combinations (brute force or cred…
Analyse my site for freeUnderstanding "Brute force / rate limiting protection"
Rate limiting on a login page restricts how many authentication attempts a single IP address can make within a given time window. Without this protection, an attacker can submit thousands of email/password combinations per minute using an automated script until the correct one is found — a brute-force attack.
An even more dangerous variant is credential stuffing: the attacker uses lists of email/password pairs stolen from other sites (often traded on the dark web after a data breach) and tests them en masse, betting that some users reuse the same password everywhere. Rate limiting makes both attacks far slower and more costly to carry out.
How TheSiteFuse checks "Brute force / rate limiting protection"
TheSiteFuse looks for a login page among common paths (/login, /account/login, /signin, /user/login, /wp-login.php). Once a page responds, it sends 5 successive POST requests with deliberately incorrect credentials (test@test.com / wrong password). If any response returns a 429 (Too Many Requests) status or includes a Retry-After header, the check passes. Otherwise it is flagged as a warning — note that 5 attempts may not be enough to trigger protections with a higher threshold, so a warning does not definitively prove the absence of protection.
Why "Brute force / rate limiting protection" matters
Lack of rate limiting on login pages exposes your site to:
- Account takeover — a patient attacker can guess weak or common passwords using dictionary lists.
- Credential stuffing — automated, large-scale reuse of email/password pairs leaked from other sites' data breaches.
- Application-level denial of service — a massive flood of login requests can saturate your server or database, slowing the site for all legitimate visitors.
- Account enumeration — without limiting, an attacker can also test which email addresses are registered by observing different error messages ("unknown email" vs "wrong password").
Fix "Brute force / rate limiting protection" step by step
Nginx (limit_req)
http {
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
}
location /login {
limit_req zone=login burst=3 nodelay;
limit_req_status 429;
}
Flask (Flask-Limiter)
pip install Flask-Limiter
from flask_limiter import Limiter
from flask_limiter.util import get_remote_address
limiter = Limiter(app=app, key_func=get_remote_address)
@app.route('/login', methods=['POST'])
@limiter.limit("5 per minute")
def login():
...
WordPress
Install a dedicated plugin such as Limit Login Attempts Reloaded or Wordfence, which temporarily blocks an IP after N failures.
At server/network level
Fail2ban watches your logs and automatically bans IPs after repeated failures — a generic solution that works regardless of your CMS. A WAF (Web Application Firewall) such as Cloudflare also offers configurable rate-limiting rules without touching application code.
Reference resource
To deepen your understanding of the technical concepts behind this check, see the dedicated Wikipedia article.
Wikipedia — Brute force / rate limiting protectionDoes your site pass this check?
Run the free full audit (120 checks) and instantly discover what needs fixing.