Implement Modern CSRF Protection

[feliperalmeida]

Code of Conduct

• I agree to follow Django's Code of Conduct

Feature Description

Django's CSRF protection is based on tokens. It works well but requires some effort from the developer to make it happen - passing around CSRF tokens in templates, form fields and HTTP headers.

Today, a more modern implementation can be achieved using Fetch Metadata and Origin request headers. Those headers are automatically sent by the browser. This is how the Go standard library implements CSRF protection. A very good resource about the implementation is available here.

This proposal is to implement the Go's stdlib CSRF protection approach on Django. It uses the Sec-Fetch-Site header with Origin as a fallback. Regarding browser compatibility, this covers all versions of Chrome and Safari ever, Firefox going back to 2019, Edge going back to 2018, and even IE 11. (source, caniuse).
The algorithm is described here.

Related Resources

https://web.dev/articles/fetch-metadata
https://words.filippo.io/csrf/
OWASP/CheatSheetSeries#1803

Problem

• Modernize Django's CSRF protection mechanism
• Reduces developer friction, as there's no need to implement token logic on the front-end
• Simpler logic on the backend

Request or proposal

proposal

Additional Details

Requests for something like this:

• https://chaos.social/@apollo13/115026470230309000
• https://code.djangoproject.com/ticket/31823
• https://discord.com/channels/856567261900832808/1432815378861527151 (some people on this thread)
• https://www.reddit.com/r/django/comments/1oihb4l/comment/nm1xdhe/

Implementation Suggestions

I already took a shot implementing this at the django-modern-csrf library. You can see the actual algorithm implementation here.

There are some considerations to discuss before implementing this in Django. The ones I can think of:

CSRF_TRUSTED_ORIGINS

The Sec-Fetch-Site header uses different values for same-site and same-origin. This conflicts with the current approach for trusted origins. For example, if CSRF_TRUSTED_ORIGINS is set to https://*.example.com, it won't be possible to deny same-site requests.

Probably a new setting will need to be created so the developer can pick the appropriate allowed values for the Sec-Fetch-Site header. Something like:

CSRF_SEC_FETCH_ALLOWED: Defines values allowed on the Sec-Fetch-Site header. Default: ['same-origin', 'none'].
Suggestions for the setting name are welcome

So if the developer wants to allow *.example.com, both settings would have to be set accordingly (_TRUSTED_ORIGINS and the new one).

HTTPS

The Sec-Fetch-Site header is only sent to trustworthy origins, i.e. HTTPS and localhost. As the Origin header serves as a fallback, it shouldn't be a concern - however it's good to have it documented.

@csrf_protect

The csrf_protect decorator currently wraps the CsrfViewMiddleware on the view. If the new approach is implemented as a separate middleware this will have to be updated.

Let the user choose the best protection strategy - and pick a default

I think developers should be able to pick the right protection strategy for their needs. Even though the modern approach will probably be enough for most users, there will be cases where the token approach is still preferred.

This could be either by having a separate middleware so users can pick the appropriate one on the MIDDLEWARE setting, or a new config can be introduced (something like CSRF_PROTECTION_STRATEGY = "modern" or "legacy") and then the appropriate algorithm is applied on the middleware.

Migration

How to migrate current codebases to the new approach? One way would be would be to introduce the new algorithm but developers would have to manually change it if they want. For new projects (via startproject) the modern approach could be the default?

[github-actions]

Thank you feliperalmeida for sharing your idea! We have a lot of them so please be patient. You can see the current queue here.

Community instructions

For commenters, please use the emoji reactions on the issue to express support, and/or concern easily. Please use the comments to ask questions or contribute knowledge about the idea. It is unhelpful to post comments of "I'd love this" or "What's the state of this?"

Reaction Guide

• 👍 This is something I would use
• 👎 This is something that would cause problems for me or Django
• 😕 I’m indifferent to this
• 🎉 This is an easy win

[knyghty]

I voted yes but from the OWASP cheat sheet they still suggest using this as a defense in depth technique, not as a primary method, and for this they still suggest using tokens. So I don't think we should really give the option to choose one or the other, we always need to be using tokens or we're not doing justice to our "secure by default" design philosophy. So I would like to see this but I disagree with a lot of the intentions behind it since in my view you would still have the same developer friction here.

[feliperalmeida]

Thanks for your feedback. I linked above the long discussion about using Fetch Metadata as a primary protection mechanism against CSRF attacks on the OWASP Cheat Sheet. There's also an active PR with the implementation. OWASP maintainers are cautious when adding new things to their documents, as people may follow them without evaluating their own needs.

What we're doing here is shifting some of the CSRF protection work to the browser. Instead of the server generating and checking tokens, we rely on modern browsers to send the right Sec-Fetch-Site and Origin headers.

Tokens are really only needed for older browsers - legacy apps that still need to support IE10 or ancient Firefox/Edge. So having both options works: use the modern approach by default (less friction for most people), but let developers switch to tokens if their situation requires it. Still secure by default, just more flexible.

[knyghty]

I don't necessarily disagree with anything but I also believe in following the published guidance over a discussion that's still in progress. I'm 100% for adding this but I'm not convinced about using it as a primary method until this advice is published by OWASP.

[nickchomey]

FWIW, the OWASP PR that was linked to is being finalized right now. Just minor tweaks in wording, punctuation etc. They're on-board with supporting Fetch metadata + Origin Header fallback as a viable standalone CSRF protection, especially if you failsafe to blocking the <2% and <0.1% of browsers that don't support Fetch metadata and Origin Headers, respectively...

I don't use django, but I would love to see it, and others, support this method. I suggest proceeding with whatever discussion you need to, assuming that OWASP will publish support in due course.

[knyghty]

I think the chance that anything is implemented here before that PR is merged is fairly low so I am happy to just say that I am completely on board if that PR lands in something similar to its current state.