0
I think HTTP_X_FORWARDED_PROTO
is dangerous if you use it blindly because it makes Django think you are receiving an HTTPS request (even if HTTP_X_FORWARDED_PROTO
is, in fact, spoofed).
But, if you are behind a properly functioning load balance/proxy (like AWS) then you can be confident that HTTP_X_FORWARDED_PROTO
is being set correctly. In this case, HTTP_X_FORWARDED_PROTO
serves to tell Django that it’s fine, don’t worry about it (because you are trusting the proxy to not allow through a spoofed header), and stop trying to continuously redirect to SSL.
Finally, HTTP_X_FORWARDED_PROTO
behind a proxy/load balancer is necessary even if you aren’t using SECURE_SSL_REDIRECT = True
(e.g. if the redirection is happening in a properly configured web server before getting to Django), because it also affects the is_secure()
function on the request, which would always be false if your proxy is swallowing the original request (e.g. it’s common to go from HTTPS between the client and your proxy/load balancer to HTTP between your proxy/load balancer and a web server).