Opened 5 years ago

Closed 3 years ago

#16046 closed New feature (fixed)

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

Reported by: adamnelson 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


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 lukeplant

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Someday/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 adamnelson

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 4 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:4 Changed 3 years ago by aaugustin

  • Resolution set to fixed
  • Status changed from new to closed
  • Triage Stage changed from Someday/Maybe to Accepted
  • Type changed from Cleanup/optimization to New 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