3 ms·

I think one issue is that we expect to rely on a standard here, while only a proprietary solution, specific to the infrastucture seems to make sense. Basically

I think one issue is that we expect to rely on a standard here, while only a proprietary solution, specific to the infrastucture seems to make sense. Basically the first device in the infrastucture, whether it is a load balancer, a cache, etc. should set (or overwrite, if it's been spoofed) a custom proprietary header with the client IP. And that's what you can rely on - either it's set and you have the IP or its not and you can't really trust anything else. He mentions Azure and a few others doing this and that sounds like the only correct approach. (Although there's still an issue when the infrastructure is changed, and the application code is not updated - in that case the old header might no longer be set, and could now be spoofed)

marcosdumay 5y ago
The standard is not really the problem. The standard existing allows you to use off the shelf middleware and widespread libraries to solve your problem. The problem here is that your border box should remove any such header that comes from an untrusted network, and not append to them.
adam-p 5y ago
I agree. However, you need to be _really_ careful about using the IP provided by your CDN, etc. For example, Akamai sets `True-Client-IP`... but doesn't overwrite it if it's present. By default, Fastly does the same with `Fastly-Client-IP`. (Yes, Azure is better, but make sure you pick the _right_ special header.) Minefields within minefields.