News
Rate Limits vs CAPTCHA on Public Login Pages
June 5, 2025
Rate limits vs CAPTCHA on public login is a layered abuse decision, not a single widget. Rate limits (and WAF bot rules) cap how often /login, /oauth/token, and password-reset can be hit from a network. CAPTCHA and similar challenges raise the cost of each automated attempt. Neither replaces MFA, SSO, or lockout policy on the account. Marketing /wp-login.php and app /oauth both need this; HTML-only limits leave the token endpoint lonely. RoastMyOpsec does not spray passwords or measure your limits. Presence of an auth path plus a missing edge fingerprint is a reminder to turn abuse controls on — not a proof they are off.
The practical difference
A rate limit is a quota: too many tries from an IP, ASN, or credential and the edge or app answers slowly or with 429. It is cheap for humans and expensive for stuffing farms if the key is right (per account, not only per IP).
A CAPTCHA or managed bot challenge is a puzzle: the client must look like a person or a trusted token. It helps when attackers already have many IPs. It fails when the real API client cannot solve a widget, or when you only put the puzzle on /login HTML and not on /api/auth.
How to choose based on the surface
Brochure WordPress: edge rate limit plus a challenge on wp-login.php, MFA on admin users, and no XML-RPC password guessing. Product apps: rate-limit token and reset routes at the WAF and in the app, challenge anonymous HTML login, keep machine clients on API keys or mTLS instead of a public puzzle.
If only the marketing host has a WAF and api. is the origin IP, stuffing walks around the costume. Pair this with the CDN vs origin and app-auth-path guides.
| Control | What it slows | What it does not do | Takeaway |
|---|---|---|---|
| IP / path rate limit | Volume from one network | Distributed stuffing; stolen valid passwords | Default on every auth route |
| Per-account lockout / backoff | Guessing one mailbox | Credential stuffing many accounts slowly | Needed with IP limits, not instead |
| CAPTCHA / bot fight | Cheap headless scripts on HTML login | Native apps and token APIs unless you add a server check | Put it where the form is; still rate-limit the API |
| MFA / SSO | Reuse of a stolen password | Session theft after login; XSS | Not optional for admin and customer accounts |
What a URL roast can and cannot see
The scanner may notice common auth paths and CDN/WAF header fingerprints. It will not fire thousands of logins to prove a 429. A clean roast is not a load-test certificate. Confirm quotas in the WAF console and application logs.
Do not ask a public scanner to 'verify rate limits work.' That is an attack against yourself with extra steps, and it is out of scope here.
Common mistakes
The first mistake is CAPTCHA on /login and unlimited POST to /oauth/token.
The second mistake is rate-limiting by IP only behind a carrier-grade NAT or a shared office.
The third mistake is treating a WAF fingerprint on www as proof that api. is protected.
Free audit the URL you own
RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.
Free audit nowFAQ
- Is CAPTCHA better than rate limiting?
- You want both classes of control. Limits cap volume. Challenges raise cost. MFA still stops a stuffed password that gets through.
- Will RoastMyOpsec tell me if my rate limit is too high?
- No. It does not send credential-stuffing traffic. Check WAF and app metrics. The roast only inventories public auth doors and edge fingerprints.
- Should I hide /login so bots cannot find it?
- Hiding is not authentication. See admin discoverability vs access control. Rate-limit and MFA the real login wherever it lives.