CSP 以及 HTTP cookie 安全标志、HSTS 和 X-FRAME-OPTIONS 将永远是我最喜欢的 HTTP 响应标头，用于始终提高用户的安全性。

另请参阅 --在 Web 应用程序中启用浏览器安全性

我认为这种机制只有在特定的情况下才有真正的价值。

在一般情况下，对于常规 Web 应用程序，您最好将代码修复为 XSS 安全，正如@SteveS 所写的那样。

但是，在某些情况下，这并不容易实现，并且这些情况越来越受欢迎。我指的是“用户生成的内容”，您需要允许用户输入（几乎）任何数据，包括任意 HTML 内容 - 博客、社交网站、CMS 等......

现在，我的安全专业部分正在为此感到畏缩，我马上想跳起来大喊：“不，你不需要这样做，找到更好的方法！”。但是，这当然不是重点......
而且是的，有一些迂回的方法可以避免这种情况，让用户输入任意 HTML - 将某些标签列入白名单，或使用替代标记系统（如此处使用的Markdown） - 但那些有点杂乱无章，功能有限，对某些最终用户来说并非微不足道。

归根结底，将有一些 webapps 将接受任意 HTML，无论出于何种原因，业务认为有必要，并且大喊它是多么不安全可能会适得其反，因为这根本行不通。
在这些情况下，内容安全策略可以增加巨大的价值，并在很大程度上缓解 XSS 特性。

从理论上讲，这是一个好主意，但我认为要问的更重要的问题是：这解决了什么问题？我可以看到它使防止 XSS 的工作变得更容易，但是您仍然需要动态生成 JavaScript，因此您只需攻击 .js 文件，而不是攻击页面本身。但是您说的是静态 .js 文件...

我的猜测是，它比它的价值更麻烦。最好将代码重写为 XSS 安全，而不是依赖浏览器做任何事情。