Yes Jon, makes sense, sorry for missing that. The only HTML-only solution I see for this is to manually add rel="noreferrer" to all external links on my webapp, which is a pain. With extra backend code, one might also implement something similar to https://anon.click/ to prevent referrer leaking.
So the problem with Django strict referrer check is deeper. It introduces complexity to make secure webapps that don't leak referrer info. PS: don't know if anon.click is safe or trustable. Em sexta-feira, 4 de dezembro de 2015 16:52:26 UTC-3, Jon Dufresne escreveu: > > On Wed, Dec 2, 2015 at 10:29 AM, Flávio Junior <flavio...@gmail.com > <javascript:>> wrote: > > 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. > > Why is it unimaginable that I may want to maximize privacy for my > users? The domain my users are coming from is between me and my users. > If CSRF would work securely without any referer header (and not leak > the same data some other way), I would choose to disable it entirely. > Often the domain is enough to leak what kind of data a user was > reading or interacting with. For example, what might one assume > (rightly or wrongly) if the referer header was > "https://wikileaks.org";? > -- 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/0a8cc4a7-76c6-434a-8ccb-f6d043638d34%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
