多年前刚刚开始有互联网的时候，就习惯了每天中午在电脑上看看新浪新闻，这个习惯一直持续到今天，然而，随便点开一篇新闻，满屏的广告总是很影响阅读，于是某天我就想，何不自己写个浏览器插件，把这些广告全部给删掉，提升一下阅读体验。

说干就干，看了看Google的官方文档，就开工了。

Chrome的插件，允许点击插件图标后，有一个小的弹出页面，方便做一些插件配置之类的事，这个页面如下图所示，其中那个绿色的"R"是插件的图标，图标下面就是插件的弹出页面:

当用户在这个页面上有所操作后，插件就可以通过javascript代码，调用Chrome API来保存用户的配置或者一些其他操作。

在这个弹出页面里，所有的Javascript代码必须引用自一个专门的js文件，而不能直接inline在页面里面，顺便查了一下，像是Firefox等浏览器也都是类似的要求。如果我就是硬要把js代码写在页面里，倒也不会报错，唯一的问题就是这些inline的js代码直接被忽略了，根本不会执行。于是问题来了，如果是一些简单功能，inline明明更简单啊，为什么非要引用自文件呢？

继续搜索，发现原来主要是安全考虑，也就是CSP(Content Security Policy)在起作用，这个CSP有很多内容，其中最主要的一点就是防止XSS攻击，或者简单说，就是防止你的页面被注入恶意的js代码来干一些你不期望发生的事。而因为这个弹出页面可以调用Chrome API，如果被XSS了，就格外地危险，所以这里就遵循了CSP，不允许js代码inline在页面里面。这里你可能就要问了，我自己写的js肯定不会攻击我自己啊，为啥不让我inline？先简单看一下XSS。

XSS攻击的手段非常多，举个简单例子，比如你有个购物网站，允许用户写评价，那么恶意用户就可以在评价里面嵌入js代码，如果你没有做安全处理，当你在页面上展示该评价的时候，顺带就把恶意的js代码给执行了。

防止XSS可以从两个方面入手，最好是让恶意代码无法注入，但上面这个XSS攻击只是非常初级的做法，实际注入恶意代码的方式无奇不有，防不胜防。所以退而求其次，就是让js代码即使被注入了也不执行，所有可以执行的js代码都必须来自指定的可靠来源的文件。

这也就是为什么浏览器插件弹出页面里不能inline js代码的原因。回到上面的那个问题：『我自己写的js肯定不会攻击我自己啊，为啥不让我inline？』

是的，从插件开发者的角度出发，自己确实是不会攻击自己，但如果你是Chrome的作者，你是很难区分清楚哪些js代码是插件作者inline的，哪些可能是被注入的，所以就只好牺牲一点开发的便捷性，但是保证安全性了。