CSP 生成器
勾选指令和来源，本页会为你拼出一行正确的 Content-Security-Policy，可用于响应头或 <meta> 标签 —— 并附上真正要紧的提醒：哪些指令绝不回退到 default-src、哈希或 nonce 何时会悄悄覆盖 unsafe-inline、以及 strict-dynamic 会关掉什么。内置的 SHA-256/384/512 哈希生成器能把内联脚本和样式变成 'sha256-…' 来源。全部在你的浏览器里运行；不上传任何内容。
未勾选的指令不会出现在策略里；勾选了却没选任何来源的指令会被忽略。'none' 会取消同一行里其它勾选。额外来源框接受逗号分隔的列表：主机名（cdn.example.com）、协议（https:）、哈希和 nonce，带不带引号都可以。
这四条不会回退到 default-src：省略它们就意味着“不限制”，所以一份完整的策略会显式设置它们。
还没有生成任何内容。勾选一些来源后按生成策略，或载入 OWASP 基线示例。
把 <script> 与 </script>（或样式块）之间的内容逐字节粘贴进来——不要多出开头或结尾的换行——然后选择一个算法。结果就是 CSP 3 要求的 'sha256-…' 来源。
哈希结果会显示在这里。
只要有可能，就用响应头而不是 meta 标签部署。响应头才是完整的 CSP：
frame-ancestors、
report-uri 和
report-to 只在响应头里生效，而且响应头在第一个字节的 HTML 被解析之前就已生效。meta 标签只是无法配置服务器时的静态文件兜底方案。本站的
安全响应头检查可以查看你站点实际发出的响应头，
HTTP 响应头解析器则可以逐段拆解原始响应块。
自测
用一组固定状态重跑构建器：来源排序、'none' 互斥、OWASP 基线字符串、nonce 与哈希的引号处理、base-uri / form-action / frame-ancestors 的无回退提醒、nonce 或哈希覆盖 unsafe-inline、strict-dynamic 提醒、Report-Only 响应头名称、meta 标签排除项、用独立计算的 SHA 向量校验哈希生成器，以及各条失败路径。不会向任何地方发送数据。
什么是 Content Security Policy？
一句话：CSP 是服务器随页面一起发出的一份白名单，它告诉浏览器脚本、样式、图片和连接究竟可以从哪里来 —— 这样一来，即使攻击者注入了 HTML，被注入的脚本依然加载不了，因为它的来源不在名单上。
三类指令
| 类别 | 示例 | 控制什么 | 会回退到 default-src 吗？ |
|---|
| 抓取指令 | script-src、style-src、img-src、connect-src、font-src、object-src、frame-src、worker-src、media-src、manifest-src | 各类内容可以从哪里加载 | 会 —— 未勾选的指令继承 default-src |
| 文档指令 | base-uri、form-action、frame-ancestors、sandbox | 页面自身可以做什么（能否被嵌入、表单能提交到哪、相对 URL 基于什么解析） | 不会 —— 每一条都必须显式设置 |
| 上报与其它 | report-uri、report-to、upgrade-insecure-requests | 违规报告发往哪里，以及旧式 URL 的升级 | 不会（它们不是抓取指令） |
最尖锐的几个坑，每段一个
'unsafe-inline' 与哈希、nonce 的博弈。如果一条指令里包含 nonce 或任意哈希来源，CSP 3 规定 'unsafe-inline' 会被忽略 —— 它留在那里只是为了照顾非常老的浏览器。这就是为什么“我们加了 nonce，但为了保险还留着 unsafe-inline”实际上意味着现代浏览器只认 nonce。本生成器会把这种组合标出来，让它变成一个主动决定，而不是无心之失。
strict-dynamic 会废掉你的白名单。在 script-src 里写上 strict-dynamic 后，主机来源、协议、'self'、'unsafe-inline' 和 data: 在加载脚本时全部被忽略；只有 nonce 和哈希起作用，而且由可信脚本加载的脚本还能继续加载更多脚本。这是运行加载器脚本的现代做法 —— 但它也让你 script-src 列表里剩下的内容变成了摆设。
meta 标签是二等公民。frame-ancestors、report-uri 和 report-to 在 <meta http-equiv> 里会被忽略。本生成器会指出你的策略里哪些部分会静默失效。
常见错误
- 从
default-src * 起步，再挂一长串例外。应该反过来：先设一个收紧的 default-src 'self'，然后只放宽确实需要放宽的指令。收得紧的策略会在测试期间响亮地失败；放得宽的策略会永远静默地失败。
- 发一份
script-src 'unsafe-inline' 'unsafe-eval' 就算完事。这样的策略几乎拦不住 XSS 攻击想做的任何事。给你的脚本加 nonce 或哈希，加上 strict-dynamic，并在生产环境持续运行 report-only 以便发现回归。
- 忘了
default-src 并不能覆盖一切。base-uri、form-action、frame-ancestors 和 sandbox 都没有回退机制 —— 这是真实世界 CSP 部署中最常被提到的漏洞。
- 一上来就用强制模式测试。先带上报收集器跑一周 Report-Only，读完报告再切到强制执行。一个把结账流程搞坏的策略，比没有策略更糟。
- 哈希时把空白字符算错了。哈希覆盖的是内联块的精确字节；某个“顺手”去掉结尾换行的构建步骤会让每一个哈希都失效。请对实际发布出去的内容生成哈希，而不是对源码生成。
常见问题
如果我把每条指令都列出来了，还需要 default-src 吗？不需要，但把它当底线留着是好习惯：未来浏览器里新增的抓取指令就会默认走你的基线，而不是默认“允许”。
upgrade-insecure-requests 到底做了什么？它告诉浏览器把页面要加载的每一个 http:// URL —— 图片、样式、fetch —— 在发起请求之前改写成 https://。它是迁移工具；最终目标应该是页面上根本没有 http:// 链接。
用 nonce 还是哈希？能控制服务器响应时用 nonce（每次响应一个随机值，响应头和每个 script 标签里都要有）。HTML 是静态或被缓存时用哈希。永远不要用固定 nonce —— 不变化的 nonce 只是绕了远路的 unsafe-inline。
为什么策略发出去了却收不到违规报告？检查你是不是处于 Report-Only（只上报）；检查 report-uri 是否指向一个接受 POST 的收集器；还要检查你是否同时配置了现代 report-to 指令所要求的 Reporting-Endpoints / Report-To 机制。
CSP 能替代其它防护措施吗？不能。它只是其中一层：继续转义你的输出、继续给 Cookie 加 HttpOnly 和 Secure、继续启用 HSTS。本站的 安全响应头检查会对整套防护做评分。
