Some browsers already implement the Referrer Policy draft <https://w3c.github.io/webappsec-referrer-policy/#referrer-policy-delivery>, which gives the developer more control over the referer HTTP header sent by the browser. Sometimes is useful to set a more private policy, like *Origin When Cross-Origin*, to prevent disclosing sensitive URL info to a third-party, like a password reset token for example.
But one can't just set the policy to *Origin When Cross-Origin*, because it will break on Safari, since Safari doesn't adhere to newest spec and defaults to no-referrer, which breaks form submits on HTTPS because of Django strict referrer check. Also, I can't imagine now why, but some developer might want to disable referer header altogether, and can easily do so by setting policy to *No Referrer*. See the rationale <https://code.djangoproject.com/wiki/CsrfProtection#StrictRefererchecking> behind strict referrer check and the code <https://github.com/django/django/blob/master/django/middleware/csrf.py#L136-L158> . Maybe Django shouldn't do do strict referrer check anymore? It's very strange to change a HTML meta tag and break everything. And break in staging specifically, because this happens only on secure requests. If Django still needs <https://code.djangoproject.com/ticket/17563#comment:2> the strict referrer check, maybe a better error message should be implemented. -- 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/3dcbec32-b180-4cba-9276-731946fdccf6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
