目前我正在定义内容安全策略（CSP），如下所示;
Header set Content-Security-Policy: "default-src 'self' data:; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data:;"
考虑到上面的CSP定义，我对内联JavaScript提出了挑战，因为它可以在任何时候被覆盖。
如果unsafe-inline几乎无法保护，有什么用？
当您在当前站点中移动或重写内联代码不是一个直接的选项但您仍然希望使用CSP来控制其他方面（例如object-src，防止注入第三方j等）时使用unsafe-inline选项。你是正确的，unsafe-inline不提供太多的安全性，因为它允许执行不安全的页内脚本和事件处理程序。
谷歌的CSP Evaluator是一个很好的工具，可以确定你的政策是否强大。
使用unsafe-inline选项的用例可以在Google的Web Developer documentation on Content Security Policy中找到：
婚戒讨论论坛管理员希望确保所有资源仅通过安全渠道加载，但实际上并没有编写太多代码;重写大量的第三方论坛软件，这些软件充满了内联脚本和风格，超出了他的能力范围。以下政策将有效：
Content-Security-Policy: default-src https:; script-src https: 'unsafe-inline'; style-src https: 'unsafe-inline'即使在
https:中指定了default-src，脚本和样式指令也不会自动继承该源。每个指令都完全覆盖该特定类型资源的默认值。
虽然我同意它并没有太大的保护，但XSS的经典开发是浏览器开发框架，你在互联网上有一台服务器，当你得到一个XSS漏洞时，你可以访问“http://bad.example.com /hook.js“>现在您可以从该服务器控制受害者的浏览器。你告诉它打开一个隐藏的窗口来持久访问，然后你有他们的浏览器的双向通信。
具有“不安全内联”的CSP仍然可能允许所有相同的利用（假设漏洞适合您可以注入的空间），但是连接外部世界接收指令或泄露数据的难度稍大。
这就是说，如果你可以在网页中注入足够复杂的客户端部分，我认为仍然可以通过其他渠道进行大多数相同的攻击。
我的攻击者帽子“自我不安全 - 内联”比没有CSP更难开发。我希望攻击工具能够适应弱的CSP，但这意味着很多常见的漏洞会立即出现，或者更难。