There seems to be some confusion about CORS (a hairy draft spec that is not fully implemented in any browser, and not appropriate for inclusion in Django at this time) and the "Origin" header (aka Web Origin, rfc6454).
http://tools.ietf.org/html/rfc6454 https://wiki.mozilla.org/Security/Origin http://www.w3.org/TR/access-control/#origin-request-header The Origin header defined in rfc6454 is compatible with the CORS origin header, but does not require full CORS support from the browser or the server to be useful. In my tests with Firefox and Chrome, both sent the origin header properly when making potentially state-changing cross-origin requests (both AJAX and standard form POST requests). My suggestion here is to include optional support for the Origin header as follows: - if present and null, fail the CSRF check - if present and not null, use in alongside the Referer header - if absent, keep current behavior As a general rule, if a browser sends an origin header, that value is more reliable (harder for malicious sites to manipulate, less often stripped by firewalls, less often disabled by users) than the referer header. This addition won't improve CSRF protection for older browsers, but it also won't break anything for them. For users with newer browsers, it should prevent CSRF even in cases when the CSRF token is stolen due to misconfiguration or user error. -Paul -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
