I just recently posted on the same issue: - https://groups.google.com/forum/#!topic/django-developers/6kUiODYObnU I definitely would like to see some change to make communicating between trusted subdomains easier. In my case it's *https://example.com* posting data to *https://api.example.com* which currently fails csrf referer validation when using a secure (https) site.
*My thoughts on the proposed fix:* I don't have any issues with validating against the CSRF_COOKIE_DOMAIN. I would like to say I'll always own my subdomains, but who knows, that could change in the future and that may not be everyone else's same opinion. I have worked with other companies that subdomains were passed off to different organizations within the company so all sites technically didn't have the same owner. Yes, we should trust other orgs in our same company, but the point is, the root owner of *https://example.com* was not in fact the owner of all subdomains. In this case, I wouldn't want CSRF_COOKIE_DOMAIN checking, but instead a more explicit approach (see below). The other thought here would be to add an additional setting that more be explicit than *CSRF_COOKIE_DOMAIN*. Instead, add a new setting, something like *CSRF_WHITELIST_ORIGINS,* that explicitly calls out which origins are legit. This would handle the case better than the "one-size-fits-all" CSRF_COOKIE_DOMAIN matching. Inside CSRF_WHITELIST_ORIGINS you can define wildcards if you'd like to do the same thing as the proposed change <https://github.com/django/django/pull/4337>, bit it's more explicit on your intentions for the behavior that you'd expect. *Match all subdomains example:* CSRF_WHITELIST_ORIGINS = ['*.example.com'] OR CSRF_WHITELIST_ORIGINS = ['.example.com'] *More explicit whitelisting:* CSRF_WHITELIST_ORIGINS =[ 'api.example.com', 'developers.example.com' ] Security should always more explicit than implicit IMHO, but just to be clear, I am in big favor of a change as I need if for my sites and there are too many hacky solutions [1][2][3][4] that currently get around this by manually changing the *request.META['HTTP_REFERER']*. Eeeek! Troy [1] https://github.com/ottoyiu/django-cors-headers/blob/master/corsheaders/middleware.py#L26 [2] https://groups.google.com/d/msg/django-developers/6kUiODYObnU/1wqxBqFP8UQJ [3] http://zachsnow.com/#!/blog/2012/django-subdomains-csrf-and-https/ [4] http://bash-shell.net/blog/2014/aug/16/django-cors-and-csrf-validation/ On Thursday, March 19, 2015 at 10:50:05 AM UTC-6, Matt Robenolt wrote: > > Ticket and patch have been submitted regarding this: > > https://code.djangoproject.com/ticket/24496 > https://github.com/django/django/pull/4337 > > Since this is related to CSRF and technically weakening the strictness of > the Referer check, Tim Graham suggested soliciting feedback here to get > more eyeballs and feedback. > > Please let me know if there's more context needed that can be added to the > ticket. > > My tl;dr is that Django should allow a Referer match across a subdomain, > and not exactly matching `request.get_host()` since cookies are allowed to > be set on subdomains as well. This is similar in vain to ALLOWED_HOSTS, > except Django would purely validate against the CSRF_COOKIE_DOMAIN. > > Thanks. <3 > -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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/c14fdc37-f8cb-4722-8a6b-d4dc3806713f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
