Introduction The X-Forwarded-For (XFF) header can be spoofed by clients, leading to incorrect IP-based decisions (rate limiting, geo-blocking, audit logging). This is a security risk when the load balancer does not properly validate the header.

Symptoms - Rate limiting not working (fake IPs bypassing limits) - Geo-location showing incorrect countries - Audit logs recording wrong client IPs - IP-based access control bypassed - Fraud detection receiving incorrect IPs

Common Causes - Load balancer appending to existing XFF instead of replacing - Application trusting XFF from untrusted sources - Proxy chain not properly configured - Missing ProxyProtocol configuration - Multiple load balancers adding XFF incorrectly

Step-by-Step Fix 1. **Configure load balancer to replace XFF': ```nginx # Nginx: Use $remote_addr instead of trusting XFF # Or use real_ip_module set_real_ip_from 10.0.0.0/8; real_ip_header X-Forwarded-For; real_ip_recursive on; ```

  1. 1.**Application-side validation':
  2. 2.```python
  3. 3.# Only trust XFF from known proxy IPs
  4. 4.trusted_proxies = {'10.0.0.0/8', '172.16.0.0/12'}
  5. 5.def get_real_ip(request):
  6. 6.if request.remote_addr in trusted_proxies:
  7. 7.return request.headers.get('X-Forwarded-For', '').split(',')[0].strip()
  8. 8.return request.remote_addr
  9. 9.`

Prevention - Always replace XFF at the edge load balancer - Configure trusted proxy ranges in application - Use ProxyProtocol for TCP load balancers - Never trust XFF from direct client connections - Implement IP validation in WAF