Login Rate Limit Checker
Does your login page stop bots from guessing passwords? We send a small burst of requests with fake credentials and check whether the server ever responds with a 429 — the signal that blocks brute-force and credential-stuffing attacks.
This tool sends up to 8 POST requests with fixed fake credentials (secscan-probe@example.com / wrong-password-secscan-probe). It cannot log in to anything. Only test domains you own or are authorized to assess.
What is login rate limiting and why does it matter?
Rate limiting on an authentication endpoint means the server counts failed login attempts and, after a threshold, returns HTTP 429 Too Many Requests — telling the caller to slow down or stop. Without it, a bot can hammer your login page with thousands of password guesses per second with no pushback from the server.
Two attacks exploit the gap. Brute force tries every combination against one account until it hits the right password. Credential stuffing takes email/password pairs leaked from other breaches and replays them at your login page, counting on password reuse. Both attacks are fully automated and both are stopped cold by a 429 after a handful of failures.
The fix is simple — any backend framework can add a counter per IP or per account and return 429 after 5–10 failures. The cost is minutes of development time; the risk of not doing it is a full account-takeover pipeline available to any attacker with a laptop.
How to add rate limiting to your login page
Work through these in order — each layer adds independent defense so a bypass at one layer doesn't immediately compromise the rest:
- Return HTTP 429 with a Retry-After header after 5–10 failed attempts per IP, per account, or both. Most frameworks have middleware for this (express-rate-limit, Django Axes, Spring Security, Rack::Attack).
- Apply exponential back-off: the lockout period doubles on each subsequent breach so that an attacker who rotates IPs still faces increasing delay.
- Add a CAPTCHA challenge (Turnstile, hCaptcha) after the second or third failure — this breaks the automation without locking out the legitimate user.
- Consider account-level lockout after a higher threshold (20–50 failures), combined with an email notification to the owner so they know an attack happened and can reset if needed.
- At the infrastructure layer, WAF rules (Cloudflare, AWS WAF, Azure Front Door) can absorb high-volume credential-stuffing bursts before they reach your application.
Want the full background? Read the in-depth guide →
Frequently asked questions
Is this checker free?
Yes — completely free, no account and no signup. Enter a domain or login URL and get the result immediately. The check sends a small burst of requests with provably fake credentials (secscan-probe@example.com / wrong-password-secscan-probe) and measures whether the server responds with a 429 or Retry-After at any point.
What credentials does it use?
The probe uses the fixed fake email secscan-probe@example.com and username secscan-probe with the password wrong-password-secscan-probe. These cannot belong to a real account. The goal is not to log in — it is to see whether the server enforces a request limit when faced with repeated failures.
My login page wasn't found — why?
The checker probes the most common auth paths (/login, /signin, /api/auth/login, /oauth/token, /connect/token and more). If your app uses a non-standard path, paste the full URL of your auth API endpoint — for example, https://example.com/api/auth/login or https://example.com/api/v2/authenticate. The tool will probe that exact endpoint first.
What does 'protected' mean exactly?
It means the server returned an HTTP 429 Too Many Requests status, or a Retry-After header, at some point during the 8-request burst. Either signal tells clients and attackers to slow down, which defeats automated credential-stuffing tools that rely on high request throughput.
Why is missing rate limiting a serious risk?
Without a limit, an automated bot can try thousands or millions of password combinations against an account — either brute-forcing a specific account or credential-stuffing with passwords leaked from other breaches. This is one of the most common ways accounts are compromised, and it costs nothing to fix: a simple 429 after 5–10 failed attempts stops the attack.
Related tools
Check the full attack surface — free.
The full external scan goes beyond a single endpoint: subdomains, open services, exposed secrets, and known-exploited CVEs, run under your authorization.