如何理解主流网站使用的Content-Security-Policy(CSP)规则

1. Facebook的default-src同时存在*和'self'的问题 #

首先明确CSP的核心规则：同一指令下的所有源规则是「或」的并列允许关系，不存在后写的规则覆盖先写规则的逻辑，只要请求满足任意一个列出的源条件，就会被放行。
你观察到的default-src * data: blob: 'self';写法里，'self'确实已经被通配符*的覆盖范围包含，出现冗余的常见原因有3个：

• 大公司的CSP规则通常是多业务模块动态拼接生成的：比如基础安全模块先统一添加了'self'作为基础规则，后续全局兼容模块又添加了*覆盖更广泛的场景，构建过程没有做冗余规则去重，就会同时出现两个条目。
• 过渡阶段的兜底设计：部分团队会先保留'self'，后续逐步下线通配符*的规则时，不用修改其他逻辑就能保证基础同源请求正常，降低规则调整的故障风险。
• 你担心的通配符安全风险在这里影响很小：Facebook的CSP已经单独声明了script-src/style-src/connect-src这些高风险资源的专属规则，default-src的*只会作用于没有单独声明的低风险资源类型，不会直接导致严重安全问题。

2. Twitter的script-src同时存在nonce和'unsafe-inline'的问题 #

这个写法不是冗余，是行业通用的向下兼容最佳实践，完全符合CSP标准规范：
CSP2及以上版本的标准明确规定：当script-src指令中存在有效的nonce或者hash值时，支持该规范的现代浏览器会自动忽略'unsafe-inline'规则，不会有inline脚本执行的安全风险，nonce的安全防护作用完全不受影响。
而对于不支持nonce特性的老旧浏览器（占比已经极低，但部分下沉场景仍有覆盖需求），会无法识别nonce字段，这时候'unsafe-inline'就会生效，保证页面功能在旧浏览器上正常运行，兼顾了安全性和兼容性。

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