开始之前：
- 如果您不确定“网站”和“源”之间的区别，请查看了解“同网站”和“同源”。
- 由于规范中最初的拼写错误，
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，Referer 标头中的数据也可以通过 JavaScript 使用 document.referrer 进行访问。
直到最近，
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：Referer: https://site-one.example/stuff/detail?tag=red 。 - 使用
strict-origin-when-cross-origin：Referer: 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：Referer: https://site-one.example/stuff/detail?tag=red
影响是什么？
根据与其他浏览器的讨论以及 Chrome 在 Chrome 84 中进行的实验，用户可见的中断预计会受到限制。
依赖于完整引荐来源网址的服务器端日志记录或分析可能会受到该信息粒度降低的影响。
您需要做些什么？
Chrome 计划在 85 中开始推出新的默认引荐来源网址政策（测试版为 2020 年 7 月，稳定版为 2020 年 8 月）。请参阅 Chrome 状态条目 中的状态。
了解并检测更改
如需了解新的默认政策在实践中的变化，您可以查看此 演示。
您还可以使用此演示来检测在您运行的 Chrome 实例中应用了哪些政策。
测试更改，并确定这是否会影响您的网站
您现在可以从 Chrome 81 开始试用此更改：在 Chrome 中访问 chrome://flags/#reduced-referrer-granularity 并启用该标志。启用此标志后，所有没有政策的网站都将使用新的 strict-origin-when-cross-origin 默认政策。
现在，您可以检查网站和后端的行为方式。
检测影响的另一项工作是检查网站的代码库是否使用引荐来源网址，无论是通过服务器上收到的请求的 Referer 标头，还是通过 JavaScript 中的 document.referrer。
如果您使用来自其他源 的请求的引荐来源网址（更具体地说是路径和/或查询字符串）访问您的网站，并且此源使用浏览器的默认引荐来源网址政策（即未设置任何政策），则您网站上的某些功能可能会中断或行为异常。
如果这会影响您的网站，请考虑替代方案
如果您使用引荐来源网址访问您网站的请求的完整路径或查询字符串，则有以下几种选择：
- 使用替代技术和标头（例如
Origin和Sec-fetch-Site）进行 CSRF 保护、日志记录和其他用例。请查看 Referer 和 Referrer-Policy：最佳实践。 - 如有需要，您可以与合作伙伴就特定政策达成一致，并向用户公开。
访问权限控制（网站使用引荐来源网址向其他来源授予对其资源的特定访问权限）可能就是这种情况，不过随着 Chrome 的更改，来源仍会在
Referer标头（和document.referrer中）共享。
请注意，大多数浏览器在引荐来源网址方面都朝着类似的方向发展（请参阅浏览器 默认政策及其演变，请参阅Referer 和 Referrer-Policy：最佳实践）。
在整个网站中实施明确的增强隐私保护的政策
在您的网站发起的 请求中应发送哪些 Referer，也就是说，您应该为网站设置哪些政策？
即使考虑到 Chrome 的更改，现在设置明确的增强隐私保护的政策 （例如 strict-origin-when-cross-origin 或更严格的政策）也是一个不错的做法。
这样可以保护您的用户，并使您的网站在不同浏览器中的行为更加可预测。最重要的是，您可以控制网站，而不是让网站依赖于浏览器默认政策。
如需详细了解如何设置政策，请查看 Referer 和 Referrer-Policy：最佳实践。
关于 Chrome 企业版
Chrome 企业版政策
ForceLegacyDefaultReferrerPolicy
适用于希望在企业环境中强制使用之前的默认引荐来源网址政策
no-referrer-when-downgrade的 IT 管理员。这让企业有更多时间来测试和更新其应用。
此政策将在 Chrome 88 中移除。
发送反馈
您有反馈要分享或有内容要报告吗？请分享您对 Chrome 计划发布的反馈，或在 Twitter 上向 @maudnals 提问。
非常感谢所有审核人员的贡献和反馈，特别是 Kaustubha Govind、David Van Cleve、Mike West、Sam Dutton、Rowan Merewood、Jxck 和 Kayce Basques。