3 ms·

If a browser is too old to send either the Sec-Fetch-Site header or the Origin header, it will probably ignore Referrer-Policy and always set the Referer header

by kijin 1y ago

If a browser is too old to send either the Sec-Fetch-Site header or the Origin header, it will probably ignore Referrer-Policy and always set the Referer header, which contains the origin. So I wonder why the author didn't consider falling back to the Referer header, instead of relying on an unrelated feature like TLS 1.3. Checking the referrer on dangerous (POST) requests was indeed considered one way to block CSRF back in the day. Assuming all your pages are on the same https origin, is there an edge case that affects Referer but not the Origin header?

nchmy 1y ago
Caniuse.com shows both origin and referer headers have 96.3% support, with Sec-Fetch-Site not far behind at 94.2. So it's probably a moot point. Ive read in various places though that referer has all sorts of issues, gotchas etc such that it isn't really a reliable way of doing this. https://security.stackexchange.com/questions/158045/is-checking-the-referer-and-origin-headers-enough-to-prevent-csrf-provided-that https://security.stackexchange.com/questions/158045/is-check...
- kijin 1y ago
  Caniuse.com looks wrong in this case. It marks old versions of Internet Explorer and Android browser as either unknown or not supporting Referer, when in fact they only lacked support for hiding the Referer in potentially insecure situations. That's the point I was trying to make above. Even old browsers send it, even when they shouldn't. This behavior is uncontrollable, even by potential attackers. A missing Referer header probably doesn't mean much one way or another. But you can at least block requests with Referer pointing to URLs outside of your origin. This fallback would seem preferable to the fail-open policy described in the article (request always allowed if neither Sec-Fetch-Site nor Origin headers are present).

3 ms·

If a browser is too old to send either the Sec-Fetch-Site header or the Origin header, it will probably ignore Referrer-Policy and always set the Referer header

by kijin 1y ago

nchmy 1y ago
Caniuse.com shows both origin and referer headers have 96.3% support, with Sec-Fetch-Site not far behind at 94.2. So it's probably a moot point. Ive read in various places though that referer has all sorts of issues, gotchas etc such that it isn't really a reliable way of doing this. https://security.stackexchange.com/questions/158045/is-checking-the-referer-and-origin-headers-enough-to-prevent-csrf-provided-that https://security.stackexchange.com/questions/158045/is-check...
- kijin 1y ago
  Caniuse.com looks wrong in this case. It marks old versions of Internet Explorer and Android browser as either unknown or not supporting Referer, when in fact they only lacked support for hiding the Referer in potentially insecure situations. That's the point I was trying to make above. Even old browsers send it, even when they shouldn't. This behavior is uncontrollable, even by potential attackers. A missing Referer header probably doesn't mean much one way or another. But you can at least block requests with Referer pointing to URLs outside of your origin. This fallback would seem preferable to the fail-open policy described in the article (request always allowed if neither Sec-Fetch-Site nor Origin headers are present).