Documentation
Getting started
Self-hosting
Concepts
Sign-in methods
Organizations & teams
Enterprise SSO & SCIM
Customization
Security
Integrations & operations
For AI agents

Attack protection

AdminUpdated Sep 11, 2026

Attack protection

Attack protection is Atlas's front line against automated abuse: credential stuffing, brute-force guessing, bot sign-ups and the reuse of passwords that are already public. You find it under Security → Attack protection.

The layers of attack protection

Rate limits

Atlas rate-limits authentication endpoints by default, keyed so that one abusive client can't exhaust the budget for everyone. Sign-in, sign-up, code verification and reset are all bounded, which turns online guessing from "unlimited attempts" into a losing game.

Brute-force lockout

Repeated failed attempts against an account trigger an automated lockout — the account is frozen for a cooling-off period rather than letting an attacker keep guessing. Legitimate users almost never hit it; when they do, an admin can clear the lockout for that user from the dashboard, or the user waits it out. Turning the lockout off is possible but flagged in the UI as weakening sign-in defenses.

Breached-password checks

When enabled, Atlas rejects passwords known to appear in public breach corpuses — at sign-up and at password change. This stops the single most common account-takeover vector (reused, already-leaked passwords) at no UX cost. Keep it on.

Bot detection & CAPTCHA

Atlas runs a risk pipeline over each sensitive attempt and can require a CAPTCHA challenge when a request looks automated:

  • Providers: hCaptcha and Cloudflare Turnstile, verified server-side (the token is checked against the provider before the attempt proceeds), plus an AWS WAF managed option.

  • Signals: the pipeline records a risk verdict per attempt using network origin (ASN/datacenter/Tor), geo (country/city, impossible-travel), and the CAPTCHA result. These rows are visible newest-first so you can see why a request was challenged.

  • Configuration: set the provider and paste its secret under Security — the secret is write-only and never returned. Until configured, CAPTCHA is simply off.

Because the risk signals include geo and network origin, Atlas can also step up to MFA on a risky sign-in rather than block it outright.

Enabling it

  1. Open Security → Attack protection.

  2. Confirm rate limits and the brute-force lockout are on.

  3. Turn on breached-password rejection.

  4. Choose a CAPTCHA provider and paste its secret.

  5. Save. Changes apply to the hosted pages, widget and SDK immediately.

Next

Decide who's even allowed to sign up → Allowlist & blocklist.

Was this page helpful?