Content-Security-Policy

本文介绍的是W3C的 Content Security Policy，简称CSP。
顾名思义，这个规范与内容安全有关，主要是用来定义页面可以加载哪些资源，减少XSS的发生。
Chrome扩展已经引入了CSP，通过manifest.json中的content_security_policy字段来定义。
一些现代浏览器也支持通过响应头来定义CSP。
下面我们主要介绍如何通过响应头来使用CSP，Chrome扩展中CSP的使用可以参考Chrome官方文档。

浏览器兼容性

早期的Chrome是通过X-WebKit-CSP响应头来支持CSP的，而firefox和IE则支持X-Content-Security-Policy，Chrome25和Firefox23开始支持标准的的Content-Security-Policy，见下表。

响应头	Chrome	Firefox	Safari	IE
`Content-Security-Policy`	`25+`	`23+`	`-`	`-`
`X-Content-Security-Policy`	`-`	`4.0+`	`-`	`10.0(有限的)`
`X-Webkit-CSP`	`14+`	`-`	`6+`	`-`

完整的浏览器CSP支持情况请移步 CanIUse。

如何使用

要使用CSP，只需要服务端输出类似这样的响应头就行了：

Content-Security-Policy: default-src 'self'

default-src是CSP指令，多个指令之间用英文分号分割；'self'是指令值，多个指令值用英文空格分割。
目前，有这些CSP指令：

指令	指令值示例	说明
`default-src`	`'self' cnd.a.com`	定义针对所有类型（js、image、css、web font，ajax请求，iframe，多媒体等）资源的默认加载策略，某类型资源如果没有单独定义策略，就使用默认的。
`script-src`	`'self' js.a.com`	定义针对JavaScript的加载策略。
`style-src`	`'self' css.a.com`	定义针对样式的加载策略。
`img-src`	`'self' img.a.com`	定义针对图片的加载策略。
`connect-src`	`'self'`	针对Ajax、WebSocket等请求的加载策略。不允许的情况下，浏览器会模拟一个状态为400的响应。
`font-src`	`font.a.com`	针对Web Font的加载策略。
`object-src`	`'self'`	针对``、``或` `等标签引入的flash等插件的加载策略。
`media-src`	`media.a.com`	针对` `或` `等标签引入的html多媒体的加载策略。
`frame-src`	`'self'`	针对frame的加载策略。
`sandbox`	`allow-forms`	对请求的资源启用`sandbox`（类似于`iframe`的`sandbox`属性）。
`report-uri`	`/report-uri`	告诉浏览器如果请求的资源不被策略允许时，往哪个地址提交日志信息。

特别的：如果只想让浏览器汇报日志，而不阻止任何内容。可以改用Content-Security-Policy-Report-Only响应头。

指令值可以由下面这些内容组成：

指令值 | 指令示例 | 说明
-||
* | img-src * | 允许任何内容。
'none' | img-src 'none' | 不允许任何内容。
'self' | img-src 'self' | 允许来自相同来源的内容（相同的协议、域名和端口）。
data | img-src data | 允许data:协议（例如base64编码的图片）。
www.a.com | img-src img.a.com | 允许加载指定域名的资源。
*.a.com | img-src *.a.com | 允许加载a.com任何子域的资源。
https://img.com | img-src https://img.com | 允许加载img.com的https资源（协议需匹配）。
https: | img-src https: | 允许加载https资源。
'unsafe-inline' | script-src 'unsafe-inline' | 允许加载inline资源（例如常见的style属性，onclick，inline js和inline css等等）。
'unsafe-eval' | script-src 'unsafe-eval' | 允许加载动态js代码，例如eval()。

从上面的介绍可以看到，CSP协议可以控制的内容非常多。而且如果不特别指定'unsafe-inline'时，页面上所有inline的样式和脚本都不会执行；不特别指定'unsafe-eval'，页面上不允许使用new Function，setTimeout，eval等方式执行动态代码。在限制了页面资源来源之后，被XSS的风险确实小不少。

当然，仅仅依靠CSP来防范XSS是远远不够的，不支持全部浏览器是它的硬伤。不过，鉴于低廉的开发成本，加上也没什么坏处。如果担心影响面太大，也可以像下面这样，仅收集不匹配规则的日志，先观察下：

Content-Security-Policy-Report-Only: script-src 'self'; report-uri http://test/

这样，如果页面上有inline的JS，依然会执行，只是浏览器会向指定地址发送一个post请求，包含这样的信息：

{
  "csp-report":{
    "document-uri": "http://test/test.php",
    "referrer": "",
    "violated-directive": "script-src 'self'",
    "original-policy": "script-src 'self'; report-uri http://test/",
    "blocked-uri": ""
  }
}

CSP先介绍到这里。现代浏览器支持不少与安全有关的响应头，以后接着再介绍。