[Devops]: express-rate-limit uses default in-memory store — limits are per-instance and reset on restart

[Srejoye]

Bug Description

All rate limiters in backend/middlewares/rateLimiter.js (authLimiter, aiLimiter, generalLimiter, sensitiveAuthLimiter) are constructed without a store option, so express-rate-limit falls back to its default in-memory MemoryStore. Combined with app.set("trust proxy", 1) in server.js — indicating the app is built for a proxied cloud deployment (Render) — this means rate-limit counters do not survive process restarts and are not shared across multiple instances.

Steps to Reproduce

1. Deploy (or simulate) two instances/processes of the backend behind a load balancer or reverse proxy.
2. From a single client IP, send requests to an endpoint guarded by authLimiter or aiLimiter, distributing them across both instances.
3. Compare the total number of successful requests to the configured max.

Expected Behavior

Rate limits (e.g. 50 login attempts / 15 min, 20 AI requests / hour) should be enforced cumulatively per client regardless of which backend instance handles the request, and should persist correctly across restarts/deploys.

Actual Behavior

Each instance maintains its own independent in-memory counter, so a client can receive roughly max * number_of_instances requests through in a single window, and any restart or deploy resets all counters to zero — silently weakening brute-force protection on auth endpoints and cost controls on paid AI/LaTeX API calls.

Severity

High

Screenshots / Screen Recording

No response

Browser

No response

Operating System

No response

Additional Context

No response

[Srejoye]

Technical understanding: express-rate-limit's default MemoryStore keeps counters in local process memory keyed by IP; it has no cross-process or cross-restart shared state, making it fundamentally incompatible with any deployment topology involving more than one running instance — a distributed-systems correctness gap rather than a coding bug.

Affected: backend/middlewares/rateLimiter.js (all four limiters), backend/server.js (trust proxy / multi-origin config implying cloud/proxied deployment).

Proposed fix approach: swap MemoryStore for a shared external store, e.g. rate-limit-redis backed by a Redis instance (already a natural fit alongside the existing MongoDB dependency), so all instances share counters. Document the single-instance limitation in README/TROUBLESHOOT.md until Redis-backed limiting is implemented, so operators aren't misled about the actual protection level in production.

Regression/unit tests: with a mocked shared store, assert that rate-limit counters are consistent when simulated across two "instances" of the limiter middleware pointed at the same store; add a test asserting the configured max is enforced cumulatively rather than per-middleware-instance.

Requesting this as a GSSoC'26 assignment (devops/infra track).