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

Maud Nalpas
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,即:您应该为您的网站设置什么政策?

即使 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。

资源