Summary: Servers often reject requests entailing an overly long `Referer` header. Additionally, attackers can retain control over the header on `no-cors` requests and force an error when fetching a subresource which allows them to perform cache probing attacks by looking at the error event of the request.
To compensate, we plan to strip down the Referrer URL to the origin if the `Referer` header's value exceeds 4k. If the origin of Referrer still exceeds 4k, then completely remove the Referrer Header. More details: https://github.com/xsleaks/xsleaks/wiki/Browser-Side-Channels#cache-and-error-events , Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1557346 Link to standard: <https://github.com/w3c/webappsec-referrer-policy/issues/96> https://github.com/w3c/webappsec-referrer-policy/pull/122 https://github.com/whatwg/fetch/issues/903 Platform coverage: All platforms. Estimated or target release: 70 Is this feature enabled by default in sandboxed iframes? Yes. DevTools bug: No Do other browser engines implement this? Chromium: https://www.chromestatus.com/features/5648956820291584 Is this feature restricted to secure contexts? No. Web-platform-tests: https://github.com/web-platform-tests/wpt/blob/master/referrer-policy/generic/referrer-policy-test-case.sub.js -- Best regards, ===================================================== Thomas Nguyen IRC : tngu...@irc.mozilla.com Slack: tnguyen Email: tngu...@mozilla.com ===================================================== _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
