Why is the CSRF template context processor hardcoded?

195 views
Skip to first unread message

Aymeric Augustin

unread,
Sep 20, 2014, 5:16:24 PM9/20/14
to django-d...@googlegroups.com
Hello,

I’m wondering why django.template.context defines:

# We need the CSRF processor no matter what the user has in their settings,
# because otherwise it is a security vulnerability, and we can't afford to leave
# this to human error or failure to read migration instructions.
_builtin_context_processors = ('django.core.context_processors.csrf',)

and then forcibly prepends it to settings.TEMPLATE_CONTEXT_PROCESSORS.

If the template context processor was missing, {% csrf_token %} wouldn’t output anything in templates. Then it would be impossible to submit forms, but that would be a bug.

The CSRF context processor even has a branch that returns NOTPROVIDED. {% csrf_token %} specifically tests for this case and doesn’t output anything when it happens.

So I fail to find the security vulnerability the comment talks about. I didn’t find the answer in:
- https://github.com/django/django/commit/8e70cef9b67433edd70935dcc30c621d1e7fc0a0
- https://code.djangoproject.com/ticket/9977
- https://code.djangoproject.com/wiki/CsrfProtection

Does anyone remembers the reasoning?

Thanks,

--
Aymeric.



Russell Keith-Magee

unread,
Sep 20, 2014, 6:42:40 PM9/20/14
to Django Developers
Hi Aymeric,

As I recall, the reasoning was:

a) CSRF should almost always be on anyway

b) The cost of having the CSRF token in place if you actually aren't using CSRF was pretty low

c) Template documentation essentially says "put {% csrf_token %} in your template always; if it's hardcoded, there's no "if CSRF is enabled" question required.

d) If templates are being distributed as part of the third party package, you want to make sure they work out of the box

e) We didn't want have two moving parts to enable it (middleware *and* context processor).

Russ %-)



--
Aymeric.



--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9EFBA6B8-F6F3-4DD4-9911-2B13906BEC2C%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Luke Plant

unread,
Oct 2, 2014, 5:10:26 AM10/2/14
to django-d...@googlegroups.com
Hi Aymeric,

I agree there is no security vulnerability, because the middleware
defaults to safe. That comment should be fixed.

The hard-coding was put there basically to make it easier to use, first
for the case of simple migration instructions when this CSRF protection
was introduced/changed, and secondly for the ongoing case - anything we
could do to streamline the instructions and minimise things that go
wrong was considered a good thing, so that we avoid the whole "just
disable the CSRF middleware" temptation.

Luke
"Cross country skiing is great if you live in a small country."
(Steven Wright)

Luke Plant || http://lukeplant.me.uk/
Reply all
Reply to author
Forward
0 new messages