Opened 9 years ago
Closed 9 years ago
#25334 closed New feature (fixed)
Check CSRF Referer against CSRF_TRUSTED_ORIGINS
Reported by: | Joshua Kehn | Owned by: | Joshua Kehn |
---|---|---|---|
Component: | CSRF | Version: | dev |
Severity: | Normal | Keywords: | csrf |
Cc: | Carl Meyer | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
Django's CSRF implementation (when used over HTTPS) validates that the Referer header matches the current host (i.e. that the request is coming from the same domain).
There are cases where it is reasonable to allow non-same-origin CSRF-protected requests. Ticket #24496 (which also contains some discussion relevant to this ticket) has a pull request to allow any host that matches CSRF_COOKIE_DOMAIN
past the Referer check; this takes care of the common subdomain cases.
But there also cases where a totally separate domain may be allowed to make POST
(etc) requests to an API via CORS, and CORS headers can be configured to allow XHR requests from that external domain to send cookies to the API (including the CSRF cookie). But at the moment such a technique falls afoul of the Referer checking, and the only way to bypass it is by monkeypatching the request headers (that's what https://github.com/ottoyiu/django-cors-headers does).
This ticket proposes adding a CSRF_TRUSTED_ORIGINS
setting, which can be set to a list of hosts that should be considered valid Referers for the purposes of CSRF checking.
Attachments (1)
Change History (9)
comment:1 by , 9 years ago
Status: | new → assigned |
---|
comment:2 by , 9 years ago
Description: | modified (diff) |
---|
comment:4 by , 9 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:5 by , 9 years ago
Description: | modified (diff) |
---|
by , 9 years ago
Attachment: | 24496.diff added |
---|
comment:6 by , 9 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
FYI, there is no need to attach a patch to the ticket when you've also sent a pull request.
I'm updating the description here to try to more clearly describe the motivation for _this_ feature, why it is useful in addition to #24496. Please let me know if you think the new description is lacking.