I do not agree that the XFF header must be dropped and re-set. Doing so can in fact be harmful. There is a reason for preserving the chain of IPs, which is that it allows the app to use the rightmost-ish IP after skipping the known proxy IPs.
You do need to make sure only trusted parties get to add headers. Otherwise, you are letting the client freely define their own IP as seen by your server.
Dropping and re-setting the header at your trust boundary is just the simplest implementation of that. You could also count instances, or sign the header, but I don’t think there’s a standard for that, and it would mean quite some overhead.
I see it as a tradeoff. By dropping the header, one maintains trust, but one loses the ability to geolocate.
Instead of dropping, I maintain a list of trusted proxies, and I remove them from the list instead at the application level. The rightmost or final value is then the client.
> By dropping the header, one maintains trust, but one loses the ability to geolocate.
Not dropping. Dropping what the client sent, and recreating it yourself, with the client connection's ip address. The IP can still be geolocated, as much as an ip address can be...
AS numbers have a very rough mapping to a very wide spot on a map, but they are not at all guaranteed to be accurate or up to date, and applied more so back when we had plenty of ipv4 space left and enormous blocks were held by giant companies.
Nowadays, ipv4 address are much more fragmented, globally, and an ASN might own a ip block that says the ip is in Utah, but it has since been leased out to some VPS provider who attached it to a load balancer running in a datacenter in Germany.
There are better headers (or better yet a combination of headers) that can be used to get the user's location, and their locale (yes, where you live or connect from doesn't at all mean you speak the native language in that region).
