WEB安全防护相关响应头（下）

前篇 “WEB安全防护相关响应头（上）”中，我们分享了 X-Frame-Options、X-Content-Type-Options、HTTP Strict Transport Security (HSTS) 等安全响应头的内容。下文中，我们则侧重介绍一些和跨站安全相关的响应头——

一、Referrer-Policy – 不要问我从哪里来

“互联网”这个词，顾名思义，“互联”才有意义。我们看到的一个常规页面，往往是先加载父级页面，父级页面再加载其他的子资源（如图片、JS 文件和各种多媒体文件等）；主页面上通常还有各种链接，点击会跳转到其他内容；另外，通过 < iframe > 等标签，还可以把第三方页面嵌入在父级页面里直接显示出来。这些都是内容之间“互联”的体现。

^{▲图1.一些做得好的<iframe>会和主页面融为一体，如右侧}


在 HTTP 协议里，如果【A资源】发起了对【B资源】的互联请求，表明该请求来自【A资源】的信息会体现在【B资源】的「referer」请求头里。【B资源】就能明确知道发起方是【A资源】。只要是引用关系或者互联关系的请求，浏览器都会自动附加这个「referer」请求头，以标明发起端是谁。

这个请求头的本意，是让网站管理者更容易得知 HTTP 访问的来源。但人们逐渐认识到这个请求头有可能暴露使用者的隐私。譬如【A资源】当前的 URL 里，如果包含了比较敏感的用户名、权限和会话等信息；只要捕获【B资源】的「referer」请求头，就有可能获得用户在【A资源】里的敏感信息。

---

出于对保护隐私的考虑，Firefox 和 Chrome 等浏览器引入了一套更精确控制浏览器如何发送「referer」请求头的机制，名叫「Referrer-Policy」。支持这套机制的浏览器，会根据具体情况决定是否发送「referer」请求头。但值得注意的是：微软系列的浏览器IE和Edge都不支持这个机制。

使用以下几种方式，可以加载和设定不同的「Referrer-Policy」策略：

方法一:
从 WEB 服务器端，整体地返回 Referrer-Policy 响应头：

#Nginx配置：
add_header Referrer-Policy "no-referrer" always;

#Apache配置：
Header always set Referrer-Policy  "same-origin"

方法二:
对整个页面添加一个名为"referrer"的新 meta 值，类似：

<meta name="referrer" content