开始之前：
- 如果您不确定“网站”和“来源”之间的区别，请参阅了解“同网站”和“同来源”。
- 由于规范中的原始拼写错误，
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 一直是各浏览器广泛采用的默认政策。不过，现在许多浏览器都在逐步改用可增强隐私保护的默认设置。
从 85 版开始，Chrome 计划将默认政策从 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 计划从 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 或更严格的政策。
这有助于保护您的用户，并让您的网站在不同浏览器中的行为更具可预测性。大多数情况下，它可让您掌控一切，而不是让您的网站依赖于浏览器默认设置。
如需详细了解如何设置政策，请参阅引荐来源和引荐来源政策：最佳做法。
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）提供的贡献和反馈。