HTTP 协议中 Referrer-Policy 详解

HTTP 协议中 Referrer-Policy 详解

一、是什么

Referrer-Policy 是一个 HTTP 响应头（也可通过 <meta> 标签或 HTML 元素属性设置），用来控制浏览器在发起后续请求时，应该把多少 Referrer 信息发送给下一个目标。

当用户从页面 A 点击链接跳转到页面 B，浏览器默认会在请求 B 的 HTTP 头里带上 Referer: <A的URL>，告诉 B"这个请求来自哪里"。Referrer-Policy 就是用来精细控制这个行为的——发多少、什么时候发、什么时候不发。

---

二、所有可选值及行为

值	行为
no-referrer	完全不发送 Referer
no-referrer-when-downgrade	HTTPS→HTTP 降级时不发（旧版浏览器默认值）
same-origin	仅同源请求才发，跨域不发
origin	只发送源（https://example.com），不带路径和查询参数
strict-origin	同 origin，但降级时不发
origin-when-cross-origin	同源发完整 URL，跨域只发 origin
strict-origin-when-cross-origin	同源发完整，跨源只发 origin，降级不发（现代浏览器默认值）
unsafe-url	永远发送完整 URL（最不安全）

---

三、三种设置方式（优先级从高到低）

1. 元素级别（最高优先级）

<a href="https://example.com" referrerpolicy="no-referrer">链接</a>
<img src="..." referrerpolicy="origin">
<iframe src="..." referrerpolicy="same-origin"></iframe>

2. meta 标签

<meta name="referrer" content="no-referrer">

3. HTTP 响应头（全局生效）

Referrer-Policy: strict-origin-when-cross-origin

---

四、strict-origin-when-cross-origin 详解

这是现代浏览器（Chrome 85+、Firefox 87+）的默认策略，判断逻辑分三步：

发起请求
  │
  ├─ 同源? ────────────────→ 发送完整 URL
  │     （协议+域名+端口完全一致）
  │
  ├─ 跨源 + 同协议安全级? ──→ 只发送 origin（不带路径和查询参数）
  │     (HTTPS→HTTPS, HTTP→HTTP)
  │
  └─ 跨源 + 降级? ──────────→ 不发送 Referer
        (HTTPS→HTTP)

具体例子

假设当前页面地址为：https://example.com/users/profile?token=abc123&page=2

场景一：同源请求 → 发完整 URL

跳转到 https://example.com/dashboard：

GET /dashboard HTTP/1.1
Referer: https://example.com/users/profile?token=abc123&page=2

同源（协议、域名、端口都相同），完整 URL 原样发送，包括路径和查询参数。

场景二：跨源 + 安全级别不降级 → 只发 origin

跳转到 https://other-site.com/article：

GET /article HTTP/1.1
Referer: https://example.com/

跨源但都是 HTTPS，安全级别没降。只发送 origin（https://example.com/），路径和查询参数被剥离。

场景三：跨源 + 降级 → 不发送

跳转到 http://insecure-site.com/page：

GET /page HTTP/1.1
（没有 Referer 头）

从 HTTPS 降级到 HTTP，传输不再加密，发送 origin 本身就有泄露风险，完全不发送 Referer。

对比总览

跳转目标	协议变化	是否跨源	实际发送的 Referer
https://example.com/dashboard	HTTPS→HTTPS	否（同源）	https://example.com/users/profile?token=abc123&page=2
https://other-site.com/article	HTTPS→HTTPS	是	https://example.com/
http://insecure-site.com/page	HTTPS→HTTP	是（且降级）	（不发送）
https://other-site.com/a?x=1	HTTPS→HTTPS	是	https://example.com/

---

五、容易忽略的细节

"同源"判定严格

同源的判定是 scheme + host + port 三者完全一致：

https://example.com  →  https://example.com:8443   跨源（端口不同）
https://example.com  →  http://example.com          跨源且降级（协议不同）

即使域名相同，只要端口或协议不同，就走跨源逻辑。

新版默认值的变化

浏览器	旧默认值	新默认值	生效时间
Chrome	no-referrer-when-downgrade	strict-origin-when-cross-origin	Chrome 85 (2020.08)
Firefox	no-referrer-when-downgrade	strict-origin-when-cross-origin	Firefox 87 (2021.03)
Edge	no-referrer-when-downgrade	strict-origin-when-cross-origin	Edge 85 (2020.08)
Safari	no-referrer-when-downgrade	strict-origin-when-cross-origin	Safari 15 (2021.09)

---

六、安全实践建议

1. 敏感 URL 参数场景

如果 URL 里带 token、session ID、用户 ID 等敏感参数（比如 ?token=abc123），默认策略下同源仍会完整泄露。如果你的重定向链里有第三方，需要主动收紧：

Referrer-Policy: same-origin

或使用 no-referrer 彻底关闭。

2. 防盗链兼容性

很多 CDN/图片服务靠 Referer 做防盗链白名单。如果策略设成 no-referrer，可能导致 Referer 校验失败、图片加载不出来。建议至少保留 strict-origin-when-cross-origin，它跨域时会发送 origin，防盗链仍能工作。

3. 服务端转发不受影响

Referrer-Policy 控制的是浏览器行为，跟服务端转发无关。服务端 HTTP client（curl、nginx proxy_pass、后端 HTTP 库）不受 Referrer-Policy 约束，需要自己在代码里显式处理 Referer 头。

4. 推荐策略

场景	推荐策略	理由
通用 Web 站点	strict-origin-when-cross-origin	浏览器默认值，平衡隐私与兼容性
高度敏感站点（后台管理、金融）	same-origin	跨域不泄露任何信息
对外 API 文档站	no-referrer-when-downgrade 或 strict-origin-when-cross-origin	便于第三方统计来源
完全不需要 Referer	no-referrer	极简隐私保护

---

七、与 Referer 请求头的关系

Referer 头是浏览器实际发送的字段，Referrer-Policy 是策略（控制浏览器怎么发）。两者关系：

• Referrer-Policy 设定了规则
• 浏览器根据规则决定 Referer 头的值
• 服务端通过读取 Referer 头来获知来源

注意拼写：HTTP 头的 Referer 少了一个 r（历史拼写错误），但 Referrer-Policy 头是正确拼写。这是 HTTP 协议里一个著名的历史遗留问题。

---

八、总结

Referrer-Policy 是浏览器层面的隐私控制开关，决定"我来自哪里"这个信息在跳转时对外暴露多少。现代浏览器默认策略（strict-origin-when-cross-origin）已经比较保守，核心逻辑是：

1. 同源 → 完整发送（充分信任）
2. 跨源同安全级 → 只发 origin（最小暴露）
3. 跨源降级 → 不发（直接掐断）

涉及敏感 URL 参数时仍需手动收紧为 same-origin 或 no-referrer。