我正在考虑在多个站点中实施CSP。
如果我不这样做会有什么风险？
问题的原因是实施CSP会带来自身的风险-不必要地阻止某些OS的浏览器，每次都必须包括新添加的外部资源等。
这值得么？
最佳答案
CSP是一个非常有用且可能非常简单的工具。我强烈建议每个人都实现它，即使必须使用一些不太理想的设置(例如unsafe-inline)。
风险性
CSP中的唯一风险是维护CSP列表，因此，如果您无法维护列表，则可能会意外地阻塞资源。
由于CSP，在旧版浏览器中不会失去功能。与大多数现代Web技术一样，CSP是“渐进式增强”，如果您甚至在不支持CSP的古老浏览器上使用疯狂严格的现代CSP访问网站，唯一的结果就是CSP被完全忽略了。旧的浏览器与阻止访问者完全相反。他们将被允许访问任何东西，就像根本不存在CSP一样(因为据浏览器所知，它根本不存在)。
困难
实施CSP的难度完全取决于您的设置以及您想要变得多么挑剔。如果您的站点纯粹是单一来源的，并且不使用任何第三方代码，则可以在5分钟内启动并运行具有最大限制但功能完整的CSP。
第三方和遗留代码的数量是花费多少时间的主要因素。您网站的起源和内联样式/脚本越多，它就会变得越复杂和令人沮丧。但这也是重构的好机会。
可以使用CSP进行挑剔的一些著名，流行的代码库是Wordpress(很多顽皮的插件和带有内嵌脚本/样式的主题)和Google Adsense(几乎无法知道从何处加载脚本，基本上需要unsafe-inline)。
好处
XSS(跨站点脚本)保护
在这一点上，CSP可以提供比传统XSS更大的保护，但是它为客户端浏览器增加了一种确切了解允许和禁止的方式。例如，如果某个用户将您的网站加载到试图插入比特币挖掘javascript文件的恶意 public wifi网络上，则您可以拒绝该文件。当然，CSP应该与强制HTTPS配对以确保
它甚至可以(部分)保护您免受恶意浏览器扩展的影响(当然，如果在访问您之前客户端的PC已经受到威胁，则CSP来不及保存它们)。即使您的页面有所更改，某些注入(inject)了恶意软件的脚本也将拒绝加载。
CSP当然是一种安全策略，因此安全是主要优势。它的特殊之处在于，它允许严格而随意的精细控制，分别阻止或允许框架，字体，脚本，样式等，或者允许所有内容，或者允许仅允许一个文件中的单个文件起源而不是信任整个领域。
推广良好做法
CSP面临的最大问题实际上是令人讨厌的，挑剔的第三方代码。使用不安全的内联样式和eval()填充的东西，从8个不同原始服务器上的10个不同文件中加载，所有文件的名称都没有发音错误的描述性名称。
虽然将所有这些糟糕的事情列入白名单很烦人，但通过提出实际问题，CSP应该有助于鼓励第三方清理坦率，讨厌，不安全和性能不佳的代码。当然要花一些时间(由于Adsense和Adwords如何使用脚本处理区域，因此Google在大多数网络领域的前瞻性思维是最严重的违规者之一)。
CSP将帮助您认识到从一致的来源提供所有内容的价值，甚至可能向第三方供应商提出投诉，以三十个额外的请求来加载您的网站，以加载图像文件和一些文本。
正在报告
真正了解您的网站在野外而不是在受控测试环境中会发生什么事情可能会很痛苦，但是使用report-uri(或不久之后，report-to)，您实际上可以收到用户自己看到的违反CSP的报告。当您的CDN或脚本“有效地”将不同的资源交付给不同的用户时，这将有所帮助。
实作
我强烈建议您使用Mozilla Observatory测试您的集合，以检查您的常规安全 header 并发现问题，并且Google Chrome浏览器的浏览器工具特别擅长报告违反CSP的行为(甚至在需要时为资源提供SHA哈希)。
关于http-headers - 内容安全政策-值得吗？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/43802161/