On point 7, the rate limit key uses the first x-forwarded-for value, and that one is set by the client. If the host doesn't overwrite the header, someone can rotate it per request and never hit the limit. Using the platform's own client IP header, or the last trusted hop, closes that, and it's worth pairing the IP with the account or email for OTP routes.
Hi Tarun! You're right - trusting the first X-Forwarded-For value without verifying how the proxy handles it can make the rate limit spoofable. The correct approach is to use the hosting platform's trusted client-IP header or derive the IP from a properly configured trusted proxy chain. Pairing IP-based limits with account or email-based limits for OTP routes adds another layer of protection. I'll clarify this in the example.
Tarun Sharma
React.js Frontend Web Developer | Next.js Specialist
On point 7, the rate limit key uses the first x-forwarded-for value, and that one is set by the client. If the host doesn't overwrite the header, someone can rotate it per request and never hit the limit. Using the platform's own client IP header, or the last trusted hop, closes that, and it's worth pairing the IP with the account or email for OTP routes.