3

Same origin policy is an important part of the security model so it is "on" by default for most things, but for the referer it does not seem to be so. The default for browsers seem to be no-referrer-when-downgrade which in practice is close to "always on" I suppose as everyone uses TLS.

Probably same-origin would be a more secure choice since it won't leak your URL's to the 3d party?

So I am wondering if there is any good reason for that?

My guess it is either too important for advertising or just was historically so and no one wants to change it.

Ilya Chernomordik
  • 2,197
  • 1
  • 21
  • 36

1 Answers1

3

Referer is a really old HTTP request header which is much much older than the idea of a Referrer Policy. In fear of breaking things the default behavior is the traditional one, i.e. nearly always on. Keeping the old default even if it is considered bad is a theme which can be seen with many security and privacy improvements in web development, for example with Content-Security-Policy (default: allow everything, which makes XSS possible) or the Cookie flags Secure (default insecure), HttpOnly (default: can be read from JavaScript, thus making session stealing using XSS possible), SameSite (insecure default helps with CSRF) etc.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • 1
    I really hope these strategies should be revised and we should gradually switch to secure by default. If it will break some old sites that are not maintained, well, we have to pay something for security, it's not free unfortunately. And that is not a too high price in my opinion, but I guess all those who control the standards disagree... – Ilya Chernomordik Nov 21 '18 at 08:13
  • "Keeping the old default even if it is considered bad" absolutely correct, especially when you consider they even keep the misspelling of "Referrer" in the header name for fear of breaking things. – Nexus Sep 10 '21 at 03:26