This lesson's interactive features are locked, please to keep using them

Protecting Auth from Abuse

Login and password-reset routes are unauthenticated and expensive, making them natural brute-force and credential-stuffing targets.

Be sure to apply the rate limit before any expensive database work or password verification, so abusive traffic doesn't cause unnecessary load on your servers!

Use both a source limit, like the request's IP, and an account limit, like the username or email being attacked. A source limit slows one caller attacking many accounts, and an account limit protects one account from attackers rotating through different IP addresses.

Don't apply account limits only to known usernames or emails. Different behavior can expose which accounts exist, so rate limit both known and unknown accounts the same way.

Assignment

Protect login and password-reset requests with both source- and account-based limits.

In internal/httpserver/app.go, create trusted-proxy-aware source limiters for:
- POST /login and POST /login/totp: 20 attempts per IP every 15 minutes
- POST /password-reset: 10 attempts per IP per hour
Create account limiters keyed by the trimmed, lowercased submitted email for:
- POST /login: 5 attempts per account every 15 minutes
- POST /password-reset: 3 attempts per account per hour
Apply the source limiter before the account limiter and before password verification or other expensive work.
Return the same 429 Too Many Requests error page and retry metadata for limited known and unknown accounts.
Start the app.

The local counters remain in memory. Production limits need a trusted proxy configuration and a shared store or edge service.

With Bearly Secure still running, run and submit the CLI tests from the project root.