动态加载CSS的CSP疑问：是否有替代unsafe-inline的合规方案？

首先明确一点：目前CSP规范中，并没有针对style-src的strict-dynamic等效机制——strict-dynamic是专门为script-src设计的，用于信任由已验证脚本加载的后续脚本，样式方面暂时没有类似的链式信任规则。不过我们有几种可行的方案来绕过unsafe-inline的要求，具体如下：

1. 使用nonce或hash精准允许特定内联样式 #

如果第三方生成的内联样式内容是可预测的（或者你能提前获取到它的内容），可以通过以下两种方式授权：

• 哈希授权：计算内联样式内容的SHA-256/SHA-384/SHA-512哈希值，将其添加到style-src指令中。例如：

  Content-Security-Policy: style-src 'sha256-abc123xyz...';
  

  部分浏览器需要搭配'unsafe-hashes'前缀使用，完整写法是：

  Content-Security-Policy: style-src 'unsafe-hashes' 'sha256-abc123xyz...';
  

• Nonce授权：如果第三方脚本支持动态携带nonce，你可以在页面加载时生成一个随机nonce，同时在CSP和第三方创建的<style>标签中添加这个nonce属性。比如：

  <style nonce="随机生成的nonce值">...</style>
  

  对应的CSP指令：

  Content-Security-Policy: style-src 'nonce-随机生成的nonce值';
  

  不过这个方案需要第三方服务商配合修改脚本，自动获取父窗口的nonce并应用到创建的样式标签上。

2. 隔离第三方内容到独立沙箱域名 #

将第三方iframe部署到一个独立的子域名（比如thirdparty.yourdomain.com），并为这个子域名单独设置宽松的CSP（允许它自己的内联样式）。同时，限制父页面的CSP仅信任主域名的资源，避免第三方操作影响主页面的安全策略。

• 前提是第三方脚本不需要直接操作父页面的DOM样式，或者可以将所有样式逻辑封装在iframe内部。如果第三方必须在父窗口创建样式，这个方案可能不适用。

3. 要求第三方修改实现方式 #

最彻底的解决方案是和第三方服务商沟通，让他们将内联样式改为外部CSS文件的形式。这样你只需要在CSP的style-src中添加第三方CSS文件的域名即可，完全不需要unsafe-inline：

Content-Security-Policy: style-src 'self' https://thirdparty-domain.com;

这种方式既符合CSP的安全原则，也避免了后续的兼容性问题，是优先推荐的方案。

4. 临时妥协：使用unsafe-hashes（如果哈希可预测） #

如果第三方生成的内联样式内容是固定的，unsafe-hashes是比unsafe-inline更安全的妥协方案——它只允许特定哈希值匹配的内联样式，而不是所有内联样式。这在无法推动第三方修改的情况下，是相对安全的替代选择。

内容的提问来源于stack exchange，提问作者kddeisz