How to Add Rate Limiting and Brute-Force Protection

Before adding any controls, map every endpoint in your application that could be targeted by brute-force or automated abuse. Missing even one public-facing login or API endpoint leaves a door open for attackers.

• List every authentication endpoint: login, registration, password reset, email verification, and magic-link entry points.
• Identify API endpoints that accept credentials or tokens (OAuth token exchange, API key validation, etc.).
• Include admin panels, staging environments, and any third-party integration callbacks that authenticate users.
• Check for username enumeration vulnerabilities — endpoints that return different responses for valid vs. invalid usernames give attackers a starting point.
• Document expected legitimate traffic volumes for each endpoint so you can set sensible rate-limit thresholds.

Rate limiting restricts how many requests a single client can make within a given time window. It is the first and most broadly applicable defence against automated attacks — it slows down both brute-force password guessing and credential-stuffing campaigns.

• Apply rate limiting at the reverse proxy or load balancer level (e.g., Nginx limit_req, HAProxy stick-tables, AWS WAF rate rules, Cloudflare Rate Limiting) so limits are enforced before traffic reaches your application servers.
• Set strict limits on login endpoints — a common starting point is 5–10 requests per minute per IP address.
• Apply separate, tighter limits on password-reset and email-verification endpoints (e.g., 3 requests per 15 minutes per IP).
• Rate-limit by user identity (username or account ID) in addition to IP address to defend against distributed attacks spread across many IPs.
• Return HTTP 429 (Too Many Requests) with a Retry-After header so legitimate clients can back off gracefully without hammering the endpoint further.
• Avoid leaking information in error messages — return the same generic message for rate-limited requests as for failed logins.
• For APIs, implement token-bucket or sliding-window rate limiting at the API gateway layer and document the limits in your API spec.
• Sensagraph continuously checks your exposed endpoints for the presence of rate-limiting controls and flags those that accept unlimited requests.

Rate limiting by IP alone is insufficient against distributed botnets. Account-level lockout and progressive delays add a second layer that protects individual user accounts regardless of how many different IP addresses the attacker uses.

• Lock an account temporarily after a configurable number of failed login attempts (e.g., 5–10 consecutive failures within a rolling 15-minute window).
• Prefer temporary lockouts (e.g., 15–30 minutes) over permanent locks to avoid denial-of-service against legitimate users; require email confirmation or MFA to unlock early.
• Implement progressive delays (exponential back-off) as an alternative or complement — each failed attempt adds incremental delay (e.g., 1 s, 2 s, 4 s, 8 s…) before the next attempt is processed.
• Store failed attempt counters in a fast, shared data store (Redis or Memcached) so that all application instances share the same counter — not just per-server memory.
• Reset the counter only on a successful login, not merely on the passage of time, unless you also implement a time-based window.
• Notify the account owner by email when a lockout is triggered, including the timestamp and approximate geographic origin of the attempts.
• Provide a self-service unlock flow that requires access to the registered email address or MFA device.

CAPTCHA challenges are most effective when deployed after a small number of failures rather than on every request, to avoid harming the user experience for legitimate users while still blocking bots that cannot solve them.

• Trigger a CAPTCHA challenge after 3–5 consecutive failed login attempts from the same IP or for the same account.
• Use an invisible or low-friction CAPTCHA solution (e.g., Google reCAPTCHA v3, hCaptcha, Cloudflare Turnstile) to minimise friction for legitimate users.
• Validate CAPTCHA tokens server-side — never trust client-side validation alone.
• Ensure CAPTCHA is also applied to registration and password-reset flows, not just login.
• Have a fallback (audio CAPTCHA, email challenge) for users with accessibility needs.
• Rotate CAPTCHA secret keys regularly and store them securely (environment variables or secrets management, not source code).

Even with rate limiting and lockout policies in place, a successful brute-force attack could theoretically succeed given enough time or a weak password. MFA ensures that a correct password alone is not sufficient to gain access.

• Require MFA for all administrator and privileged accounts — no exceptions.
• Offer MFA to all users and strongly encourage adoption through in-app prompts and clear communication of the security benefit.
• Support time-based one-time passwords (TOTP via apps like Google Authenticator or Authy) as a minimum.
• Support hardware security keys (FIDO2/WebAuthn passkeys) for the highest level of phishing and brute-force resistance.
• Avoid SMS-only MFA for high-value accounts due to SIM-swapping risk; treat SMS as a fallback, not the primary method.
• Apply rate limiting and lockout policies to MFA verification attempts as well — do not leave the second factor unprotected.
• Provide secure account recovery codes (one-time-use, stored hashed) and educate users to store them safely.

