此页面由 Cloud Translation API 翻译。

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

Maud Nalpas

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

摘要

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

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

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

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

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

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

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

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

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

带有路径的网址，对应不同的隐私和安全风险。 — 使用完整网址会影响用户隐私和安全性。

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

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

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

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

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

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

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

可
包含在引荐来源网址标头和 document.referrer 中。 — 引荐来源网址数据示例。

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

下表显示了引荐来源网址政策如何限制可用的网址数据从 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 月

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

浏览器	默认`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`，只是有一些特定的区别。请参阅 <ph type="x-smartling-placeholder"></ph> 阻止跟踪防范跟踪了解详情。

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

目标：明确设置增强隐私保护的政策，例如 strict-origin-when-cross-origin（或更严格的政策）。

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

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

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

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 已发送。

Chrome 开发者工具的 Network 面板的屏幕截图，其中显示了 Referer 和 Referrer-Policy。 — </ph> Chrome 开发者工具的**Network** 面板，其中包含已选择的请求。

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

我们强烈建议您明确设置增强隐私保护的政策，例如 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 对新默认政策的变更不会改变此行为

总结

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

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

资源

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

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

摘要

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

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

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

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

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

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

为什么要“明示”？

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

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

示例：元素级政策

示例：请求级政策

您还应考虑哪些因素？

传入请求的最佳做法

保护用户的数据

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

Referer 的替代方案

如果您只需要

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

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

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

记录和调试

付款

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

总结

资源

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

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

`Referer` 的替代方案