Opened 12 years ago

Closed 8 years ago

Last modified 6 years ago

#16870 closed Bug (wontfix)

CSRF too strict when no referer is present

Reported by: rtux Owned by: nobody
Component: CSRF Version: dev
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 12 years ago by rtux

Cc:… added

comment:2 Changed 12 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 12 years ago by rtux

Thank you for the detailed explanation!

comment:4 Changed 11 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 10 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 8 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 8 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 8 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 6 years ago by Tim Graham (previous) (diff)

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

As per policy! Close ticket :)

comment:10 Changed 8 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 6 years 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