Opened 6 years ago

Closed 3 years ago

Last modified 2 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 (11)

comment:1 Changed 6 years ago by rtux

Cc:… added

comment:2 Changed 6 years ago by Paul McMillan

Resolution: wontfix
Status: newclosed

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 6 years ago by rtux

Thank you for the detailed explanation!

comment:4 Changed 6 years ago by Luke Plant

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

Version: 1.31.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 3 years ago by Jon Dufresne

Cc: jon.dufresne@… added
Version: 1.5master

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 3 years ago by Raúl Cumplido

Resolution: wontfix
Status: closednew

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 3 years ago by James Bennett

Resolution: wontfix
Status: newclosed

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

Last edited 3 months ago by Tim Graham (previous) (diff)

comment:9 Changed 3 years ago by Raúl Cumplido

As per policy! Close ticket :)

comment:10 Changed 3 years ago by Aymeric Augustin

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).

comment:11 Changed 2 months ago by Tim Graham <timograham@…>

In 0af14b2:

Refs #16870 -- Doc'd that CSRF protection requires the Referer header.

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