Strong rate limiting is undermined if users are allowed to set trivially guessable passwords. Combine rate-limiting controls with robust password policies to reduce the value of each guess an attacker makes.

• Enforce a minimum password length of at least 12 characters; 16+ is recommended for new applications.
• Check new passwords against a list of known-breached passwords (e.g., using the Have I Been Pwned Pwned Passwords API or a local copy of the dataset) and reject matches.
• Do not require arbitrary complexity rules (e.g., mandatory symbols) that push users toward predictable patterns — length and breach-checking are more effective.
• Hash passwords using a strong, slow algorithm: bcrypt (cost factor ≥ 12), Argon2id, or scrypt. Never use MD5, SHA-1, or unsalted hashes.
• Do not enforce frequent mandatory password rotations unless a breach is suspected — this leads to incremental, predictable changes.
• Detect and block the use of common patterns such as the username, domain name, or sequential characters within the password.

Layering network-level controls on top of application-level rate limiting provides an additional barrier, especially against large-scale automated attacks originating from known malicious infrastructure.

• Integrate an IP reputation feed or threat intelligence service (e.g., via your WAF or CDN) to automatically block requests from IPs associated with botnets, Tor exit nodes, or known malicious actors.
• Consider restricting access to admin panels by IP allowlist if your administrators work from predictable network locations (offices or VPN).
• If your user base is geographically concentrated, consider challenging or blocking logins from unexpected countries — with a clear mechanism for legitimate travelling users to regain access.
• Log and review the autonomous system numbers (ASNs) of brute-force attempt sources to identify hosting providers that are frequently abused and apply provider-level blocks if necessary.
• Be careful not to over-block — shared NAT environments (corporate proxies, mobile carriers) can cause many legitimate users to appear behind a single IP.

Controls are only effective if you can verify they are working and detect when they are being bypassed. Comprehensive logging and real-time alerting are essential for both incident response and ongoing tuning of your thresholds.

• Log every authentication attempt — success, failure, lockout, and rate-limit trigger — with timestamp, source IP, user agent, and account identifier (never the password itself).
• Forward authentication logs to a centralised log management or SIEM system (e.g., ELK Stack, Splunk, Datadog, AWS CloudWatch) with appropriate retention policies.
• Create alerts for: a sudden spike in failed login attempts across multiple accounts (credential stuffing); repeated lockout triggers for a single account; login success from a new country or device immediately after repeated failures.
• Set alert thresholds based on your normal traffic baseline — review and adjust them quarterly.
• Test your alerting pipeline regularly by simulating failure scenarios in a staging environment.
• Retain authentication logs for a minimum of 90 days (longer if required by compliance frameworks such as PCI-DSS or ISO 27001).

Defences that have not been tested should not be trusted. Regularly verify that your controls behave as expected across all environments and after every significant code or infrastructure change.

• Write automated integration tests that simulate rapid successive login failures and assert that the 429 response and lockout are triggered at the correct thresholds.
• Test rate limiting from multiple IP addresses simultaneously to ensure your distributed counter (Redis, etc.) is being shared correctly across all application instances.
• Verify that rate limits survive a deployment — counters should persist across restarts and rolling updates.
• Test the account unlock flow end-to-end: trigger a lockout, receive the notification email, follow the unlock link, and confirm access is restored.
• Include rate-limiting and lockout checks in your CI/CD pipeline so regressions are caught before they reach production.
• Conduct periodic penetration tests or red-team exercises specifically targeting authentication mechanisms to uncover bypasses (e.g., header manipulation such as X-Forwarded-For spoofing to rotate IPs).
• Ensure that X-Forwarded-For and similar headers are only trusted from known, legitimate proxy addresses — an attacker can spoof these headers to bypass IP-based rate limiting if your application blindly trusts them.
• Sensagraph automatically probes your login and sensitive endpoints to verify rate-limiting and brute-force protection controls are active and correctly configured.

Rate limiting and brute-force protection are not set-and-forget controls. Attack techniques evolve, traffic patterns change, and new endpoints are added. A regular review cadence keeps your defences effective over time.

• Review rate-limit thresholds quarterly or after any significant change in user traffic volume.
• Subscribe to threat intelligence feeds and security advisories relevant to your technology stack to learn about new bypass techniques as they emerge.
• Include authentication security in your security champion or security review process for every new feature that introduces a login or API authentication flow.
• After any security incident involving authentication, conduct a post-mortem and update controls accordingly.
• Document your rate-limiting and lockout configuration in your security runbook so that on-call engineers can quickly understand and adjust settings during an active incident.