Document best practices around using request.is_secure() in reverse proxy environments

[Adam Nelson]

As evidenced in these locations:

• #14597
• ​https://github.com/rossdakin/django-heroism
• ​http://packages.python.org/django-middleware-extras/usage.html
• ​http://yuji.wordpress.com/2008/08/15/django-nginx-making-ssl-work-on-django-behind-a-reverse-proxy/
• #6548

There is a need to document a best-practices way of handling an upstream django server (Gunicorn, etc...) behind a reverse proxy (Nginx, etc...) using the request.is_secure() method.

[Luke Plant]

I'm going to accept as 'Maybe/Someday', on the basis that I don't know that there is a 'best-practices way'.

The most commonly used method is to add a header like X-Forwarded-Protocol, but AFAICS it isn't so easy to configure common webservers to ensure that this header is not passed on if the request is not HTTPS i.e. stripping headers seems to be much harder. Without this ability, there is a big flaw in this method, because a MITM attack could add the header, fooling the web app into believing the request is secure.

It is possible to use a custom header which is not guessable by 3rd parties. However, this is problematic. 1) It means that we have a piece of webserver configuration information that is now a secret, so you now have to keep your webserver config secret. 2) It is insecure in shared hosting scenarios, and these are pretty common with Django hosting e.g. WebFaction.

We don't want to document a best-practice that is actually impractical. If you can point us to something that is actually a good way of doing it, please do so.

[Adam Nelson]

django-heroism uses two headers, 'X-Forwarded-Protocol' for what you say, and then X-Magic-Header with a secret value for validation that the headers have not been tampered with. This solves the problem you bring up.

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

As far as I can tell, 61f0aff811aa596fa62136852c59d47f988d1185 covers this.

There's extensive documentation for the SECURE_PROXY_SSL_HEADER setting.