Opened 4 years ago

Closed 12 months ago

Last modified 12 months ago

#16870 closed Bug (wontfix)

CSRF too strict when no referer is present

Reported by: rtux Owned by: nobody
Component: CSRF Version: master
Severity: Normal Keywords:
Cc:…, jon.dufresne@… Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


For privacy reasons, users may decide to stop their browser from sending referer headers, which is fine with probably 99.9% of the webpages. I recently had troubles logging into launchpad, which uses django’s csrf-protection and it turned out to be due to the missing referer header from my browser.
So just the fact, that the header is missing should not imply, that the request is invalid.

This concerns mainly the function django.middleware.csrf.CsrfViewMiddleware.process_view

Change History (10)

comment:1 Changed 4 years ago by rtux

  • Cc… added
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:2 Changed 4 years ago by PaulM

  • Resolution set to wontfix
  • Status changed from new to closed

This is intentional and is not likely to change. We are looking at adding support for the Origin header, which has similar functionality, but we will not remove the requirement entirely. We only require the referer header in the case that you're coming from an SSL encrypted Django site back to that same site, in which case the privacy implications of blocking the header are pretty nonexistent.

Instead of blocking the header altogether, you might consider an addon that does something more intelligent like blocking it only when moving from one domain to another.

Unfortunately, this check is absolutely necessary for the security of Django's CSRF protection. Without it, we can't prevent man-in-the-middle attacks on SSL sites. We made the decision that preventing MITM was a more valuable tradeoff than breaking sites for the small minority of users who block the header in a fashion which does not improve privacy.

comment:3 Changed 4 years ago by rtux

Thank you for the detailed explanation!

comment:4 Changed 4 years ago by lukeplant

For reference, this Firefox add-on looks like it implements the kind of referer blocking you need:

(I do not know if you are using Firefox or not).

comment:5 Changed 3 years ago by ilf

  • Version changed from 1.3 to 1.5

I'm hitting this on 1.5 and find it very annoying. There's also a lengthy discussion on this over here:

comment:6 Changed 12 months ago by jdufresne

  • Cc jon.dufresne@… added
  • Version changed from 1.5 to master

This issue came up recently on django-developers:!msg/django-developers/4ZDBMulE-W0/_iKRIGctxccJ

One recent development that makes this more of a concern than in the past is the new HTML referrer tag:

comment:7 Changed 12 months ago by raulcd

  • Resolution wontfix deleted
  • Status changed from closed to new

Reopen bug so we take a look. I also think that things have changed since the bug was open and due to new implementation of browsers the % of users that may want to not send their HTTP_REFERER header may increase.

comment:8 Changed 12 months ago by ubernostrum

  • Resolution set to wontfix
  • Status changed from new to closed

Per the ticket/triaging documentation, do not re-open a ticket which has been closed "wontfix" by a member of the Django core team:

comment:9 Changed 12 months ago by raulcd

As per policy! Close ticket :)

comment:10 Changed 12 months ago by aaugustin

Perhaps we should document that Django's CSRF protection is incompatible with <meta name="referrer" content="none"> and requires at least the origin for same-site requests (in which case there are no privacy concerns).

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