fix(security): add validation for X-Forwarded-For header in rate limiter

[anshul23102]

Summary

This PR fixes the rate limiter vulnerability by adding validation for X-Forwarded-For headers. The rate limiter now requires explicit configuration before trusting proxy headers, preventing trivial per-IP bypass attacks.

Problem

The get_client_key() function in middleware.py blindly trusts the X-Forwarded-For header without validation:

• Any client can spoof X-Forwarded-For to appear as different IPs
• Rate limiting per client IP becomes ineffective
• Attackers can bypass rate limits by sending different IPs in each request

Solution

1. Added TRUST_PROXY_HEADERS environment variable (defaults to false)
2. Header validation - only uses X-Forwarded-For if explicitly enabled
3. Secure IP extraction - uses rightmost IP in chain (most recent/trusted hop)
4. Fallback behavior - defaults to direct connection IP for security
5. Production safe - requires explicit opt-in for proxy header trust

Changes

• backend/app/middleware.py: Updated get_client_key() with conditional proxy header handling
• backend/app/config.py: Added trust_proxy_headers boolean setting

Security Impact

• Prevents spoofed X-Forwarded-For from bypassing rate limits
• Secure by default (proxy headers not trusted unless enabled)
• Protects API endpoints from abuse and resource exhaustion

Testing

• Rate limiting uses direct connection IP by default
• When TRUST_PROXY_HEADERS=true, uses X-Forwarded-For rightmost IP
• Spoofed X-Forwarded-For is ignored when disabled
• Rate limits properly block requests from same IP/proxy

Related Issue

Closes #709

---

This contribution is part of GSSoC 2026. Please consider adding the gssoc-approved label when reviewed.