3 ms·

Indeed. With https there is no good reason to not have a hard dependency on the origin/referrer header to enforce same-site restrictions.

• bawolff 6y ago
  Even with https, people can have privacy extensions that mess with referrers. I wouldn't consider referer 100% reliable and origin header isn't always sent for all request types.
  • namibj 6y ago
    Blocking same-site referer beyond stripping the path is something where I'd draw the line to protect the user against CSRF attacks. Do you have any evidence for a modern browser sending a harmful referer or allowing sending of one?
    • nulbyte 6y ago
      Firefox can be configured[1] to never send the header or always send the target URL as the header. [1]: https://wiki.mozilla.org/Security/Referrer https://wiki.mozilla.org/Security/Referrer
      • namibj 6y ago
        Interesting. Especially the latter, considering that even the RFC [0] mentions it's usage for CSRF protection. This seems to be about as harsh as reasonable without breaking CSRF protection: network.http.sendRefererHeader=1 network.http.referer.trimmingPolicy=2 network.http.referer.XOriginPolicy=2 [0]: https://tools.ietf.org/html/rfc7231#section-5.5.2 https://tools.ietf.org/html/rfc7231#section-5.5.2
        • bawolff 6y ago
          Sure, but there is a reason why everyone uses tokens to fix csrf and not referrer.