目前我正在定义内容安全策略（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实际上无法保护，有什么用？
答案 0 :(得分：21)
当移动或重写当前站点中的内联代码不是一个直接选项时，使用unsafe-inline选项，但您仍然希望使用CSP来控制其他方面（例如object-src，防止注入第三方js等）。你是正确的unsafe-inline不提供太多安全性，因为它允许执行不安全的页内脚本和事件处理程序。
Google的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，脚本和样式指令也不会自动继承该源。每个指令都完全覆盖该特定类型资源的默认值。
答案 1 :(得分：7)
虽然我同意它并没有太大的保护，但XSS的经典利用是浏览器开发框架，你在互联网上有一台服务器，当你得到一个XSS漏洞时，你会掉进“http：// bad。 example.com/hook.js">现在，您可以从该服务器控制受害者的浏览器。你告诉它打开一个隐藏的窗口来保持访问权限，然后你的浏览器就会有双向通信。
具有“unsafe-inline”的CSP仍然可能允许所有相同的利用（假设漏洞适合您可以注入的空间），但是连接外部世界以接收指令或泄露数据的难度更大
那就是说我认为如果你可以将足够复杂的客户端部分注入网页，仍然可以通过其他渠道进行大多数相同的攻击。</ p>
我的攻击者帽子“自我不安全 - 内联”比没有CSP更难开发。我希望攻击工具能够适应弱弱的CSP，但这意味着许多常见漏洞会立即出现，或者更难。