CSP安全策略生成器

本地处理

打赏支持
分享链接
反馈建议

指令	允许的来源（空格分隔，留空表示不在策略中出现）
default-src
script-src
style-src
img-src
connect-src
font-src
media-src
object-src
base-uri
form-action
frame-ancestors

策略会显示在这里

meta 标签写法会显示在这里

常用来源关键字
'self' 同源；'none' 禁止全部；data: 内联数据 URI；https: 任意 https 源
'unsafe-inline' 允许内联脚本或样式（降低安全性）；'unsafe-eval' 允许 eval（降低安全性）
nonce-随机串与 sha256-哈希用于精确放行特定内联脚本

先上报告模式再收紧：把策略名改为 Content-Security-Policy-Report-Only 配合 report-uri 收集违规日志，确认没有误伤后再切换为强制生效，否则很容易把站点自己的脚本一起拦掉。

关于本工具

内容安全策略（CSP）是防 XSS 最有性价比的一道防线：浏览器只加载策略允许的来源，被注入的恶意脚本就无处执行。但指令多、语法细，手写容易漏掉一条导致站点白屏。

如何使用

逐条填写你允许的来源（留空的指令不会写进策略）。不确定从哪开始时，先点「填入严格策略」，再用浏览器的控制台看哪些资源被拦，按提示补上对应来源。

常见问题

为什么 default-src 最重要？它是所有未单独声明指令的兜底。有了 default-src 加 object-src 的 'none'，可以挡掉最常见的注入与插件型攻击。

'unsafe-inline' 一定要用吗？尽量不用。若站点有内联脚本，改用 nonce 或哈希放行，安全性会高得多；'unsafe-inline' 会让 CSP 对 XSS 的防护效果大打折扣。

你可能还想问

为什么加上 CSP 后页面部分功能失效？

通常是内联脚本、内联样式或第三方资源被拦截；先以 Report-Only 模式跑一段时间收集违规报告，再逐步放行所需来源，避免一刀切。

unsafe-inline 会不会让 CSP 失去意义？

会大幅削弱 XSS 防护。更好的做法是给脚本加 nonce 或 hash 替代 unsafe-inline；确实必须内联的样式可暂时允许，脚本不建议放行。

CSP 能防哪些攻击？

主要缓解 XSS 与内容注入：限制脚本、样式、图片、iframe 的加载来源；它不能替代输出转义与 HTTPS，只是纵深防御的一层。