header('X-Content-Security-Policy: default-src \'self\'');
header('Content-Security-Policy: default-src \'self\'');
header('X-Webkit-CSP: default-src \'self\'');
header('Set-Cookie: abc=123');
?><!doctype html>
<body onclick="alert(1)">
Click me
</body>
详细的讨论可以看这里：https://bugzilla.mozilla.org/show_bug.cgi?id=886164
（2）XSS Auditor和CSP
关于XSS Auditor和CSP，这里笔者想进行一次更开放式的讨论。以Chrome中测试为例，当XSS Auditor和CSP同时作用到一段JS代码上，会有怎样一个效果呢。比如XSS Auditor设置的是阻断，CSP里设置unsafe-inline放行，结果还是被阻断。这是由于浏览器解析JS脚本的时候先使用了XSS auditor这层安全防御策略，所以CSP中的unsafe-inline这个指令并没有起作用，从广义的角度来看，CSP中的策略被Bypass了。浏览器的策略中，类似与这样的情况还有很多。比如下面介绍的这个。
（3） X-Frame-Options和CSP frame
当a.com设置X-Frame-Options:deny，b.com设置CSP frame-src a.com，那么b.com是否可以iframe a.com呢。测试中发现a.com还是不能被b.com包含的。你可以认为浏览器解析中，X-Frame-Options优先级大于CSP frame。
十、CSP总结
充分了解CSP安全策略的语法和指令，并最大程度的合理的去利用和部署这些策略，努力把安全策略发挥到极致，使其最终把危害降低到最低。
CSP并不能消除内容注入攻击，但可以有效的检测并缓解跨站攻击和内容注入攻击带来的危害。
CSP不是做为防御内容注入(如XSS)的第一道防线而设计，而最适合部署在纵深防御体系中。
关于为什么CSP的使用率如此之低。究其原因，CSP虽然提供了强大的安全保护，但是他也造成了如下问题：Eval及相关函数被禁用、内嵌的JavaScript代码将不会执行、只能通过白名单来加载远程脚本。这些问题阻碍CSP的普及，如果要使用CSP技术保护自己的网站，开发者就不得不花费大量时间分离内联的JavaScript代码和做一些调整。
没有被绕过的策略不是好的策略，而从辩证角度来讲，多加载一种安全策略，就多了一种Bypass的维度。在安全领域“Bypass”是一个曼妙而鬼魅的名字。
应该把CSP安全策略视为是一把可以直插心脏的锋利的尖刀，而不是一根电线杆子杵在那。
