Trusted Reverse Proxy
This module helps Drupal sites running behind trusted reverse proxies correctly identify the client's IP address by inspecting headers like X-Forwarded-For. It also adjusts system status reports to acknowledge this setup, preventing unnecessary errors. Use this module only if you fully trust your upstream reverse proxies and understand the security implications.
A simple module designed to run on sites that are known to operate in environment(s) behind known trusted reverse proxies. This module presently performs a number of specific tasks:
- Inspecting
x-forwarded-forheaders to identify reverse proxies and trust the left-most IP found as the client IP. (For instance, you may be behind no or only one reverse proxy during local development but behind CloudFlare and a TLS-terminating reverse proxy and then Varnish in production. - Demoting the status report/requirements error for a missing trusted host pattern setting to a "checked" finding. This is a proposed change in Core: #3166866: Don't raise requirements error when no trusted_host_patterns and behind trusted reverse proxy
Why a contrib module? This is complex enough a set of overrides that it is not easily accomplished in one or two configuration changes, and hopefully this project provides a collection point for best practices on keeping Drupal a best-in-class cloud native product by adopting sensible defaults in the cloud.
Scary-sounding warning
This module is all about trusting your upstream reverse proxies. If you don't trust them, don't use this module.
Furthermore, if you don't fully understand why you would do such a thing, don't use this module.
Things to consider:
- Does your first-hop reverse proxy rewrite `x-forwarded-for` instead of passing through any headers received from the client request?
- Are your remaining hops on a private network, or otherwise restrict communication from only trusted reverse proxies?
- Do you understand HTTP mechanics sufficiently to understand the implications of implementing this module?
Basically, if clients are able to spoof the x-forwarded-for header, things like IP blacklisting/whitelisting, fail-2-ban by IP, or other such features on your site could be circumvented. Know your upstream.