Behind a reverse proxy: trusting forwarded headers correctly

Goal

Let the application know the real client address and scheme for rate limiting, logging and redirects, without giving clients a way to forge them.

Prerequisites

The exact address (or small CIDR) of the proxy on the application's network, and knowledge of which headers the proxy sets and whether it strips incoming ones.

Steps

1. Configure the proxy to overwrite or append forwarding headers rather than pass client-supplied ones through unchanged.
2. In the application, trust forwarding headers only when the TCP peer is the proxy; otherwise use the peer address as the client address.
3. Walk X-Forwarded-For from the right (the proxy's entry) to the left and stop at the first address that is not a trusted proxy; that is the client. Never take the leftmost value blindly.
4. Take the scheme from X-Forwarded-Proto (or the standard Forwarded header of RFC 7239) only under the same trust rule; use it for building absolute URLs and secure-cookie decisions.
5. Validate the Host header against an allow-list and derive canonical URLs from configuration, not from the request.
6. Test with forged headers from an untrusted peer and confirm they are ignored.

Expected result

Rate limits key on the real client, logs show real addresses, and a client cannot escape limits by sending X-Forwarded-For: 1.2.3.4.

Limits and test basis

Trusting a whole shared subnet lets any container in it spoof. Multiple proxy layers (CDN plus local proxy) need all hops in the trusted list. The rules follow the cited references and this wiki's own middleware tests.