我正在考虑在多个网站上实施CSP ..
如果不这样做会有什么风险？
问题的原因是实施CSP带来了它自己的风险 - 不必要地阻止某些操作系统的浏览器，每次都必须包含新增的外部资源等。
值得吗？
答案 0 :(得分：2)
CSP是一个非常有用且可能非常简单的工具。我强烈建议每个人都实施它，即使必须使用一些不太理想的设置，如unsafe-inline。
CSP中唯一的风险是维护CSP列表，因此，如果您无法维护列表，可能会意外阻止资源。
由于CSP，不可能在旧浏览器中丢失功能。与大多数现代网络技术一样，CSP是一种渐进式增强功能。如果你在一个不支持CSP的古老浏览器上使用一个疯狂严格的现代CSP访问一个网站，唯一的结果就是CSP被完全忽略了。旧的浏览器将完全阻止访问者;他们将被允许访问任何内容，就像CSP根本不存在一样（因为，据浏览器所知，它不是）。
实施CSP的难度完全取决于您的设置以及您想要的挑剔程度。如果您的站点纯粹来自单一来源并且不使用第三方代码，那么您可以在5分钟内启动并运行最大限制但功能完备的CSP。
第三方和遗留代码的数量是需要多长时间的主要因素。您的网站拥有的内容和内联样式/脚本越多，它就越复杂和令人沮丧。但这也是重构的好机会。
一些值得注意的流行代码库，可以通过CSP挑选Wordpress（许多顽皮的插件和主题内联脚本/样式）和Google Adsense（几乎不可能知道脚本将从何处加载而unsafe-inline将基本上是必需的。）
XSS（跨站点脚本）保护
此时CSP可以防止超过传统的XSS，但它为客户端浏览器添加了一种方法，可以准确地知道允许的内容和不允许的内容。例如，如果用户将您的网站加载到试图插入比特币挖掘javascript文件的恶意公共wifi网络上，则可以拒绝该网站。当然，CSP应该与强制HTTPS配对以确保
它甚至可以保护您（部分）免受恶意浏览器扩展（当然，如果客户端的PC在访问之前已经受到攻击，那么您的CSP来不及保存它们）。即使您的页面以某种方式被更改，某些恶意软件注入的脚本也将拒绝加载。
CSP当然是一种安全策略，因此安全性是主要的好处。它的特殊之处在于允许一个令人印象深刻的粒度控制，如你所愿，严格或松散，阻止或允许框架，字体，脚本，样式等所有单独的，广泛地允许一切或狭窄只允许一个来自原始的单个文件，而不是信任整个域。
宣传良好做法
你对CSP最大的问题是非常讨厌，挑剔的第三方代码。使用不安全的内联样式和eval()输出wazoo，从8个不同的原始服务器上的10个不同文件加载，所有文件都有不可发音的不同名称。
虽然将所有这些糟糕的事情列入白名单是令人讨厌的，但通过提出实际问题，CSP应该有助于鼓励第三方清理他们坦率的，不安全和不可靠的代码。它需要一段时间（谷歌，因为他们在大多数网络前沿的所有前瞻性思维，是由于Adsense和Adwords如何使用他们的脚本处理区域而成为最严重的罪犯之一）。
CSP将帮助您了解从一致的来源提供所有内容的价值，甚至可能会向第三方供应商提出投诉，因为有三十个额外的请求需要加载图像文件和一些文本。< / p>
<强>报告
实际上知道您的网站在野外发生了什么而不是在受控测试环境中可能会很痛苦，但是report-uri（或很快，report-to）您实际上可以收到有关CSP的报告用户看到的违规行为。当您的CDN或脚本有用时，这可以提供帮助。为不同的用户提供不同的资源。
我强烈建议您使用Mozilla Observatory测试您的设置，以检查您的常规安全标头并发现问题，而Google Chrome浏览器工具尤其擅长报告CSP违规行为（即使为资源提供SHA哈希也应如此你想要他们。）