避免运行时的内联模版：许多模版库都使用new Function()以加速模版的生成。这对动态程序来说非常棒，但是对恶意文本来说存在风险。
报告
CSP可以在服务器端阻止不可信的资源对用户来说非常有用，但是对于获取各种发送到服务器的通知来说对我们却非常有用，这样我们就能识别和修复任何恶意脚本注入。为此你可以通过report-uri指令指示浏览器发送JSON格式的拦截报告到某个地址。
Content-Security-Policy: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;
报告看起来会像下面这样：
{
"csp-report": {
"document-uri": "http://example.org/page.html",
"referrer": "http://evil.example.com/",
"blocked-uri": "http://evil.example.com/evil.js",
"violated-directive": "script-src 'self' https://apis.google.com",
"original-policy": "script-src 'self' https://apis.google.com; report-uri http://example.org/my_amazing_csp_report_parser"
}
}
其中包含的信息会帮助你识别拦截的情况，包括拦截发生的页面（document-uri），页面的referrer，违反页面策略的资源（blocked-uri），所违反的指令（violated-directive）以及页面所有的内容安全策略（original-policy）。
现实用法
CSP现在在Chrome 16+和Firefox 4+的浏览器上可用，并且它在IE10上预计会获得有限的支持。Safari目前还不支持，但是WebKit每晚构建版已经可用，所以预计Safari将会在下面的迭代中提供支持。
下面让我们看一些常用的用例：
实际案例1：社会化媒体widget
Google +1 button包括来自https://apis.google.com的脚本，以及嵌入自https://plusone.google.com的iframe。你的策略需要包含这些源来使用Google +1的按钮。最简单的策略是script-src https://apis.google.com; frame-src https://plusone.google.com。你还需要确保Google提供的JS片段存放在外部的JS文件里。
Facebook的Like按钮有许多种实现方案。我建议你坚持使用iframe版本，因为它可以和你站点的其它部分保持很好的隔离。这需要使用frame-src https://facebook.com指令。请注意，默认情况下，Facebook提供的iframe代码使用的是相对路径//facebook.com，请把这段代码修改为https://facebook.com，HTTP你没有必要可以不使用。
Twitter的Tweet按钮依赖于script和frame，都来自于https://platform.twitter.com（Twitter默认提供的是相对URL，请在复制的时候编辑代码来指定为HTTPS方式）。
