准备工作:
- 如果您不确定“site”和“origin”之间的区别,请参阅了解“same-site”和“same-origin”。
- 由于规范中存在原始拼写错误,
Referer
标头缺少 R。JavaScript 和 DOM 中的Referrer-Policy
标头和referrer
拼写正确。
摘要
- 浏览器正在朝着可加强隐私保护的默认引荐来源网址政策的方向发展,以便在网站未设置政策时提供良好的回退机制。
- Chrome 计划在 85 中逐步启用
strict-origin-when-cross-origin
作为默认政策;这可能会影响依赖于其他来源的引荐来源网址值的用例。 - 这是新的默认设置,但网站仍然可以选择自己选择的政策。
- 如需在 Chrome 中试用此更改,请在
chrome://flags/#reduced-referrer-granularity
处启用该标志。您也可以查看此演示,了解更改的实际效果。 - 除了引荐来源网址政策之外,浏览器处理引荐来源网址的方式可能会发生变化,因此请留意。
具体变化及变化原因
HTTP 请求可能包含可选的 Referer
标头,该标头指示发出请求的来源或网页的网址。Referer-Policy
标头定义了 Referer
标头中可用的数据,以及目的地的 document.referrer
中的导航和 iframe 的数据。
从网站发出的请求中的 Referer
标头要发送的确切信息是由您设置的 Referrer-Policy
标头决定的。
如果未设置政策,则使用浏览器的默认设置。网站通常会遵循浏览器的默认设置。
对于导航和 iframe,您还可以使用 document.referrer
通过 JavaScript 访问 Referer
标头中显示的数据。
直到最近,no-referrer-when-downgrade
一直是各种浏览器普遍采用的默认政策。但是,现在许多浏览器都处于采用更多可增强隐私保护的默认设置的阶段。
Chrome 计划从版本 85 开始将其默认政策从 no-referrer-when-downgrade
改为 strict-origin-when-cross-origin
。
这意味着,如果未为您的网站设置政策,Chrome 将默认使用 strict-origin-when-cross-origin
。请注意,您仍然可以设置您选择的政策;此更改只会对未设置政策的网站产生影响。
此更改意味着什么?
strict-origin-when-cross-origin
提供了更多隐私保护。使用此政策时,只有源站在跨源请求的 Referer
标头中发送。
这样可以防止泄露可从完整网址的其他部分(如路径和查询字符串)访问的私密数据。
例如:
跨源请求,从 https://site-one.example/stuff/detail?tag=red 发送到 https://site-two.example/...:
- 使用
no-referrer-when-downgrade
:引荐来源网址:https://site-one.example/stuff/detail?tag=red。 - 使用
strict-origin-when-cross-origin
:引荐来源网址:https://site-one.example/。
哪些方面不会变化?
- 与
no-referrer-when-downgrade
一样,strict-origin-when-cross-origin
是安全的:当请求从 HTTPS 来源(安全)到 HTTP 来源(不安全)时,不存在引荐来源网址(Referer
标头和document.referrer
)。这样一来,如果您的网站使用 HTTPS(如果不这么做,请将其设为优先),您网站的网址不会在非 HTTPS 请求中泄露,因为网络上的任何人都可以看到这些网址,从而导致您的用户面临中间人攻击。 - 在同一源中,
Referer
标头值是完整网址。
例如:同源请求,从 https://site-one.example/stuff/detail?tag=red 发送到 https://site-one.example/...:
- 使用
strict-origin-when-cross-origin
:引荐来源网址:https://site-one.example/stuff/detail?tag=red
有何影响?
根据与其他浏览器进行的讨论以及 Chrome 自己在 Chrome 84 中运行的实验,用户可见的中断预计会受到限制。
依赖于可用完整引荐来源网址的服务器端日志记录或分析可能会因这些信息的精细程度降低而受到影响。
您需要做些什么?
Chrome 计划从 85 版开始推出新的默认引荐来源网址政策(Beta 版为 2020 年 7 月,稳定版为 2020 年 8 月)。请在 Chrome 状态条目中查看状态。
了解和检测更改
如需了解新的默认操作在实践中有哪些变化,您可以查看此演示。
您还可以使用此演示来检测在您运行的 Chrome 实例中应用的政策。
测试更改,确定这是否会影响您的网站
从 Chrome 81 开始,您已经可以试用这项变更:在 Chrome 中访问 chrome://flags/#reduced-referrer-granularity
并启用该标志。启用此标志后,所有未设置政策的网站都将使用新的 strict-origin-when-cross-origin
默认值。
您现在可以检查网站和后端的行为方式。
要检测影响,另一种方法是检查网站的代码库是否使用引荐来源网址,方法是通过服务器上传入请求的 Referer
标头或来自 JavaScript 中的 document.referrer
。
如果您使用另一个来源对您网站的请求(更具体地说是路径和/或查询字符串)的引荐来源网址,并且此来源使用浏览器的默认引荐来源网址政策(即未设置任何政策),那么网站上的某些功能可能会中断或出现不同行为。
如果这会影响您的网站,请考虑替代方案
如果您使用引荐来源网址来获取针对您网站的请求的完整路径或查询字符串,则有以下几种选择:
- 针对 CSRF 保护、日志记录和其他用例使用
Origin
和Sec-fetch-Site
等替代方法和标头。请参阅引荐来源网址和引荐来源网址政策:最佳做法。 - 如果需要,您可以就具体政策与合作伙伴达成一致,并且对用户公开透明。
访问权限控制(当网站使用引荐来源网址向其他来源授予对其资源的特定访问权限时),可能会出现这种情况。虽然 Chrome 进行了更改,但相应来源仍会在
Referer
标头(以及document.referrer
)中共享。
请注意,在涉及引荐来源网址时,大多数浏览器都在朝着类似的方向发展(请参阅引荐来源网址和引荐来源网址政策:最佳做法中的浏览器默认设置及其演变)。
针对整个网站实施可加强隐私保护的明确政策
在您的网站所发出的请求中,应发送什么 Referer
,即:您应该为您的网站设置什么政策?
即使 Chrome 发生了变化,我们也建议您立即设置明确的可加强隐私保护的政策(例如 strict-origin-when-cross-origin
或更严格的政策)。
这样可以保护您的用户,并让您的网站在不同浏览器中的行为更能预测。大多数情况下,这可让您进行控制,而不是让网站依赖于浏览器默认设置。
如需详细了解如何设置政策,请参阅 Referrer and Referrer-Policy: best practices。
Chrome 企业版简介
Chrome 企业政策 ForceLegacyDefaultReferrerPolicy
适用于想要在企业环境中强制采用之前的默认引荐来源网址政策 no-referrer-when-downgrade
的 IT 管理员。这为企业提供了更多时间来测试和更新其应用。
在 Chrome 88 中,此政策将被移除。
发送反馈
您有什么反馈要分享或要报告吗?请就 Chrome 的推出计划提供反馈,或通过 @maudnals 发帖提问。
非常感谢所有评价者的贡献和反馈,尤其是 Kaustubha Govind、David Van Cleve、Mike West、Sam Dutton、Rowan Merewood、Jxck 和 Kayce Basques。