Chrome 的新默认引荐来源网址政策 - Strict-origin-when-cross-origin

毛德·纳尔帕斯
Maud Nalpas

开始前须知:

  • 如果您不确定“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 标头中发送

这样可以防止泄露可从完整网址的其他部分(例如路径和查询字符串)访问的私密数据。

示意图:根据政策针对跨源请求发送的引荐来源网址。
针对跨源请求发送的引荐来源网址(和 document.referrer),具体取决于政策。

例如:

跨源请求,从 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 默认值。

Chrome 屏幕截图:如何启用 chrome://flags/#reduced-referrer-granularity 标志。
启用标志。

您现在可以检查网站和后端的行为方式。

如需检测影响,您需要检查网站的代码库是否使用了引荐来源网址:通过服务器上传入请求的 Referer 标头,或通过 JavaScript 中的 document.referrer

如果您使用来自其他来源的请求的引荐来源网址(更确切地说是路径和/或查询字符串),并且此来源使用浏览器的默认引荐来源网址政策(即未设置任何政策),您网站上的某些功能可能会无法正常工作或出现异常行为。

如果这会影响您的网站,请考虑替代方案

对于针对您网站的请求,如果您使用引荐来源网址获取完整路径或查询字符串,则有以下几种选择:

  • 请为 CSRF 保护、日志记录和其他用例使用 OriginSec-fetch-Site 等替代技术和头文件。请查看引荐来源网址和引荐来源网址政策:最佳做法
  • 如果需要,您可以就具体政策与合作伙伴达成一致,且该政策对用户公开透明。 访问权限控制(当网站使用引荐来源网址向其他来源授予对其资源的特定访问权限时),可能属于这种情况,但 Chrome 进行更改后,该来源仍会在 Referer 标头(和 document.referrer)中共享。

请注意,就引荐来源网址而言,大多数浏览器都朝着类似的方向前进(请参阅 Referer and Referrer-Policy: best practices(引荐来源网址和引荐来源网址政策)中的浏览器默认设置及其变化情况。

在整个网站上实施有助于加强隐私保护的明确政策

在您的网站发出的请求中,应该发送什么 Referer,即,您应该为自己的网站设置什么政策?

即使 Chrome 考虑了相关变更,我们仍建议您立即设置明确的、有助于加强隐私保护的政策(例如 strict-origin-when-cross-origin 或更严格的政策)。

这可保护您的用户,并使您的网站在不同浏览器中的行为方式更加可预测。大多数情况下,它可以让您控制,而不是让您的网站依赖于浏览器默认设置。

如需详细了解如何设置政策,请参阅 Referrer and Referrer-Policy:最佳做法

Chrome 企业版简介

如果 IT 管理员想要在企业环境中强制执行之前的默认引荐来源网址政策 no-referrer-when-downgrade,可以使用 Chrome 企业版政策 ForceLegacyDefaultReferrerPolicy。这为企业留出了更多时间来测试和更新其应用。

在 Chrome 88 中,此政策将被移除。

发送反馈

您有要分享的反馈或要举报的内容吗?欢迎就 Chrome 推出计划的目标提供反馈,或通过 @maudnals 发 Twitter 微博。

非常感谢所有审核者做出的贡献和提供的反馈,尤其是 Kaustubha Govind、David Van Cleve、Mike West、Sam Dutton、Rowan Merewood、Jxck 和 Kayce Basques。

资源