前言

这也是本周get到的一个名词，可能早读君有点落后。看之前可以先讲get到这个名词的过程，本来呢想开发个加班的桌面提醒，但开发完表示我不是想要的那种，那么就想转战到chrome extension来做，可这个时候就会报各种CSP了。今天我们先来看看由@屈光宇关于csp的分享。

ps：这可能就是双手互搏，一手挖坑，一手填坑吧。

正文从这开始～

本文要介绍的是 W3C 的 Content Security Policy，简称 CSP。顾名思义，这个规范与内容安全有关，主要是用来定义页面可以加载哪些资源，减少 XSS 的发生。

Chrome 扩展已经引入了 CSP，通过 manifest.json 中的 content_security_policy 字段来定义。一些现代浏览器也支持通过响应头来定义 CSP。下面我们主要介绍如何通过响应头来使用 CSP，Chrome 扩展中 CSP 的使用可以参考 Chrome 官方文档。

浏览器兼容性

早期的 Chrome 是通过 X-WebKit-CSP 响应头来支持 CSP 的，而 firefox 和 IE 则支持 X-Content-Security-Policy，Chrome25 和 Firefox23 开始支持标准的 Content-Security-Policy，见下表。

（点图片看大图）

完整的浏览器 CSP 支持情况请移步 CanIUse。

如何使用

要使用 CSP，只需要服务端输出类似这样的响应头就行了：

default-src 是 CSP 指令，多个指令之间用英文分号分割；'self' 是指令值，多个指令值用英文空格分割。目前，有这些 CSP 指令：

（点图片看大图）

指令值可以由下面这些内容组成：

（点图片看大图）

从上面的介绍可以看到，CSP 协议可以控制的内容非常多。而且如果不特别指定 'unsafe-inline' 时，页面上所有 inline 样式和脚本都不会执行；不特别指定 'unsafe-eval'，页面上不允许使用 new Function，setTimeout，eval 等方式执行动态代码。在限制了页面资源来源之后，被 XSS 的风险确实小不少。

当然，仅仅依靠 CSP 来防范 XSS 是远远不够的，不支持全部浏览器是它的硬伤。不过，鉴于低廉的开发成本，加上也没什么坏处。如果担心影响面太大，也可以像下面这样，仅收集不匹配规则的日志，先观察下：

这样，如果页面上有 inline JS，依然会执行，只是浏览器会向指定地址发送一个 POST 请求，包含这样的信息：

@屈光宇曾经分享过的有：

【第382期】AMP，来自 Google 的移动页面优化方案

最后

本该这个时候在南京的，可惜这周末要培训，没办法去参加这种高大上的搞基会了。要是有去的童鞋，可以分享分享你们的体会～

关于本文

作者：@屈光宇

原文链接：https://imququ.com/post/content-security-policy-reference.html

欢迎投稿到前端早读课

投稿邮箱：181422448@qq.com