本页概述了设置引荐来源网址政策以及在传入请求中使用引荐来源网址的一些最佳做法。
摘要
- 意外的跨源信息泄露会破坏网络用户的隐私。保护性引荐来源网址政策可能会有所帮助。
- 不妨考虑将引荐来源网址政策设置为
strict-origin-when-cross-origin。它保留了引荐来源网址的大部分实用性，同时降低了跨源泄露数据的风险。 - 不要使用引荐来源网址来防范跨站请求伪造 (CSRF) 攻击。请改用 CSRF 令牌和其他标头作为一道额外的安全保障。
引荐来源网址和引荐来源网址政策基础知识
HTTP 请求可以包含可选的 Referer 标头，该标头用于指示发出请求的来源或网页网址。Referrer-Policy 标头定义 Referer 标头中提供的数据。
在以下示例中，Referer 标头包含发出请求的 site-one 上的页面的完整网址。
Referer 标头可能会出现在不同类型的请求中：
- 导航请求（当用户点击链接时）。
- 子资源请求（当浏览器请求网页所需的图片、iframe、脚本和其他资源时）。
对于导航和 iframe，您还可以使用 document.referrer 通过 JavaScript 访问这些数据。
您可以从 Referer 值中学到很多东西。例如，分析服务可能会使用它们来确定 site-two.example 上 50% 的访问者来自 social-network.example。但是，当跨源在 Referer 中发送完整网址（包括路径和查询字符串）时，可能会危及用户隐私并带来安全风险：
网址 1 到 5 包含私密信息，有时包含敏感信息或身份信息。跨源以静默方式泄露这类事件可能会危害 Web 用户的隐私。
网址 6 是功能网址。如果除目标用户以外的任何人收到此邮件，则恶意操作者可以控制此用户的帐号。
若要限制哪些引荐来源网址数据可用于来自您网站的请求，您可以设置引荐来源网址政策。
目前有哪些政策？这些政策有何不同？
您可以从 8 项政策中选择一项。Referer 标头（和 document.referrer）可提供以下数据，具体取决于政策：
- 无数据（不存在
Referer标头） - 只有 origin
- 完整网址：来源、路径和查询字符串
某些政策的行为因上下文而异：跨源请求还是同源请求，请求目的地和/或请求目的地是否安全。这有助于限制不同源站或安全性较低的源站共享的信息量，同时保持您自己网站中引荐来源网址的丰富性。
下表显示了引荐来源网址政策如何限制引荐来源网址标头和 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 提供了政策和行为示例的完整列表。
以下是设置引荐来源网址政策时需要注意的一些事项：
- 所有考虑 [HTTPS 与 HTTP] 架构（
strict-origin、no-referrer-when-downgrade和strict-origin-when-cross-origin）的政策对从一个 HTTP 来源到另一个 HTTP 来源的请求的处理方式与从 HTTPS 来源到另一个 HTTPS 来源的请求相同，尽管 HTTP 的安全性较低。这是因为对于这些政策，重要的是是否发生安全性降级；也就是说，请求是否可以将来自加密来源的数据暴露给未加密来源（如 HTTPS → HTTP 请求）。HTTP → HTTP 请求是完全未加密的，因此没有降级。 - 如果请求是同源请求，则意味着架构（HTTPS 或 HTTP）是相同的，因此安全性不会降级。
浏览器中的默认引荐来源网址政策
截至 2021 年 10 月
如果未设置引荐来源网址政策，浏览器将使用其默认政策。
| 浏览器 | 默认 Referrer-Policy / 行为 |
|---|---|
| Chrome |
默认为 strict-origin-when-cross-origin。
|
| Firefox |
默认值为 strict-origin-when-cross-origin。从 93 版开始，对于“严格跟踪保护”和“无痕浏览”用户，跨网站请求会忽略限制较宽松的引荐来源网址政策 no-referrer-when-downgrade、origin-when-cross-origin 和 unsafe-url，这意味着无论网站采用怎样的政策，系统始终会对跨网站请求删减引荐来源网址。
|
| Edge |
默认为 strict-origin-when-cross-origin。
|
| Safari |
默认值类似于 strict-origin-when-cross-origin，但存在一些特定差异。如需了解详情，请参阅
阻止反跟踪跟踪。
|
设置引荐来源网址政策的最佳做法
您可以通过多种方式为您的网站设置引荐来源网址政策：
您可以为不同的网页、请求或元素设置不同的政策。
HTTP 标头和 元元素都是网页级的。确定元素有效政策的优先级顺序如下：
- 元素级政策
- 网页级政策
- 浏览器默认设置
示例：
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。
您应该为自己的网站设置哪项政策？
我们强烈建议您明确设置有助于增强隐私权的政策，例如 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；如果可用，则使用 Origin（适用于 POST 和 CORS 请求）和 Sec-Fetch-Site 等标头（如果可用），而不是使用 Referer。
记录和调试
请务必保护可能位于 Referer 中的用户个人数据或敏感数据。
如果您只使用源站，请检查是否可以使用 Origin 标头作为替代标头。这样一来，您就可以通过更简单的方式获得进行调试所需的信息，而无需解析引荐来源网址。
付款
付款服务机构可能会依赖传入请求的 Referer 标头进行安全检查。
例如：
- 用户点击
online-shop.example/cart/checkout上的购买按钮。 online-shop.example重定向到payment-provider.example以管理交易。payment-provider.example会根据商家设置的允许Referer值列表检查此请求的Referer。如果它与列表中的所有条目都不匹配，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 商家网站重定向到 HTTPS 付款服务机构时，Referer 会怎样？
在向 HTTPS 付款服务机构发送的请求中看不到 Referer，因为如果网站未设置政策，大多数浏览器会默认使用 strict-origin-when-cross-origin 或 no-referrer-when-downgrade。Chrome 改用新的默认政策不会改变此行为。
总结
保护性引荐来源网址政策是为用户提供更多隐私的绝佳方式。
如需详细了解保护用户的不同技术，请参阅我们的安全集合
资源
- 了解“同网站”和“同源”
- 新的安全标头：引荐来源网址政策 (2017)
- MDN 上的引荐来源网址政策
- 引荐来源网址标题：MDN 的隐私和安全问题
- Chrome 变更：要实现的 Blink intent
- Chrome 变更：Blink intent 推出
- Chrome 更改：状态条目
- Chrome 变更：85 Beta 版博文
- 引荐来源网址剪辑 GitHub 线程：不同浏览器会执行的操作
- 引荐来源网址政策规范
非常感谢所有审核者做出的贡献和提供反馈，尤其是 Kaustubha Govind、David Van Cleve、Mike West、Sam Dutton、Rowan Merewood、Jxck 和 Kayce Basques。