前篇“web安全防护相关响应头（上）”中，我们分享了 x-frame-options、x-content-type-options、http strict transport curity (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 t referrer-policy  "same-origin"

方法二:

对整个页面添加一个名为”referrer”的新 meta 值，类似：

<meta name="referrer" content="origin">

方法三:

给页面内某个标签，如下例中的 <a> 链接标签和 <img> 图片加载标签，增加一个 referrerpolicy 属性：

<a href="/d/file/titlepic/example.com" referrerpolicy="origin"><img src="/d/file/titlepic/bd_logo1.png" referrerpolicy="no-referrer">

可以看出，以上三种方式的生效范围各有差异，分别对应整站起效、特定页面起效及设置特定标签起效，可以根据具体情况使用。

这个策略可以配置为以下值，含义分别为：

no-referrer
任何情况下，浏览器都不发送 http referer 请求头；

no-referrer-when-downgrade
如果浏览器从 https 类型的 url 跳转到 http 类型的 url，浏览器就不需要发送 referer 请求头；

same-origin
只有发起端和目标端是同源时，浏览器才发送 referer 请求头。域名和协议完全相同，两个站点才是同源站点；

origin
浏览器会发送 referer 请求头，但 referer 请求头里只有发起方的域名信息，没有完整的 url 路径。如发起端 url 为 https://example.com/page.html，实际发送的 referer 请求头里只有 https://example.com/；

strict-origin
和 origin 含义相似，且只有同等安全级别的协议才发送 referer 请求头，如从 https→https 会发送，而从 https→http 则不发送；

origin-when-cross-origin
对同源的其他资源，发送包含完整 url 的 referer 请求头；如果是非同源的资源，则 referer 请求头里只有域名信息，没有完整 url；

strict-origin-when-cross-origin
和上一条类似，但协议的安全等级降低时就不发送 referer 请求头了；

unsafe-url
无论是否同源，都发送完整 url 的 referer 请求头。

举例：在我们的测试页面 /d/file/titlepic/ 里，包含外站图片 http://img.tcxa.com.cn/logo.png 。默认在没有其他设置的情况下，发往该图片的请求如下图，其中的 referer 请求头里清晰地包含了父级页面的地址：http://www.sandbox加入学生会申请书.com/index.html

▲图2 正常状态下图片访问带referer请求头

如果 www.sandbox.com 服务器的 nginx 配置内，加入 add_headerreferrer-policy"same-origin"always; ，设定只有同源站点才发送 referer 请求头。这时候，访问 /d/file/titlepic/ 获得的响应头里，就增加了一行 referrer-policy:same-origin 的响应头，如下：

▲图3 父资源的referrer-policy设置为same-origin同源

这时候，由于和发起端 www.sandbox.com 的域名并不同源，如下图所示，可以看出，发往 http://img.tcxa.com.cn/logo.png 图片的请求此时已不再出现 referer 请求头了：

▲图4 子资源的请求里二年级班务工作计划不再包含referer请求头

题外话：
referer 这个单词在英语里并不存在，它是个拼错的单词，正确写法是「referrer」。在相关 http 协议制定时，写作者笔误写错了。人们意识到这个错误时为时已晚。为了保持旧有兼容性，这个名字被将错就错延续下来。但后续很多和 山东源大工贸有限公司referer 请求头相关的术语和协议，又恢复了正确的「referrer」拼法。比如这里的「referrer-policy」策略。

二、x-xss-protection — 跨站边界保护

xss 的全称是 cross site scripting，中文叫“跨站脚本攻击”。其中“脚本”一词，主要指 javascript 脚本。javascript 脚本在多年的进化中，使用越来越灵活，功能越来越强大，这也导致人们原本不太在意的浏览器客户端安全，变得越来越重要了。

现在的 javascript 脚本，不但可以访问和操控页面上的 dom 元素，还可以和服务器端进行交互，故而它带来的安全隐患也不容忽视。为了“缓解”这一问题，浏览器厂商们做了一定的努力，其中一种机制就是 x-xss-protection 响应头。支持这一响应头的浏览器，在检测到跨站脚本攻击 (xss)时，可以主动停止加载页面。

这个响应头有以下四种值：

x-xss-protection: 0x-xss-protection: 1x-xss-protection: 1; mode=blockx-xss-protection: 1; report=<reporting-uri>

这四个值的含义分别为：

http://dvwa站点ip/vulnerabilities/xss_r/?name=<script>alert(document.cookie)</script>

#nginx配置：add_header x-xss-protection "1; mode=block" always;#apache配置：header always t x-xss-protection "1; mode=block"