什么是CSP
参照完整文档：
https://developer.mozilla.org/zh-CN/docs/Web/HTTP/CSP
CSP（Content Security Policy）即内容安全策略。
是一个额外的安全层，用于检测并削弱某些特定类型的攻击，包括跨站脚本 (XSS) 和数据注入攻击等。无论是数据盗取、网站内容污染还是散发恶意软件，这些攻击都是主要的手段。
CSP 被设计成完全向后兼容（除CSP2 在向后兼容有明确提及的不一致; 更多细节查看这里 章节1.1）。不支持CSP的浏览器也能与实现了CSP的服务器正常合作，反之亦然：不支持 CSP 的浏览器只会忽略它，如常运行，默认为网页内容使用标准的同源策略。如果网站不提供 CSP 头部，浏览器也使用标准的同源策略。（在下文中再讲一下同源策略）
为使CSP可用, 你需要配置你的网络服务器返回 Content-Security-Policy HTTP头部 ( 有时你会看到一些关于X-Content-Security-Policy头部的提法, 那是旧版本，你无须再如此指定它)。
说了这么一堆，总结一下：
CSP是一种白名单策略，当有从非白名单允许的JS脚本出现在页面中，浏览器会阻止脚本的执行。
同源策略
在看CSP语法前我觉得有必要了解一下浏览器的同源策略
完整文档：
https://developer.mozilla.org/zh-CN/docs/Web/Security/Same-origin_policy
同源策略是一个重要的安全策略，它用于限制一个origin的文档或者它加载的脚本如何能与另一个源的资源进行交互。它能帮助阻隔恶意文档，减少可能被攻击的媒介。
同源的定义
如果两个 URL 的 protocol、port (如果有指定的话)和 host 都相同的话，则这两个 URL 是同源。这个方案也被称为“协议/主机/端口元组”，或者直接是 “元组”。（“元组” 是指一组项目构成的整体，双重/三重/四重/五重/等的通用形式）。
同源政策的目的，是为了保证用户信息的安全，防止恶意的网站窃取数据。
举一个例子：
有一个网站，用户登陆了一个网站，网站使用了cookie身份验证，而且没有使用http-only，（这里稍微提一下http-only，使用了http-only后，通过JavaScript的 Document.cookie API无法访问带有 HttpOnly 标记的Cookie，它们只应该发送给服务端。包含服务端 Session 信息的 Cookie 不能被客户端 JavaScript 脚本调用，）我们利用XSS攻击方式获得了用户的cookie（比如
），我们获得了用户的cookie后，因为没有同源策略限制，浏览器不作为，
提交表单不受同源政策的限制。我们可以在登陆了当前页面后，以当前用户的身份去查看我们想要看的包含这个用户信息的所有信息。比如银行卡余额，密码这种。
"同源政策"越来越严格。目前，如果非同源，共有三种行为受到限制。
（1） Cookie、LocalStorage 和 IndexDB 无法读取。
（2） DOM 无法获得。
（3） AJAX 请求不能发送。
跨源网络访问
同源策略控制不同源之间的交互，例如在使用XMLHttpRequest 或 标签时则会受到同源策略的约束。这些交互通常分为三类：
跨域写操作（Cross-origin writes）一般是被允许的。例如链接（links），重定向以及表单提交。特定少数的HTTP请求需要添加 preflight。
跨域资源嵌入（Cross-origin embedding）一般是被允许（后面会举例说明）。
跨域读操作（Cross-origin reads）一般是不被允许的，但常可以通过内嵌资源来巧妙的进行读取访问。例如，你可以读取嵌入图片的高度和宽度，调用内嵌脚本的方法
以下是可能嵌入跨源的资源的一些示例：
标签嵌入跨域脚本。语法错误信息只能被同源脚本中捕捉到。 标签嵌入CSS。由于CSS的松散的语法规则，CSS的跨域需要一个设置正确的 HTTP 头部 Content-Type 。不同浏览器有不同的限制： IE, Firefox, Chrome, Safari (跳至CVE-2010-0051)部分 和 Opera。 通过