本页概述了设置 Referrer-Policy 以及在传入请求中使用引荐来源网址的一些最佳实践。
摘要
- 意外的跨源信息泄露会损害 Web 用户的隐私。保护性引荐来源网址政策可以提供帮助。
- 请考虑将引荐来源网址政策设置为
strict-origin-when-cross-origin。它保留了引荐来源网址的大部分实用性，同时降低了跨域泄露数据的风险。 - 请勿使用引荐来源网址来防范跨站请求伪造 (CSRF)。请改用 CSRF 令牌，并使用其他标头作为额外的安全层。
Referer 和 Referrer-Policy 基础知识
HTTP 请求可以包含可选的 Referer 标头，用于指明发出请求的来源或网页网址。Referrer-Policy 标头定义了 Referer 标头中提供的数据。
在以下示例中，Referer 标头包含发出请求的 site-one 网页的完整网址。
Referer 标头可能存在于不同类型的请求中：
- 导航请求，即用户点击链接时。
- 子资源请求，即浏览器请求网页所需的图片、iframe、脚本和其他资源。
对于导航和 iframe，您还可以使用 JavaScript 通过 document.referrer 访问这些数据。
您可以从 Referer 值中了解很多信息。例如，分析服务可能会使用这些信息来确定 site-two.example 上 50% 的访问者来自 social-network.example。但是，当完整网址（包括路径和查询字符串）在Referer中跨源发送时，可能会危及用户隐私并造成安全风险：
网址 1 至 5 包含私密信息，有时还包含敏感信息或身份信息。在不同源之间静默泄露这些信息可能会侵犯 Web 用户的隐私。
网址 6 是功能网址。如果目标用户以外的任何人收到此信息，恶意方就可以控制此用户的账号。
如需限制哪些引荐来源网址数据可用于来自您网站的请求，您可以设置引荐来源网址政策。
有哪些政策可用？它们有何不同？
您可以选择八种政策之一。根据政策，Referer 标头（和 document.referrer）中提供的数据可以是：
- 无数据（不存在
Referer标头） - 仅来源
- 完整网址：源、路径和查询字符串
某些政策旨在根据上下文（跨域请求或同源请求、请求目标是否与来源一样安全，或两者兼而有之）而表现出不同的行为。这有助于限制跨源或向安全性较低的源共享的信息量，同时在您自己的网站内保持引荐来源网址的丰富性。
下表显示了引荐来源网址政策如何限制 Referer 标头和 document.referrer 中提供的网址数据：
| 政策范围 | 政策名称 | Referer: No data | Referer：仅限来源 | 引荐来源网址：完整网址 |
|---|---|---|---|---|
| 未考虑请求上下文 | no-referrer |
check | ||
origin |
check | |||
unsafe-url |
check | |||
| 注重安全性 | 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 标头和 meta 元素都属于网页级。确定元素的有效政策的优先级顺序如下：
- 元素级政策
- 页面级政策
- 浏览器默认
示例：
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（或更严格的政策）？
您需要制定一项安全、能增强隐私保护且实用的政策。“有用”的含义取决于您希望从引荐来源网址中获得什么：
- Secure：如果您的网站使用 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收到的数据比以前少。 - 默认情况下，浏览器越来越多地使用 Referrer-Policy
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用户的隐私、更符合未来趋势。 - 缺点：您或系统用户可能需要执行更多操作。
- 优点：更明确、更注重保护
- 检查发出请求的网站是否同意将每个元素或每个请求的 Referrer-Policy 设置为
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 更改为新的默认政策不会改变此行为。
总结
采用保护性引荐来源网址政策是为用户提供更多隐私保护的好方法。
如需详细了解保护用户的不同技术，请参阅我们的安全可靠集合
资源
- 了解“同网站”和“同源”
- 新的安全标头：Referrer Policy (2017)
- MDN 上的 Referrer-Policy
- Referer 标头：MDN 上的隐私和安全问题
- Chrome 变更：Blink 意向实现
- Chrome 变更：Blink 意向发布
- Chrome 变更：状态条目
- Chrome 变更：85 Beta 版博文
- Referrer trimming GitHub 讨论串：不同浏览器的做法
- Referrer-Policy 规范
非常感谢所有审核者（尤其是 Kaustubha Govind、David Van Cleve、Mike West、Sam Dutton、Rowan Merewood、Jxck 和 Kayce Basques）的贡献和反馈。