CSP非后缀通配符需求：限制引入带版本号的可信CDN脚本

一、当前浏览器原生机制的局限 #

目前CSP只支持前缀匹配、域名通配符这类粗粒度规则，没法直接实现URL必须包含@x.y.z格式完整版本号的校验。就像你提到的，用https://cdn.jsdelivr.net/npm/作为前缀规则，会同时放行带版本和不带版本的URL，满足不了你的不可变需求。

二、可行的创意替代方案 #

1. 沙箱代码预处理+API拦截 #

在用户代码加载进iframe前，先做一层预处理：

• 解析代码里所有<script>标签的src属性，校验是否符合https://cdn.jsdelivr.net/npm/[包名]@[x.y.z]/的格式
• 不符合规则的直接拦截，或者把src替换成无效地址
• 还要防范用户动态创建脚本绕过：在沙箱里注入钩子，拦截document.createElement('script')、fetch这类能加载脚本的API，对动态生成的URL做同样校验

2. 服务端中转校验 #

如果你的应用有服务端，可以做中转代理：

• 用户要加载的CDN脚本，先经过服务端校验URL格式，确认带完整版本号
• 校验通过后，服务端把脚本内容转发给沙箱iframe
• 此时CSP设置成只允许从你的域名加载脚本，彻底杜绝用户访问不符合规则的资源
• 缺点是会增加服务端的带宽消耗和维护成本

3. SRI结合格式校验优化 #

虽然你提到生成integrity hash有项目约束，但可以结合CDN特性调整：

• 带完整版本号的jsdelivr资源内容固定，你可以预先获取对应版本的SRI哈希，或者服务端实时获取
• 用户提交代码后，自动给符合格式的<script>标签加上integrity和crossorigin属性
• 配合CSP的require-sri-for script规则，确保只有带有效SRI的脚本能加载；不带版本的URL因为内容可变，没法生成稳定SRI，自然会被拦截

三、CSP未来规范的可能性 #

目前W3C的CSP工作组确实讨论过更精细的匹配规则，比如支持正则或路径特定模式，但暂时还没纳入正式规范的时间表。这类需求属于场景明确的小众安全需求，你可以通过W3C的GitHub仓库提交issue或参与讨论，推动相关功能落地。

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