引荐来源网址和引荐来源网址政策最佳实践

本页面简要介绍了一些关于设置引荐来源网址政策的最佳做法 在传入请求中使用引荐来源网址。

摘要

• 意外的跨源信息泄露会损害 Web 用户的保护隐私。答 保护性引荐来源网址政策会有所帮助。
• 考虑将引荐来源网址政策设置为 strict-origin-when-cross-origin。它 可保留引荐来源网址的大部分实用性，同时降低 跨源泄露数据的问题
• 请勿将引荐来源网址用于跨网站请求伪造 (CSRF) 防护。使用 CSRF 令牌 和其他标头，作为一道额外的安全保障。

。 <ph type="x-smartling-placeholder">

引荐来源网址和引荐来源网址政策基础知识

HTTP 请求可以包含可选的 Referer 标头， ，用于表示请求的来源或网页网址。通过 Referrer-Policy 标题 定义 Referer 标头中提供哪些数据。

在以下示例中，Referer 标头包含 site-one 上发送请求的网页。

<ph type="x-smartling-placeholder">

</ph>

Referer 标头可能存在于不同类型的请求中：

• 当用户点击链接时，发出导航请求。
• 当浏览器请求图片、iframe、脚本和 网页所需的其他资源

对于导航和 iframe，您还可以使用 document.referrer。

您可以从 Referer 值中学到很多东西。例如，分析服务 据此判断，在site-two.example上，有 50% 的访问者来自 social-network.example起。但当完整网址（包括路径和 查询字符串，通过 Referer 跨源发送，可能会危及用户 和带来安全风险：

<ph type="x-smartling-placeholder">

</ph>

网址 1 到 5 包含隐私信息，有时包含敏感信息或 身份信息在源站之间静默泄露这些信息可能会泄露 Web 用户的保护隐私。

网址 6 是功能网址。如果任何人 非预期用户会收到该响应，恶意行为者可以控制 。

要限制哪些引荐来源网址数据可用于来自您网站的请求， 您可以设置引荐来源网址政策。

有哪些适用的政策？它们有何不同？

您可以从八项政策中选择一项。根据具体政策 Referer 标头（和 document.referrer）中的可用参数可以是：

• 无数据（不存在 Referer 标头）
• 仅 origin
• 完整网址：源、路径和查询字符串

。 <ph type="x-smartling-placeholder">

</ph>

某些政策会根据具体情况采用不同的行为方式： 跨域请求还是同源请求，无论请求目的地是 或同时指定两者这有助于限制 在多个源之间共享或与安全性较低的源共享，同时保持其丰富性 来自您自己的网站中

下表显示了引荐来源网址政策如何限制可用的网址数据 从 Referer 标头和 document.referrer 中获取：

政策范围	政策名称	引荐来源网址：无数据	引荐来源网址：仅限源	引荐来源网址：完整网址
不考虑请求上下文	no-referrer	检查
	origin		检查
	unsafe-url			检查
注重安全	strict-origin	从 HTTPS 到 HTTP 的请求	从 HTTPS 到 HTTPS 或从 HTTP 到 HTTP 的请求
	no-referrer-when-downgrade	从 HTTPS 到 HTTP 的请求		从 HTTPS 到 HTTPS 或从 HTTP 到 HTTP 的请求
注重隐私保护	origin-when-cross-origin		跨源请求	同源请求
	same-origin	跨源请求		同源请求
注重隐私和安全	strict-origin-when-cross-origin	从 HTTPS 到 HTTP 的请求	跨源请求 从 HTTPS 到 HTTPS 或从 HTTP 转换为 HTTP	同源请求

MDN 提供了完整的政策和行为列表 示例。

以下是设置引荐来源网址政策时需要注意的事项：

• 将 scheme 纳入考虑范围的所有政策（HTTPS 与 HTTP） （strict-origin、no-referrer-when-downgrade和 strict-origin-when-cross-origin）处理来自一个 HTTP 源的请求， 与从 HTTPS 来源到另一个 HTTP 来源的请求相同 HTTPS 源，即使 HTTP 安全性较低。这是因为对于这些 政策时，重要的是是否会进行安全性降级；那个 即请求可以将来自加密源的数据公开给未加密的 一种，如 HTTPS → HTTP 请求HTTP → HTTP 请求 因此不会降级
• 如果请求是 same-origin，则意味着 scheme（HTTPS 或 HTTP）是 因此不会进行安全降级

浏览器中的默认引荐来源网址政策

截至 2021 年 10 月

如果未设置引荐来源网址政策，浏览器将使用其默认政策。

设置引荐来源网址政策的最佳做法

您可以通过多种方式为您的网站设置引荐来源网址政策：

• 作为 HTTP 标头
• 在您的 HTML
• 通过 JavaScript 按请求

您可以为不同的页面、请求或元素设置不同的政策。

HTTP 标头和元元素都是网页级的。广告资源单元的 确定元素的有效政策的方法如下：

1. 元素级政策
2. 网页级政策
3. 浏览器默认设置

示例：

index.html：

<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />

