Hi Everyone,
TL;DR: This ticket was triaged to “Someday/Maybe” due to concerns over Fetch Metadata Request Headers being experimental and not supported by all browsers. I would like to address these concerns and hear them in more detail to see if we can add more protection for Django users now. I wanted to get more feedback on this ticket regarding implementing Fetch Metadata Request Headers as an additional protection against cross-origin attacks. I also want to open a discussion about improving the CSRF middleware. The feedback on this ticket was concerned about the experimental nature of the headers. I would like to know more about the concerns regarding these headers as I think they would add value to Django and would not require additional maintenance once implemented given the current status of the specification. Fetch Metadata Request Headers are a new security feature that protects against cross-origin attacks. They are to be used as a defense-in-depth feature and not as a replacement for the current CSRF protections. The spec can be found here. <https://w3c.github.io/webappsec-fetch-metadata> These headers, if set by the browser, would be checked in place of the referer header to protect against CSRF. Because these headers are only set if they are supported by the browser, their presence in the request indicates that the browser supports this feature and that the headers are accurate. If the headers are not present, the browser does not support this feature and the referer header check can be used instead. Given this, it is possible to account for browsers adopting this feature without losing backwards compatibility. The experimental status of the feature should not affect the server-side implementation as only the client-side spec is subject to change. Of the four headers, the Sec-Fetch-Site header is the only one considered unstable. This header can be set to "cross-site", "same-origin", "same-site", or "none". “None” is used to distinguish “webby” requests from those that arise from user interaction with the user agent, like opening a bookmark. Each browser may have different interactions that fall into this category. As such, the client-side specification is open to some interpretation as the feature is adopted by more browsers. However, this shouldn’t have an impact on the server-side usage of the headers. More information can be found here. <https://w3c.github.io/webappsec-fetch-metadata/#directly-user-initiated> Currently, the CSRF middleware checks the referer header as an additional protection against MITM and other attacks that can circumvent the CSRF cookie and token checks. This is done by checking that the referer is a well formed URL and that connection is over https and not http. However, this header is not included in every request which leads to false positive cases where non malicious requests may be blocked. The new Fetch Metadata Request Headers provide more information than the referer header alone which allows for finer security controls based on the request origin and the adoption of a strict resource isolation policy in addition to verifying the URL. Thank you for your thoughts! -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/315c3c13-12e2-45fc-97f7-cd39f760e916n%40googlegroups.com.
