🛡️ Sentinel: implement dual rate-limiting on authentication server actions - #126
Conversation
…tions - Implement asynchronous dual rate-limiting (`rateLimitDual`) inside `src/lib/rate-limit.ts` combining client IP checks (first) and target-based checks (second) to safeguard against credential stuffing and Account Lockout Denial of Service (DoS) attacks. - Integrate `rateLimitDual` into both `signUpAction` and `signInAction` inside `src/app/actions/auth.ts` before database queries or CPU-intensive password-hashing verify calls. - Implement helper function `resetRateLimits()` to clear maps and resolve inter-test pollution. - Add comprehensive unit tests in `src/lib/__tests__/rate-limit.test.ts` to cover single and dual rate-limiting edge cases under `noUncheckedIndexedAccess`. - Update `auth-actions.test.ts` to call `resetRateLimits` in its `beforeEach` hook. - Append critical security learnings to `sentinel.md` journal. Co-authored-by: projectamazonph <286085559+projectamazonph@users.noreply.github.com>
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
|
Warning Review limit reached
Next review available in: 39 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. 📝 WalkthroughWalkthroughSignup and signin now use IP-first dual rate limiting. The rate-limit utility adds client-IP extraction, target protection, fallback handling, reset support, and comprehensive tests. ChangesAuthentication rate limiting
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
src/app/actions/auth.ts (1)
35-37: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueReplace em dashes in the new TypeScript comments.
src/app/actions/auth.ts#L35-L37: replace the em dash afterworkwith a period or comma.src/app/actions/auth.ts#L134-L136: replace the em dash afterworkwith a period or comma.As per coding guidelines, "Do not use emojis in code or commit messages, and do not use em-dashes."
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/app/actions/auth.ts` around lines 35 - 37, Replace the em dash after “work” with a period or comma in the comments at src/app/actions/auth.ts lines 35-37 and 134-136; no other changes are needed.Source: Coding guidelines
src/lib/__tests__/rate-limit.test.ts (1)
4-4: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueExplain the mock purpose or remove the comment.
The comment restates the mock declaration. State why the tests need controllable request headers.
As per coding guidelines, "Comments should explain why."
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/lib/__tests__/rate-limit.test.ts` at line 4, Update the comment above the next/headers mock to explain that the mock provides controllable request headers for testing rate-limit behavior, rather than merely describing what is mocked.Source: Coding guidelines
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/lib/rate-limit.ts`:
- Line 96: Normalize targetKey before the rateLimit call in the target-key path,
using the established key-normalization behavior or an explicit
normalized-target contract. In src/lib/rate-limit.ts lines 96-96, update the
code around rateLimit; in src/lib/__tests__/rate-limit.test.ts lines 51-77,
raise ipLimit above three and assert the third case-variant request is rejected
by targetLimit.
---
Nitpick comments:
In `@src/app/actions/auth.ts`:
- Around line 35-37: Replace the em dash after “work” with a period or comma in
the comments at src/app/actions/auth.ts lines 35-37 and 134-136; no other
changes are needed.
In `@src/lib/__tests__/rate-limit.test.ts`:
- Line 4: Update the comment above the next/headers mock to explain that the
mock provides controllable request headers for testing rate-limit behavior,
rather than merely describing what is mocked.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 37e46914-a0a0-4044-a853-9f759253ae11
📒 Files selected for processing (5)
.jules/sentinel.mdsrc/app/actions/__tests__/auth-actions.test.tssrc/app/actions/auth.tssrc/lib/__tests__/rate-limit.test.tssrc/lib/rate-limit.ts
| } | ||
| } | ||
|
|
||
| return rateLimit(targetKey, targetLimit, targetWindowMs); |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Normalize target keys and make the test evaluate the target bucket.
Line 96 sends case variants to separate target buckets. The test's third call is denied by ipLimit: 2 before it can validate target normalization.
src/lib/rate-limit.ts#L96-L96: normalize the target key before callingrateLimit, or define and enforce an explicit normalized-target contract.src/lib/__tests__/rate-limit.test.ts#L51-L77: setipLimitabove three and assert that the third case variant is rejected bytargetLimit.
Proposed fix
- return rateLimit(targetKey, targetLimit, targetWindowMs);
+ return rateLimit(targetKey.toLowerCase(), targetLimit, targetWindowMs);- ipLimit: 2,
+ ipLimit: 5,📍 Affects 2 files
src/lib/rate-limit.ts#L96-L96(this comment)src/lib/__tests__/rate-limit.test.ts#L51-L77
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/lib/rate-limit.ts` at line 96, Normalize targetKey before the rateLimit
call in the target-key path, using the established key-normalization behavior or
an explicit normalized-target contract. In src/lib/rate-limit.ts lines 96-96,
update the code around rateLimit; in src/lib/__tests__/rate-limit.test.ts lines
51-77, raise ipLimit above three and assert the third case-variant request is
rejected by targetLimit.
…nd resolve CI pnpm failure - Implement asynchronous dual rate-limiting (`rateLimitDual`) inside `src/lib/rate-limit.ts` combining client IP checks (first) and target-based checks (second) to safeguard against credential stuffing and Account Lockout Denial of Service (DoS) attacks. - Integrate `rateLimitDual` into both `signUpAction` and `signInAction` inside `src/app/actions/auth.ts` before database queries or CPU-intensive password-hashing verify calls. - Implement helper function `resetRateLimits()` to clear maps and resolve inter-test pollution. - Add comprehensive unit tests in `src/lib/__tests__/rate-limit.test.ts` to cover single and dual rate-limiting edge cases under `noUncheckedIndexedAccess`. - Update `auth-actions.test.ts` to call `resetRateLimits` in its `beforeEach` hook. - Pin `packageManager` in `package.json` to stable `pnpm@11.12.0` to prevent CI setup-pnpm self-installer failure with broken `pnpm@11.13.0`. - Append critical security learnings to `sentinel.md` journal. Co-authored-by: projectamazonph <286085559+projectamazonph@users.noreply.github.com>
…nd resolve CI pnpm failure - Implement asynchronous dual rate-limiting (`rateLimitDual`) inside `src/lib/rate-limit.ts` combining client IP checks (first) and target-based checks (second) to safeguard against credential stuffing and Account Lockout Denial of Service (DoS) attacks. - Integrate `rateLimitDual` into both `signUpAction` and `signInAction` inside `src/app/actions/auth.ts` before database queries or CPU-intensive password-hashing verify calls. - Implement helper function `resetRateLimits()` to clear maps and resolve inter-test pollution. - Add comprehensive unit tests in `src/lib/__tests__/rate-limit.test.ts` to cover single and dual rate-limiting edge cases under `noUncheckedIndexedAccess`. - Update `auth-actions.test.ts` to call `resetRateLimits` in its `beforeEach` hook. - Pin `packageManager` in `package.json` to the verified healthy `pnpm@11.14.0` version to resolve CI setup-pnpm self-installer failures with broken releases. - Append critical security learnings to `sentinel.md` journal. Co-authored-by: projectamazonph <286085559+projectamazonph@users.noreply.github.com>
🛡️ Sentinel: [improving area/improvement type]
🚨 Severity
HIGH
💡 Vulnerability
The application originally relied on a single-key rate-limiting helper inside authentication server actions (
signUpActionandsignInAction) constrained only on target emails. This left the authentication entry points vulnerable to brute-force credential stuffing and, critically, Account Lockout Denial of Service (DoS) where an attacker could easily lock out legitimate users from accessing their accounts by repeatedly making failing requests with their emails from different IPs, or lock out whole networks via IP lockout.🎯 Impact
A targeted brute-force or credential stuffing attack could trigger a CPU-exhaustion DoS on the Next.js event loop due to heavy cryptographic operations (e.g. password verification), or completely lockout legitimate student and admin accounts through bucket exhaustion of their specific email identifiers.
🔧 Fix
rateLimitDualfunction insrc/lib/rate-limit.tsthat safely extracts client IP from headers (x-forwarded-forandx-real-ip) under strict TypeScript parameters (noUncheckedIndexedAccess) and checks the IP limit before checking the target key's limit.signUpActionandsignInActioninsrc/app/actions/auth.tswithrateLimitDual, ensuring limits are enforced before any database lookups or password hashing.resetRateLimits()to prevent state pollution between unit tests.src/lib/__tests__/rate-limit.test.tscovering IP extraction, IP-bypass-first, case-insensitivity on email addresses, and graceful fallback..jules/sentinel.md.✅ Verification
pnpm typecheck), ESLint (pnpm lint), and production build (pnpm build) are 100% clean.PR created automatically by Jules for task 3105092884023430613 started by @projectamazonph
Summary by CodeRabbit
Bug Fixes
Documentation