使用 no-referrer-when-downgrade 政策请求图片， 此页面中的子资源请求遵循strict-origin-when-cross-origin 政策。

如何查看引荐来源网址政策？

securityheaders.com 可帮助您确定 政策。

您还可以使用 Chrome、Edge 或 Firefox 中的开发者工具， 用于特定请求的引荐来源网址政策。在撰写本文时，Safari 不会显示 Referrer-Policy 标头，但会显示Referer 已发送。

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder">

您应该为您的网站设置哪项政策？

我们强烈建议您明确设置增强隐私保护的政策，例如 strict-origin-when-cross-origin（或更严格的值）。

为什么要“明示”？

如果未设置引荐来源网址政策，系统将使用浏览器的默认政策 - 事实上，网站通常采用的这一政策 采用浏览器的默认设置。但这并不理想，因为：

• 不同的浏览器有不同的默认政策，因此，如果您依赖浏览器， 默认值，您的网站将无法跨浏览器运行。
• 浏览器采用了更严格的默认值，例如 strict-origin-when-cross-origin 以及引荐来源网址移除等机制 跨域请求明确选择接受可加强隐私保护的政策 。

为什么选择 strict-origin-when-cross-origin（或更严格的值）？

您需要安全、可加强隐私保护的实用政策。什么“有用” 的意思取决于您希望从引荐来源网址中得到什么：

• 安全：如果您的网站使用的是 HTTPS（否则，请将其设为 优先级），并且不希望自己的网站网址泄露 非 HTTPS 请求由于网络上的任何人都可以看到这些信息，因此信息泄露会 让您的用户面临中间人攻击。政策 no-referrer-when-downgrade、strict-origin-when-cross-origin、no-referrer、 和 strict-origin 可解决此问题。
• 增强隐私保护：对于跨源请求，请使用 no-referrer-when-downgrade 共享完整网址，这可能会导致隐私问题。 strict-origin-when-cross-origin 和 strict-origin 仅共享来源， 而 no-referrer 完全不共享任何内容。这样您就可以获得 strict-origin-when-cross-origin、strict-origin和no-referrer作为 增强隐私的选项
• 有用：no-referrer 和 strict-origin 绝不会分享完整网址，即使 。如果您需要完整网址，请strict-origin-when-cross-origin 是更好的选择

所有这些都意味着，strict-origin-when-cross-origin 通常是 明智的选择。

示例：设置 strict-origin-when-cross-origin 政策

index.html：

<meta name="referrer" content="strict-origin-when-cross-origin" />

或服务器端，例如在 Express 中：

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

如果 strict-origin-when-cross-origin（或更严格的场景）不能满足您的所有用例，该怎么办？

在这种情况下，请采用渐进式方法：设置如下保护措施： strict-origin-when-cross-origin，如果需要， 用于特定请求或 HTML 元素的宽容政策。

示例：元素级政策

index.html：

<head>
  <!-- document-level policy: strict-origin-when-cross-origin -->
  <meta name="referrer" content="strict-origin-when-cross-origin" />
  <head>
    <body>
      <!-- policy on this <a> element: no-referrer-when-downgrade -->
      <a src="…" href="…" referrerpolicy="no-referrer-when-downgrade"></a>
      <body></body>
    </body>
  </head>
</head>

Safari/WebKit 可能会对 document.referrer 或 Referer 标头设置上限 跨网站请求。 查看详细信息。

示例：请求级政策

script.js：

fetch(url, {referrerPolicy: 'no-referrer-when-downgrade'});

您还应考虑哪些因素？

您的政策应取决于您的网站和使用情形，具体由您自己决定 团队和公司。如果某些网址包含身份数据或敏感数据， 设置保护措施。

传入请求的最佳做法

下面介绍了一些指南，介绍了当网站使用引荐来源网址为 传入请求。

保护用户的数据

Referer可以包含私密数据、个人数据或身份数据，因此请务必 您就会像这样处理它。

传入的引荐来源网址可能会发生变化 {referer-can-change}

使用传入的跨源请求中的引荐来源网址会有一些限制：

• 如果您无法控制请求发出器的实现， 并假设您的 Referer 标头（和 document.referrer） 接收。请求发出器可能会决定改用 no-referrer 政策 也可以遵守比其内容更严格的政策 。这意味着，您从 Referer 收到的数据比以前要少。
• 浏览器越来越多地使用引荐来源网址政策 strict-origin-when-cross-origin 默认情况。也就是说，您现在可能只会收到源，而不是 完整的引荐来源网址（在传入的跨源请求中，如果发件人网站） 未设置政策。
• 浏览器可能会改变其管理 Referer 的方式。例如，某些浏览器 开发者可能会决定始终在跨源中削减对源的引荐来源网址 子资源请求，以保护用户隐私。
• Referer 标头（和 document.referrer）包含的数据可能多于 所需的资源。例如，在您只想知道 请求是跨源请求

Referer 的替代方案

如果出现以下情况，您可能需要考虑采用替代方案：

• 您网站的一项基本功能就是使用 跨域请求
• 您的网站在 跨域请求当请求发出器更改其设置 政策或未设置政策且浏览器默认政策已更改时 （例如在 Chrome 85 中）。

