From the article: https://httptoolkit.com/blog/what-is-x-forwarded-for/ :

> Dropping all external values like this is the safest approach when you're not sure how secure and reliable the rest of your call chain is going to be. If other proxies and backend apps are likely to blindly trust the incoming information, or generally make insecure choices (which we'll get into more later) then it's probably safest to completely replace the X-Forwarded-For header at that outside-world facing reverse proxy, and ditch any untrustworthy data in the process.

X-Forwarded-For: https://en.wikipedia.org/wiki/X-Forwarded-For :

> Just logging the X-Forwarded-For field is not always enough as the last proxy IP address in a chain is not contained within the X-Forwarded-For field, it is in the actual IP header. A web server should log both the request's source IP address and the X-Forwarded-For field information for completeness

HTTP header injection: https://en.wikipedia.org/wiki/HTTP_header_injection

This OWASP page has a list of X-Forwarded-For and X-FORWARDED-foR and similar headers; "Headers for IP Spoofing" https://owasp.org/www-community/pages/attacks/ip_spoofing_vi...

A sufficient WAF should detect all such attempts.

The X-Forwarded-For Wikipedia article mentions that RFC 7239 actually standardizes the header and parsing:

  Forwarded: for=192.0.2.60;proto=http;by=203.0.113.43
  Forwarded: for="[2001:db8::1234]"

RFC 7239: "Forwarded HTTP Extension" (2014): https://www.rfc-editor.org/rfc/rfc7239

What is X-Forwarded-For and when can you trust it? (2024)