From the article: https://httptoolkit.com/blog/what-is-x-forwarded-for/ https://httptoolkit.com/blog/what-is-x-forwarded-for/ : > Dropping all external values

From the article: https://httptoolkit.com/blog/what-is-x-forwarded-for/ 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 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 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_via_http_headers 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 https://www.rfc-editor.org/rfc/rfc7239