Bot defense and rate limiting: do's and don'ts
Updated 2026-05-07
Bot defense and rate limiting form the volume layer of ATO defense. Phishing-resistant auth (passkeys) eliminates the credential class for users who enroll; bot defense and rate limiting handle the residual attack volume against the long tail of users still on passwords. The do's and don'ts here distill the patterns that production B2C SaaS at scale relies on.
For broader ATO context, see the account takeover defense guide and the credential stuffing glossary entry.
Do
Filter at the network edge before requests reach auth APIs
Bot defense at the auth layer alone fails, credential stuffing volume can exceed millions of requests per day. The right place to filter is at the network edge (CDN, WAF, dedicated bot management) where the cost per request is lowest.
Cloudflare Bot Management, Akamai Bot Manager, DataDome, and PerimeterX all sit at the edge. Major B2C SaaS targets see 90%+ of credential-stuffing volume blocked at the edge before it ever reaches the application.
Rate-limit per IP, per account, and per session
Per-IP catches scripted attacks from single hosts. Per-account catches distributed attacks targeting one user. Per-session catches an authenticated session being abused. All three composed catches more than any one alone.
OWASP Authentication Cheat Sheet recommends layered rate limits: 5–10 attempts per IP per minute on auth endpoints, 5 per account per hour, 100 per session per hour. Tune to match observed legitimate user behavior.
Use invisible CAPTCHA at risky moments, not always-on
Always-on CAPTCHA is friction users hate. Invisible CAPTCHA (Cloudflare Turnstile, hCaptcha invisible, reCAPTCHA v3) scores requests in the background; visible challenge is reserved for high-risk attempts.
Cloudflare's Turnstile and Google's reCAPTCHA Enterprise have published deployment data showing invisible-first scoring catches the majority of bot traffic without affecting legitimate user conversion. Always-on visible CAPTCHA depresses signup conversion by 5–15% in published studies.
Tune detection per-deployment based on observed false-positive rate
Bot defense rules tuned for a generic SaaS will misfire on real users behind shared NAT, VPNs, corporate proxies, and accessibility tooling. Production-grade deployments tune rules against observed false-positive data.
Major bot management vendors (Cloudflare, Akamai, DataDome) all expose tuning dashboards. The first month of any bot-defense deployment should include weekly review of false-positive samples and rule adjustment.
Don't
Don't rely on rate limiting alone for credential stuffing defense
Distributed attacks rotate IPs faster than per-IP limits can detect. Per-account limits catch some, but attacker tooling now spreads attempts across millions of IPs and tens of thousands of accounts.
Modern credential-stuffing tooling (Sentry MBA, OpenBullet, BlackBullet) is designed specifically to defeat rate limits via residential-proxy networks. The defense stack must include device fingerprinting and bot detection, not just rate limits.
Don't expose user enumeration in error messages
'Invalid password' for known users and 'No such account' for unknown users lets attackers enumerate the user base for targeted follow-up. Identical responses for valid and invalid credentials prevent enumeration.
OWASP Top 10 includes user enumeration; modern CIAM (Auth0, Cognito, Stytch) ship the 'invalid credentials' (single response) pattern as the default for auth APIs.
Don't block legitimate VPN and Tor traffic by default
VPN and Tor users include privacy-conscious users, security researchers, journalists, and users in regions with restrictive networks. Blocking them by default is a real cost in legitimate user access.
Major B2C platforms (Apple, Google, Microsoft) document policy of allowing VPN/Tor with adaptive challenge rather than blocking. Reserve hard blocks for confirmed-abuse traffic, not category bans.
Don't deploy bot defense without observability
Without monitoring, the false-positive rate is unknown until users complain in support. Production-grade bot defense includes dashboards on block rate, challenge rate, false-positive samples, and conversion impact.
Major bot management vendors all expose telemetry. The teams that get bot defense right are the teams that watch the dashboards weekly and adjust; the teams that don't watch end up overblocking or underblocking until something breaks.