要定义替代方法，请先分析您使用的引荐来源网址的哪一部分。

如果您只需要

• 如果您在拥有网页顶级访问权限的脚本中使用引荐来源网址， 您可以改用 window.location.origin。
• 标头（如果有） Origin和 Sec-Fetch-Site 可为您提供 Origin 或说明相应请求是否为跨源请求， 可能正是您需要的。

如果您需要网址的其他元素（路径、查询参数...）

• 请求参数可以适用于您的用例， 解析引荐来源网址。
• 如果您在拥有网页顶级访问权限的脚本中使用引荐来源网址， window.location.pathname 可以作为替代方案。仅提取路径 部分，并将其作为参数进行传递，这样任何可能敏感的 不会传递网址参数中的信息。

如果您无法使用以下替代方案：

• 检查您能否更改系统，预期发出请求发出器 （例如 site-one.example）来明确设置您需要的信息， 特定配置
  • 优点：对于 site-one.example 用户，更明确，更保护隐私， 更加适应未来需求。
  • 缺点：您可能需要完成更多的工作，或需要系统用户完成更多工作。
• 检查发出该请求的网站是否可能同意设置 no-referrer-when-downgrade 的每个元素或每个请求的引荐来源网址政策。
  • 缺点：对于 site-one.example 用户，隐私保护力度可能较低； 可能并非所有浏览器都支持。

跨网站请求伪造 (CSRF) 防护

请求发出器始终可以通过设置 no-referrer 政策，恶意行为者甚至可以仿冒引荐来源网址。

使用 CSRF 令牌 作为您的主要保护措施。如需额外保护，请使用 SameSite 和 而非 Referer，请使用如下标头： Origin （适用于 POST 和 CORS 请求）和 Sec-Fetch-Site （如果可用）。

记录和调试

请务必保护用户的或敏感数据，而这可能是 Referer。

如果仅使用源站，请检查是否可以使用 Origin 标头为 。这可能会为您提供调试所需的信息 而无需解析引荐来源网址。

付款

付款服务机构可能依赖于传入请求的 Referer 标头 安全检查。

例如：

• 用户在 online-shop.example/cart/checkout 上点击 Buy 按钮。
• online-shop.example 重定向到 payment-provider.example 以管理 交易。
• payment-provider.example 对照列表检查此请求的 Referer 商家设置的允许的 Referer 值中的 1 个。如果与上述任何一项都不匹配 条目，则 payment-provider.example 会拒绝该请求。如果是 匹配，用户可以继续进行交易。

付款流程安全检查的最佳做法

作为付款服务机构，您可以使用Referer作为与某些 攻击。不过，Referer 标头本身并不是 支票。发出请求的网站无论其是否为合法商家，都可以设置 no-referrer 政策，此政策使得 Referer 信息无法提供给 付款服务机构。

查看 Referer 可能有助于付款服务机构捕捉到 未设置“no-referrer”政策。如果您使用 Referer 作为初步检查：

• 不要指望 Referer 始终存在。如果有，请勾选 只针对它可以包含的最少数据，即来源。
  • 设置允许的 Referer 值列表时，请确保仅包含 没有路径
  • 例如，online-shop.example 允许的 Referer 值应为 online-shop.example，而不是 online-shop.example/cart/checkout。根据预期 完全没有 Referer，或者使用仅发出请求的 Referer 值 就可以防止 关于商家的Referrer-Policy。
• 如果 Referer 不存在，或存在且存在您的基本 Referer 源 就可以进行另一种更可靠的验证 方法。

为了更可靠地验证付款，请让请求提出者 对请求参数进行哈希处理，同时确保请求的唯一键。 然后，付款服务机构可以计算您一方的相同哈希值 并仅接受与您的计算相符的请求

如果 HTTP 商家网站没有引荐来源网址，Referer 会发生什么情况 政策会重定向到 HTTPS 付款服务机构？

向 HTTPS 付款服务机构发送的请求中看不到任何 Referer，这是因为 大多数浏览器使用 strict-origin-when-cross-origin 或 如果网站未设置政策，则默认为 no-referrer-when-downgrade。 Chrome 对新默认政策的变更 不会改变此行为

总结

保护性引荐来源网址政策是为用户提供更多隐私保护的好方法。

如需详细了解保护用户的各种技术，请参阅我们的 安全可靠的数据收集

资源

• 了解“same-site”和“same-origin”
• 新的安全标头：引荐来源网址政策 （2017 年）
• 关于 MDN
• 引荐来源网址：有关隐私权和安全问题 MDN
• Chrome 变更：Blink intent 至 实现
• Chrome 变更：Blink intent 至 轮船
• Chrome 更改：状态条目
• Chrome 变更：85 测试版 blogpost
• 引荐来源网址修剪 GitHub 线程：有哪些不同的浏览器 正确做法
• 引荐来源网址政策规范

衷心感谢所有评价者的贡献和反馈，尤其是 Kaustubha Govind， David Van Cleve、Mike West、Sam Dutton、Rowan Merewood、Jxck 和 Kayce Basques。