用过 CSP 的都很郁闷，上报的只有违规的站点名，却没有具体路径。这是缺陷，还是特意的设计？
显然，CSP 是为安全定制的，里面的规范自然要严格制定，否则就会带来新的安全问题。如果支持详细路径的上报，那又会引出什么问题？
由于 CSP 会上报所有的请求，甚至包括重定向的，因此可以用来探测重定向后的地址。假如已登录的用户访问 login.xx.com 会重定向到 xx.com/username，那么攻击者设计一个只允许重定向前的规则的页面，用户访问后，重定向后的 URL 就会当做违规地址上报给攻击者，这其中就包括了用户名。
如果支持详细路径的上报，这简直就是灾难，就用来探测的用户隐私信息了。事实上目前只上报主机名，都能进行一些利用，例如这篇 Using Content-Security-Policy for Evil。
不过新的规范总是在改进，未来也许只上报重定向前的 URL。但在这之前，我们只能接受这些鸡肋的上报日志。
规则不灵活
CSP 目前只支持白名单列表，这多少有些死板。
更糟的是，不同规则之间无法继承和共享。例如默认有个 default-src 规则，但其他的规则会覆盖它，而不是继承它。这就导致各个规则之间，出现很多的重复，使得整个字符串变的冗长。
无法和页面交互
CSP 的监控和上报，是在浏览器后台自动处理的，没有提供一个事件供页面进行交互。
这样就只能使用统一方式强制处理了，而无法交给页面脚本，更好的来自定义处理。
上报方式不可控
如果处理方式有多种选择，那么统一处理也无可厚非。
但事实上 CSP 的上报方式及格式，没有任何可选余地。只能使用 POST + JSON 的方式提交，并且其中的字段十分累赘，甚至把规则里的白名单列表也发上来了。
此外，也无法设定一个缓存时间，控制重复上报的间隔。在配置白名单遗漏时，会出现大量的误报，严重消耗资源。
浪费带宽
在较新的 Chrome 里，能够使用 meta 标签在前端页面定义 CSP 规则，但其他浏览器目前仍不支持。
为了能够统一，大多仍使用 HTTP 头部输入的方式。由于规则通常都很长，导致每次页面访问，都会额外增加数百字节。
维护繁琐
如果是通过 Web 服务开启的，那么每次调整策略，都得修改配置甚至重启服务，很是麻烦。
兼容性不高
目前只有高版本的浏览器支持，而 IE 系列的则几乎都没能很好的支持。
如果某些攻击只争对低版本的浏览器，那么很有可能出现大量遗漏。
模拟的 CSP
原理
事实上在 CSP 出现的好几年前，就有一个能够监控跨站资源的方案，下面就来分享下。
写过 JS 的都知道，如果需要给大量元素监听事件，无需对每个元素上都进行绑定，只要监听它们的容器即可。当具体的事件冒泡到容器上，通过 event.target 即可获知是哪个元素产生的。
脚本、图片、框架等元素加载完成时，都会产生 onload 事件；而所有元素都位于『文档』这个顶级容器。因此我们监听 document 的 onload 事件，即可获知所有加载资源的元素。
不过 onload 这个事件比较特殊，无法通过冒泡的方式来监听。但在 DOM-3 标准模型里，事件还有一个『捕获』的概念，这也是为什么 addEventListener 有第三个参数的原因。
来源：https://www.cnblogs.com/dwnww/p/4343554.html