Security: Implement Rate Limiting on Auth and API Routes

[rushikesh-bobade]

Problem Statement
Currently, our Supabase/Prisma architecture relies entirely on application-level logic for authentication and API mutations. We have no rate limiting in place for sensitive routes (e.g., /auth/login, /auth/reset-password, /api/insights), leaving the application vulnerable to brute-force attacks and DDOS.

Motivation
To become a production-grade platform, we must protect our backend from malicious scraping and credential stuffing.

Proposed Solution
Implement a lightweight Redis-based or memory-based rate limiter middleware for Remix actions and loaders.

1. Add a utility function rateLimit(request, limit, windowMs) in app/utils/rate-limit.server.ts.
2. Apply this utility to app/routes/login-page.tsx, app/routes/signup-page.tsx, and app/routes/reset-password.tsx.

Implementation Notes

• Since we are deploying to Vercel, memory-based limiters won't share state across serverless functions. We should investigate using @upstash/ratelimit if a Redis instance is available, OR implement a simple IP-based rate limiter using Vercel KV.
• If Redis is unavailable, fallback to a basic memory cache and clearly document the limitation.

Dependencies

• None. Can be worked on independently.

Out-of-Scope

• Do not implement rate limiting on frontend UI components. This is strictly backend middleware.

Acceptance Criteria

• rateLimit utility function is created.
• Attempting to login > 5 times in 1 minute throws a 429 Too Many Requests response.
• The user sees a clear error message: "Too many attempts. Please try again later."

Testing Requirements

• Add unit tests for the rateLimit function.

Documentation Updates

• Document the new utility in CONTRIBUTING.md so future developers know how to rate-limit their new API routes.

[pari-28]

Hi @rushikesh-bobade,

I'd like to work on this issue. I understand the requirements and will implement a reusable rateLimit utility, integrate it into the authentication routes, add appropriate fallback handling, return 429 Too Many Requests responses when limits are exceeded, include unit tests, and update the documentation while keeping the implementation within the defined scope.

Could you please assign this issue to me? Thank you!

[github-actions]

Hi @pari-28! 👋

Thank you for your interest in contributing to this repository! Please wait until a maintainer officially assigns you to this issue before opening a Pull Request.

While you wait, please consider starring ⭐ this repository to show your support! We review requests regularly and will assign it as soon as possible if it's available. Happy coding! 🚀

[rushikesh-bobade]

Hey @pari-28! 👋

Thank you so much for volunteering to tackle this one! Having rate limiting is going to be a huge step forward for the security and scalability of FlipTrack.

I have officially assigned this issue to you.

A quick tip before you get started: since we are deploying to Vercel (serverless environment), a standard Node.js memory cache won't persist across different serverless invocations.

• Ideally, look into using a lightweight Redis implementation (like @upstash/ratelimit or Vercel KV) if you can.
• If you opt for a simple memory-based fallback first, just make sure to clearly document that it is per-invocation so future maintainers are aware of the limitation.

Please make sure to check out our CONTRIBUTING.md for local setup instructions if you haven't already.

We're excited to see your PR! Let us know if you have any questions about the Remix loaders/actions or the implementation details along the way. Happy coding!

[harshitaaa0]

Hi @rushikesh-bobade , I'd like to work on this issue as part of ECSoC'26.

I've gone through the requirements and understand the need for a reusable backend rate-limiting utility to protect authentication and API routes from brute-force attacks. My plan is to implement a reusable rateLimit() utility, integrate it with the specified auth routes, return proper 429 Too Many Requests responses with the required error message, add unit tests, and update the contributor documentation. I'll also evaluate the existing codebase to determine whether Upstash/Redis is already available and otherwise implement the documented in-memory fallback as described in the issue.

If no one is currently working on this, I'd appreciate being assigned. Thank you!

[rushikesh-bobade]

Hi @harshitaaa0,

Thank you so much for your interest and for putting together such a solid technical plan!

Unfortunately, this issue was already assigned to @pari-28 a few days ago, and they have already submitted PR #99 which is currently under review.

Since we only assign one contributor per issue to avoid duplicate work, I won't be able to assign you to this one. However, we would love to have your help on the project! Feel free to browse through our other open issues (especially those without the "assigned" tag) and drop a comment when you find another backend feature that catches your eye.