一、介绍
为了减缓XSS攻击，一个web应用可以声明它只可以从指定的可信源加载脚本。这个声明允许客户端检测并阻止恶意的脚本被黑客注入到应用中。
CSP并不应作为防御内容注入漏洞的第一道防线，而是用于深度防护，它是为了减少由内容注入攻击造成的伤害。防御内容注入的第一道防线，应该由服务器来验证输入，以及对输出进行编码。
通常会对现有的web应用实现CSP策略，为了获得最大的利益，作者需要移除所有内联脚本和内联样式，例如将他们移动到外部脚本中。因为浏览器不能判断内联脚本是否是由攻击者注入的。
web应用程序通过Content-Security-Policy HTTP头来使用CSP策略。这些策略只适用于当前的资源。如果要为整个站点提供一个策略，服务器需要对每个资源进行声明。
应用示例：
开发者想要保护他们的应用免受跨站脚本攻击。他们只希望加载并执行可信的CDN上的脚本，并且他们希望确保在网页环境中不能执行插件，下面的政策可以实现：
Content-Security-Policy: script-src https://cdn.example.com/scripts/; object-src 'none'
二、第二版相对第一版本的变化
1.现在如果资源加载是重定向的结果，源表达式的路径组件会被忽略。
2.现在受保护的资源可以加载Workers由child-src而不是script-src控制。
3.Workers现在有自己的策略，从加载它们的保护资源中分离。
4.base-url控制受保护的资源可以从指定的文档基础URL加载。
5.child-url代替了frame-src，控制受保护的资源能够嵌入框架并加载Workers。（第三版又有变化）
6.form-action控制受保护的资源的表单提交。
7.frame-ancestors控制受保护资源能否嵌入其他文档。它意图取代X-Frame-Options HTTP请求头。
8.plugin-types控制受保护资源能否加载指定类型的插件。
9.特殊的内联脚本和样式可以通过随机数和哈希加入白名单。
10.CSP请求头现在跟随相关请求头发送。
11.SecurityPolicyViolationEvent事件会在违反策略时触发。
12.新增了一些违反策略的报告（通过report-uri提交以及通过SecurityPolicyViolationEvent事件）。它包括effectiveDirective、statusCode、sourceFile、lineNumber以及columnNumber。
13.现在在sandbox指令中的标志会影响Worker的实例。
三、第三版相对于第二版的变化
1.在CSP第二版中被废弃的frame-src指令，又生效了，worker-src指令添加了进来。如果两者都未出现则遵从child-src指令（如果仍没有则为default-src指令）。
2.URL匹配规则目前把不安全的模式和端口视为它们的安全变种。也就是说http://example.com:80将会同时匹配http://example.com:80和https://example.com:443
‘self’现在匹配https和wss，即使页面是http
3.从内联脚本和内联样式生成的违反报告现在报告“inline”作为阻止资源。阻止eval()的执行会报告“eval”。
4.增加了manifest-src指令。
5.report-uri指令废弃，使用新的report-to指令代替。
6.disown-opener指令确保资源不会被其他浏览器上下文控制。
四、策略的传达
服务器通过HTTP响应头向客户端传达策略。
1.Content-Security-Policy头域
Content-Security-Policy头域是传达策略的较好的机制，它的语法如下：
"Content-Security-Policy":策略字符串
例如，一个响应可能会包含以下头域：
Content-Security-Policy: script-src 'self'
服务器禁止发送多于1个叫做Content-Security-Policy的HTTP头域。
服务器可以针对不同的类型的资源发送不同的值。
在收到服务器响应至少一个Content-Security-Policy头域时，客户端必须执行其中的所有策略。
2.Content-Security-Policy-Report-Only头域
Content-Security-Policy-Report-Only头域只是监控策略而不执行，语法如下：
"Content-Security-Policy-Report-Only":策略字符串
例如，服务器操作员可能希望开发它们的安全策略迭代。操作者可以部署一个report-only策略以检测它们的表现：
Content-Security-Policy-Report-Only: script-src 'self';
report-to csp-reporting-endpoint
在他们的网站中，违反策略的客户端会发送违反报告到report-to中指定的URL上，但是仍然允许违反策略的资源加载。一旦确认策略配置的正确，他们就可以使用Content-Security-Policy头域强制执行。
服务器禁止发送多于1个叫做Content-Security-Policy-Report-Only的HTTP头域。
服务器可以针对不同的类型的资源发送不同的值。
在收到服务器响应至少一个Content-Security-Policy-Report-Only头域时，客户端必须监控其中的所有策略。
Content-Security-Policy-Report-Only头在meta元素中不支持。
3.HTML meta元素
服务器可以通过一个或多个meta元素支持策略。例如：
<meta http-equiv="Content-Security-Policy" content="script-src 'self'">
4.CSP HTTP请求头
CSP头域声明了一个特殊的请求，它是一个策略的主题，它的值定义为下面的ABNF语法：
"CSP:" csp-header-value
csp-header-value = *WSP “active” *WSP
如果用户代理在监控或执行一个包含指令值为源列表的策略，那么用户代理必须与不匹配受保护的资源的来源请求一同发送一个叫做CSP的头域，它的值必须是active。
用户代理可以选择发送这个头，仅当请求的资源类型是活动的策略。也就是说，给定的策略img-src example.com，用户代理会同图片请求一同发送CSP:active头，可以在其他类型的资源中不添加这个头。
5.执行多个策略
上文说道，当有多条策略出现时，每一条必须根据相关类型被执行或报告：
Content-Security-Policy: default-src 'self' http://example.com http://example.net;
connect-src 'none';
Content-Security-Policy: connect-src http://example.com/;
script-src http://example.com/
连接到example.com是否允许？回答是不允许。执行多个策略指的是通过所有的策略。即使第二条策略会允许连接，但第一条策略包含connect-src ‘none’，所以它会阻止连接。向策略列表添加额外的策略只会更进一步的限制保护资源的能力。
进一步证明，考虑在这个页面的一个脚本。第一个策略会通过default-src指令锁定脚本资源到自身、http://example.com和http://example.net来源。第二条，只会允许脚本来源于http://example.com/。脚本只会在两个策略同时符合时加载，这个例子中来源只有是http://example.com/时符合。
五、策略语法
CSP使用分号“;”分割多个策略。每个策略由下面的语法构成：
WSP表示空白字符，VCHAR表示可打印字符
policy-token = [ directive-token *( ";" [ directive-token ] ) ] directive-token = *WSP [ directive-name [ WSP directive-value ] ] directive-name = 1*( ALPHA / DIGIT / "-" ) directive-value = *( WSP / )
解析策略步骤：
1.让directives集合为空的集合
2.遍历每一个非空的token，返回以分号为分隔符对policy进行严格的拆分：
I.跳过空白字符
II.收集非空格的其他字符序列，它们是指令名称
III.如果在token中仍然有字符保留，跳过开头的一个字符（一定是一个空格）
IV.token剩下的字符（如果由）就是指令的值
V.如果指令集合已经包含一个大小写不敏感的匹配指令名，忽略这个指令，继续下一个token
VI.添加指令到指令集合中，名为指令名，值为指令值
3.返回指令集合
具体指令的用法会在后面的文章中说明。