很久之前，我的个人网站被攻击了。我不知道它是如何发生的，但它确实发生了。幸运的是，攻击带来的破坏是很小的：一小段 JavaScript 被注入到了某些页面的底部。我更新了 FTP 和其它的口令，清理了一些文件，事情就这样结束了。
有一点使我很恼火：在当时，还没有一种简便的方案能够使我知道那里有问题，更重要的是能够保护网站的访客不被这段恼人的代码所扰。
现在有一种方案出现了，这种技术在上述两方面都十分的成功。它就是 内容安全策略 （ content security policy ） （CSP）。
什么是 CSP?
其核心思想十分简单：网站通过发送一个 CSP 头部，来告诉浏览器什么是被授权执行的与什么是需要被禁止的。
这里有一个 PHP 的例子：
一些指令
你可以定义一些全局规则或者定义一些涉及某一类资源的规则：
default-src 'self' ;
# self = 同端口，同域名，同协议 => 允许
基础参数是 default-src：如果没有为某一类资源设置指令规则，那么浏览器就会使用这个默认参数值。
script-src 'self' www.google-analytics.com ;
# 来自这些域名的 JS 文件 => 允许
在这个例子中，我们已经授权了 www.google-analytics.com 这个域名来源的 JavaScript 文件使用到我们的网站上。我们也添加了 'self' 这个关键词；如果我们通过 script-src 来重新设置其它的规则指令，它将会覆盖 default-src 规则。
如果没有指明协议（scheme）或端口，它就会强制选择与当前页面相同的协议或端口。这样做防止了混合内容（LCTT 译注：混合内容指 HTTPS 页面中也有非 HTTPS 资源，可参见： https://developer.mozilla.org/zh-CN/docs/Security/MixedContent ）。如果页面是 https://example.com，那么你将无法加载 http://www.google-analytics.com/file.js 因为它已经被禁止了（协议不匹配）。然而，有一个例外就是协议的提升是被允许的。如果 http://example.com 尝试加载 https://www.google-analytics.com/file.js，接着协议或端口允许被更改以便协议的提升。
style-src 'self' data: ;
# Data-Uri 嵌入 CSS => 允许
在这个例子中，关键词 data: 授权了在 CSS 文件中 data 内嵌内容。
在 CSP 1 规范下，你也可以设置如下规则：
img-src有效的图片来源connect-src应用于 XMLHttpRequest（AJAX），WebSocket 或 EventSourcefont-src有效的字体来源object-src有效的插件来源（例如，，，）media-src有效的和来源
CSP 2 规范包含了如下规则：
child-src有效的 web workers 和 元素来源，如和（这个指令用来替代 CSP 1 中废弃了的frame-src指令）form-action可以作为 HTML的 action 的有效来源frame-ancestors使用，，，或内嵌资源的有效来源upgrade-insecure-requests命令用户代理来重写 URL 协议，将 HTTP 改到 HTTPS （为一些需要重写大量陈旧 URL 的网站提供了方便）。
为了更好的向后兼容一些废弃的属性，你可以简单的复制当前指令的内容同时为那个废弃的指令创建一个相同的副本。例如，你可以复制 child-src 的内容同时在 frame-src 中添加一份相同的副本。
CSP 2 允许你添加路径到白名单中（CSP 1 只允许域名被添加到白名单中）。因此，相较于将整个 www.foo.com 域添加到白名单，你可以通过添加 www.foo.com/some/folder 这样的路径到白名单中来作更多的限制。这个需要浏览器中 CSP 2 的支持，但它很明显更安全。
一个例子
我为 Web 2015 巴黎大会上我的演讲 “CSP in Action”制作了一个简单的例子。
在没有 CSP 的情况下，页面展示如下图所示：
不是十分优美。要是我们启用了如下的 CSP 指令又会怎样呢？
