[Investigation] Operational improvements for RateLimitingFilter

[GabrielNat1]

RateLimitingFilter (src/main/java/com/example/spring_boot_project/security/RateLimitingFilter.java) works but has several operational limitations that may cause incorrect rate limiting or resource issues in production.

Evidence

• Uses req.getRemoteAddr() to identify clients; behind proxies/load balancers this will reflect the proxy IP, not the client.
• The buckets map (buckets.computeIfAbsent) can grow without bound, causing memory pressure.
• When returning 429, the response does not set Retry-After header or Content-Type.

Impact

• Incorrect client identification when deployed behind proxies can lead to incorrect or bypassed rate limits.
• Unbounded growth of in-memory buckets may lead to memory leaks.
• Clients lack guidance on when to retry.

Recommendations

1. Respect X-Forwarded-For / X-Real-IP when properly configured/trusted; allow configuration to enable proxy-aware IP extraction.
2. Use a cache with eviction (Caffeine, Guava Cache) or external store (Redis) for buckets instead of an unbounded map.
3. When returning 429, include Retry-After and Content-Type headers and a helpful response body (JSON).
4. Consider rate limiting by API key/user in addition to IP.

Related files

• src/main/java/com/example/spring_boot_project/security/RateLimitingFilter.java