本页面简要介绍了一些关于设置引荐来源网址政策的最佳做法 在传入请求中使用引荐来源网址。
摘要
- 意外的跨源信息泄露会损害 Web 用户的保护隐私。答 保护性引荐来源网址政策会有所帮助。
- 考虑将引荐来源网址政策设置为
strict-origin-when-cross-origin
。它 可保留引荐来源网址的大部分实用性,同时降低 跨源泄露数据的问题 - 请勿将引荐来源网址用于跨网站请求伪造 (CSRF) 防护。使用 CSRF 令牌 和其他标头,作为一道额外的安全保障。
引荐来源网址和引荐来源网址政策基础知识
HTTP 请求可以包含可选的 Referer
标头,
,用于表示请求的来源或网页网址。通过
Referrer-Policy
标题
定义 Referer
标头中提供哪些数据。
在以下示例中,Referer
标头包含
site-one
上发送请求的网页。
![包含 Referer 标头的 HTTP 请求。](https://web.developers.google.cn/static/articles/referrer-best-practices/image/http-request-including-r-9ebf692a22831.jpg?authuser=7&hl=ro)
Referer
标头可能存在于不同类型的请求中:
- 当用户点击链接时,发出导航请求。
- 当浏览器请求图片、iframe、脚本和 网页所需的其他资源
对于导航和 iframe,您还可以使用
document.referrer
。
您可以从 Referer
值中学到很多东西。例如,分析服务
据此判断,在site-two.example
上,有 50% 的访问者来自
social-network.example
起。但当完整网址(包括路径和
查询字符串,通过 Referer
跨源发送,可能会危及用户
和带来安全风险:
![带有路径的网址,对应不同的隐私和安全风险。](https://web.developers.google.cn/static/articles/referrer-best-practices/image/urls-paths-mapped-diff-5b35e579c46d7.jpg?authuser=7&hl=ro)
网址 1 到 5 包含隐私信息,有时包含敏感信息或 身份信息在源站之间静默泄露这些信息可能会泄露 Web 用户的保护隐私。
网址 6 是功能网址。如果任何人 非预期用户会收到该响应,恶意行为者可以控制 。
要限制哪些引荐来源网址数据可用于来自您网站的请求, 您可以设置引荐来源网址政策。
有哪些适用的政策?它们有何不同?
您可以从八项政策中选择一项。根据具体政策
Referer
标头(和 document.referrer
)中的可用参数可以是:
- 无数据(不存在
Referer
标头) - 仅 origin
- 完整网址:源、路径和查询字符串
![可
包含在引荐来源网址标头和 document.referrer 中。](https://web.developers.google.cn/static/articles/referrer-best-practices/image/data-can-contained-the-209ad524f7ae8.jpg?authuser=7&hl=ro)
某些政策会根据具体情况采用不同的行为方式: 跨域请求还是同源请求,无论请求目的地是 或同时指定两者这有助于限制 在多个源之间共享或与安全性较低的源共享,同时保持其丰富性 来自您自己的网站中
下表显示了引荐来源网址政策如何限制可用的网址数据
从 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>
阻止跟踪防范跟踪了解详情。
|
设置引荐来源网址政策的最佳做法
您可以通过多种方式为您的网站设置引荐来源网址政策:
您可以为不同的页面、请求或元素设置不同的政策。
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。](https://web.developers.google.cn/static/articles/referrer-best-practices/image/a-screenshot-the-network-7f0db2eae4fd4.jpg?authuser=7&hl=ro)
您应该为您的网站设置哪项政策?
我们强烈建议您明确设置增强隐私保护的政策,例如
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。