Skip to content

feat(auth): add per-IP rate limiting to signup, signin, and password reset#4527

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
waleedlatif1 wants to merge 1 commit into from
Closed

feat(auth): add per-IP rate limiting to signup, signin, and password reset #4527

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions apps/sim/lib/auth/auth.ts
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -181,6 +181,19 @@ export const auth = betterAuth({
provider: 'pg',
schema,
}),
rateLimit: {
enabled: true,
customRules: {
'/sign-up/email': { window: 600, max: 3 },
'/sign-in/email': { window: 60, max: 10 },
'/forget-password': { window: 600, max: 3 },
},
},
Comment on lines +184 to +191

@greptile-appsgreptile-appsBotMay 9, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2In-memory rate limit state is per-ECS-task, not shared

The rate limiter defaults to in-memory storage, so each ECS task maintains its own counters. With N tasks running, any IP effectively gets max * N attempts before being blocked — e.g., 3 signups × 5 tasks = 15 signups unchecked cluster-wide. The PR description already flags this as a known follow-up, but it is worth noting explicitly: against a coordinated signup bot that distributes requests across tasks, the limit provides weaker-than-stated protection until storage: 'database' (or Redis) is added.

advanced: {
ipAddress: {
ipAddressHeaders: ['cf-connecting-ip', 'x-forwarded-for'],

@greptile-appsgreptile-appsBotMay 9, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1securityx-forwarded-for fallback enables rate-limit bypass

Including x-forwarded-for as a fallback header is exploitable when traffic reaches the ALB without going through Cloudflare. AWS ALB appends (but does not strip) client-supplied X-Forwarded-For values, so an attacker who reaches the ALB directly can send X-Forwarded-For: 1.1.1.1 and the ALB produces X-Forwarded-For: 1.1.1.1, <real-client-ip>. Better-auth reads the leftmost value, treating 1.1.1.1 as the client IP — a different spoofed address for every request, defeating the limit entirely. If cf-connecting-ip is always present when behind Cloudflare, the fallback only matters for requests that bypass Cloudflare, which are precisely the ones most at risk of IP-header forgery.

},
},
session: {
cookieCache: {
enabled: true,
Expand Down
Loading