Content Security Policy配置问题：unsafe-inline/eval替代方案及图片报错修复

一、替代'unsafe-inline'和'unsafe-eval'的安全方案 #

直接使用这两个指令确实会大幅削弱CSP的安全防护能力，推荐按优先级尝试以下替代方案：

• 迁移内联代码到外部文件
  这是最彻底的解决方案：把页面中直接编写的<script>代码移到独立的.js文件，内联<style>或style属性的样式移到.css文件。完成后你可以完全移除'unsafe-inline'，同时确保script-src和style-src只信任指定的外部域名与'self'。

• 使用哈希（Hashes）允许特定内联脚本/样式
  如果必须保留少量内联代码，可以计算该代码的哈希值（支持SHA-256、SHA-384、SHA-512），将其添加到对应的CSP指令中。例如：

  # 假设内联脚本的SHA-256哈希值为abc123xyz...
  script-src 'self' 'sha256-abc123xyz...' https://unpkg.com/sweetalert/dist/sweetalert.min.js ...;
  

  浏览器会验证内联代码的哈希是否与CSP中声明的一致，一致才允许执行，安全性远高于'unsafe-inline'。

• 使用随机Nonce（一次性令牌）
  为每个HTTP请求生成唯一的随机字符串（nonce），将其添加到CSP的script-src/style-src中，同时在对应的<script>/<style>标签上添加nonce属性。例如：

  # 假设生成的nonce为随机字符串random123
  script-src 'self' 'nonce-random123' https://unpkg.com/sweetalert/dist/sweetalert.min.js ...;
  

  页面中的脚本标签：

  <script nonce="random123">/* 内联代码 */</script>
  

  Nonce是一次性的，每次请求都会变化，攻击者无法复用，安全性极高。

• 替换依赖中的eval使用
  如果'unsafe-eval'是因为第三方库使用了eval或类似动态执行代码的方式（如new Function()），可以查看该库是否提供了不依赖eval的构建版本。比如很多前端模板引擎都有“无eval”的替代方案，优先选择这类版本来移除'unsafe-eval'。

二、修复data:image/svg...图片加载报错 #

从你的CSP规则来看，img-src已经包含了data:，理论上应该允许data:image/svg+xml这类图片资源加载。出现报错可能有以下几种原因，对应解决方案：

• 检查是否是CSS背景图的引用
  如果报错的SVG是作为CSS中的background-image引用的，除了确保img-src允许data:，还要确认style-src允许加载对应的样式文件（你的规则中style-src已经包含必要域名，这部分应该没问题）。部分浏览器对CSS中引用的data URI可能需要额外确认，但一般只要img-src包含data:即可正常加载。

• 验证CSP规则的拼写与缓存
  检查你的img-src指令是否有拼写错误（比如把data:写成dat:），同时强制刷新浏览器缓存（Ctrl+F5），确保浏览器加载的是最新的CSP规则，而非旧的缓存版本。

• 确认SVG资源的上下文
  如果SVG是通过<object>或<embed>标签加载的，你的object-src 'none'会阻止它。这种情况下需要将SVG改为<img>标签加载，或者在必要时调整object-src（不推荐，除非是业务必需场景）。

如果以上操作都没问题，可以尝试更新img-src指令，明确指定data:image/svg+xml（虽然data:已经包含所有data URI，但有些场景下明确指定可能解决兼容性问题）：

img-src 'self' data:image/svg+xml data: https://secure.gravatar.com;

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