Opened 5 years ago

Closed 4 years ago

#16046 closed New feature (fixed)

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

Reported by: Adam Nelson Owned by: nobody
Component: Documentation Version: 1.3
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

As evidenced in these locations:

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.

Change History (4)

comment:1 Changed 5 years ago by Luke Plant

Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset
Triage Stage: UnreviewedSomeday/Maybe

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.

comment:2 Changed 5 years ago by 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.

comment:3 Changed 5 years ago by Aymeric Augustin

UI/UX: unset

Change UI/UX from NULL to False.

comment:4 Changed 4 years ago by Aymeric Augustin

Resolution: fixed
Status: newclosed
Triage Stage: Someday/MaybeAccepted
Type: Cleanup/optimizationNew feature

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

There's extensive documentation for the SECURE_PROXY_SSL_HEADER setting.

Note: See TracTickets for help on using tickets.
Back to Top