CSP 生成
勾选各条指令与来源，生成 Content-Security-Policy 的响应头值、Content-Security-Policy-Report-Only 与 <meta> 写法，附严格 / 宽松 / 报告三种预设和 unsafe-inline、unsafe-eval、通配符风险提示。
浏览器本地运行所有计算都在你的浏览器里完成，数据不会离开本机。
预设与输出格式
指令顺序、取值语法与 meta 里会被忽略的指令都按 W3C CSP Level 3 与 MDN 文档实现；页面不发任何请求。
指令
勾选要输出的指令，多个来源用空格分隔；'none' 必须单独使用，report-uri / report-to 填一个 URL 或 / 开头的路径。
生成结果
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self'; connect-src 'self'; media-src 'self'; object-src 'none'; frame-src 'self'; frame-ancestors 'self'; base-uri 'self'; form-action 'self'; manifest-src 'self'; worker-src 'self'; upgrade-insecure-requests
32215<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self'; connect-src 'self'; media-src 'self'; object-src 'none'; frame-src 'self'; base-uri 'self'; form-action 'self'; manifest-src 'self'; worker-src 'self'; upgrade-insecure-requests">
没有出现 'unsafe-inline'、'unsafe-eval' 或通配符。
这个工具能做什么
- 给站点加安全响应头时不想手写一长串指令：勾选 default-src、script-src 等指令，来源用快捷项点选，直接拿到可粘贴的 Content-Security-Policy 值。
- 排查「加了 CSP 之后页面白屏」：用报告模式先只上报不拦截，把 report-uri 指到自己的收集端点，确认没有误伤再切回强制模式。
- 给静态站点（没有响应头可改）生成 meta http-equiv="Content-Security-Policy" 标签，工具会自动去掉 meta 里不生效的指令。
- 代码评审时检查别人的策略：把来源粘进来，看有没有 unsafe-inline / unsafe-eval / 通配符这类等于没加的口子。
示例
输入
选择「严格」预设（default-src 'self'、script-src 'self'、style-src 'self'、img-src 'self' data:、object-src 'none'、upgrade-insecure-requests 等）
输出
default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self'; connect-src 'self'; media-src 'self'; object-src 'none'; frame-src 'self'; frame-ancestors 'self'; base-uri 'self'; form-action 'self'; manifest-src 'self'; worker-src 'self'; upgrade-insecure-requests
严格预设共 15 条指令。切到 meta 标签时 frame-ancestors 会被去掉（浏览器在 meta 里忽略这条指令），所以 meta 形式只剩 14 条。
常见问题
加了 CSP 之后页面白屏，怎么排查？
先换成「报告模式」：策略一样，但用 Content-Security-Policy-Report-Only 头，浏览器只上报不拦截，站点不会坏。把 report-uri 指向自己的收集端点，看被拦的到底是哪些资源，补进白名单后再换成强制模式。
为什么不能直接加 unsafe-inline？
unsafe-inline 允许页面里的内联脚本执行，而 XSS 注入的正是内联脚本，等于把 CSP 最有价值的那层防护让出去了。真要允许内联，用 nonce-… 或 sha256-… 白名单：脚本标签带对 nonce 才执行，攻击者注入的脚本拿不到这个随机值。
CSP 写在 meta 里和写在响应头里有什么区别？
写在 meta 标签里只能用在没法改响应头的静态站点，而且 frame-ancestors、sandbox、report-uri、report-to 这四条在 meta 里会被浏览器忽略（本工具会自动去掉并提示）。另外 meta 形式的 CSP 生效更晚，某些预加载的资源可能已经发出去了，能改响应头就优先用响应头。
report-uri 和 report-to 该填哪个？
report-uri 是旧写法，直接给一个接收 POST 的地址，兼容性最好；report-to 是 CSP3 的写法，需要在响应头里另配 Report-To 组，但能上报更多字段。两个都写不冲突，老浏览器用 report-uri，新浏览器优先 report-to。
default-src 和 script-src 同时写会冲突吗？
不会。default-src 是所有「没单独写」的指令的兜底值，一旦写了 script-src，脚本就按 script-src 走，default-src 不再参与脚本判定。所以最稳的写法是先给一条比较紧的 default-src，再按需要逐条放开。
关键词：cspcontent security policycsp generatorsecurity headerunsafe-inlinexssCSP 生成内容安全策略安全响应头跨站脚本指令来源白名单