Content Security Policy（CSP）是什么？为什么它能抵御 XSS 攻击？

挺久之前过了一遍CSP的安全策略，很多人把它喻为XSS攻击的终结者，因为这种策略不再像传统只靠各种正则和特征匹配来识别跨站攻击Payload，而是直接从协议层把一些存在安全隐患的用法默认给干掉了，把同源同域更发挥到了极致。把之前整理的内容发到这里吧。

CSP策略在默认的情况下是不允许使用data URIs资源的,如果要使用，那么需要显示的指定,比如:img-src ‘self’ data:
script-src：在处理脚本资源的时候设置”unsafe-inline”可以阻止内联Js代码的执行。使用unsafe-eval开关可以禁止eval,setTimeout,setInterval函数的执行。
object-src：控制embed,code,archive applet等对象。
style-src：会控制样式表@import和rel时所引入的URI资源，设置unsafe-inline规则可以是浏览器拒绝解析内部样式和内联样式定义。并不会阻止链入外部样式表。
img-src：可以控制图片资源的连接，包括img标签的src属性，以及CSS3中的url()和image()方法，以及link标签中的href属性(当rel设置成与图像相关的值，比如HTML支持的icon)
media-src:控制媒体类型的外部链入资源，如video, audio, source, 和track标签的src属性。
frame-src:控制内嵌框架包含的外部页面连接：iframe or a frame。
font-src：控制CSS中的@font-face
connect-src：控制XMLHttpRequest中的open()，WebSocket，EventSource
inline script和eval类型函数(包括eval、setInterval、setTimeout和new Function())是不被执行的。另外data URIs也是默认不允许使用的，XBL,只允许通过chrome:和resource:形式uri请求的XBL,其它的比如在CSS中通过-moz-binding来指定的XBL则不允许被执行。

关于Bypass：

通过CRLF相应头分裂注入来BypassCSP需要将新的相应头插入到原来的CSP下面，在处理相同名字的Http头时候，少数浏览器是根据第一次出现的来设置，大部分则是根据最后一次出现的同名Http头来设置。这种属于伪绕过。
请参考kuza55大神的Bypassing Content-Security-Policy，讲了很多通过第三方前端框架的特性实现绕过的case，基本覆盖全了。

综述：
个人愚见，首先CSP是可以在一定程度上提高XSS的攻击难度的，甚至杜绝XSS，前提是CSP策略用的好。还要考虑CSP能否普及，因为CSP在提供安全性的同时也提高了前端逻辑的复杂度，很多资源需要调整，类似QQ，新浪，搜狐这样的站群，想通过合适的CSP同时提高安全性和易用性是很难的。