关于'It violates the following Content Security Policy directive: ‘iframe-src'’

提笔写这个文章有些担心，因为毕竟技术不够好，英语不够好，好，废话少说，开始说。

最近在做一个产品的维护，SpeedyPassword，一款密码管理器。

SpeedyPassword介绍：

SpeedyPasswor是一款可以记录各个网站密码的浏览器插件，跨浏览器使用。 它自己有一个主密码。假如我在chrome浏览器上安装了SpeedyPassword，但是没有登录SpeedyPassword。 我在打开一个facebook网站时，页面会有如下提示信息，

但是在打开www.twitter.com时，这个内嵌的页面没有弹出。

调试信息如下，请看红线标出的那一部分，‘it violates the following Content Security Policy directive: ‘iframe-src。’’

根据我在goole.com上面的搜索，对于content页面，有一个Content Security Polily（内容安全协议）。

对于这个解释，请看http://www.html5rocks.com/en/tutorials/security/content-security-policy/?redirect_from_locale=zh#disqus_thread这个页面，现在我大致的翻译一下。

内容安全协议简介

前言

来自https://mybank.com网站的代码只能对https://mybank.com网站的数据有操作权限，因此https://evil.example.com肯定不能有对mybank网站数据的操作权限。每一个原始页面都和网络上的其他网站隔离开来，给开发人员一个独立的空间建立自己的网站。理论上这是相当明智的选择。实际上，网络攻击者们已经找到了更加聪明的办法来破坏这一规律。

  跨域脚本攻击，例如，使用含糊不清的代码带着目的内容欺骗一个网站，从而绕过最初的安全策略。这是一个大问题，因为浏览器信任所有的显示在页面上面的代码，如果一个黑客成功的植入了所有的代码，那就game over了。用户session 数据妥协了，并且应该保密的信息被坏人窃取了。 我们显而易见的要尽可能的阻止这类事件的发生。本教程中突出了一个很有前景的新防御方式,可以显著减少XSS攻击的风险和影响现代浏览器:内容安全策略(CSP)。

代码白名单

   由XSS攻击暴露出来的核心问题是，浏览器不能在区分出这两种脚本，一个是本身就是应用一部分的，一个是含糊不清被第三方入侵的脚本。例如，加载和执行在google网站上的google +1按钮的代码来自

https://apis.google.com/js/plusone.js 这个页面的初始代码里面。 我们信任他，但是我们不能指望浏览器自己区分出代码是来自apis.google.com，这件事是比较令人敬畏的。然而来自apis.evil.example.com的代码并不然。浏览器快乐的下载执行一个页面请求的代码，不顾来源。

  不是盲目的相信服务器传递的所有东西，而是CSP定义了Content Security Policy http header，这个http header允许开发者创建信任内容的代码白名单，从而指导浏览器仅仅执行或者回报来自哪些资源的代码。即使攻击者能够找到入侵代码的突破口，代码和白名单不匹配，入侵代码也不会执行。

  由于我们信任apis.google.com来传递有效代码，我们相信我们自己也会，让我们定义一个策略，只允许执行来自其中一个来源的代码。

	Content-Security-Policy: script-src 'self' https://apis.google.com

script-src是一个指导，控制着代码特殊页面域代码相关的权限。 我们指定‘self’ 作为一个有效的代码来源。apis.google.com是另外一个。

浏览器会有责任的去下载执行来自apis.google.com的js，同时也有来自当前页面的js。

由于这个规则已经制定了，浏览器只会抛出一个异常，而不是从其他来源下载脚本。 当一个聪明的黑客向你的站点植入代码时，他会得到一个错误信息，而不是像他所希望的成功页面。