跳到正文

CSP 内容安全策略生成

CSP Builder

按引导表单或一份违规报告生成 Content-Security-Policy,并逐条解释每个指令。

Content-Security-Policy 这个响应头能把一个跨站脚本漏洞从“被攻陷”变成“控制台里一条被拦截的消息”,它也是最常以一种什么都不做的形式上线的响应头。这里逐条指令地搭建它,并解释每一条实际在防什么。

🔒 完全在你的浏览器里运行cspheaderswebgenerator
载入现有策略

你没有单独设置的取回类指令,都回落到它。

脚本可以从哪里加载。真正挡住 XSS 的就是这一条。

样式表可以从哪里加载。

图片可以从哪里加载。

字体可以从哪里加载。

fetch、XHR、WebSocket 和 EventSource 可以连到哪里。

<audio> 和 <video> 可以从哪里加载。

<object>/<embed> 可以从哪里加载。一般设成 'none' 最省事。

<iframe> 里的文档可以从哪里加载。

谁可以把这个页面放进框架——X-Frame-Options 的现代替代品。

<base href> 可以被设成什么。限制到 'self' 或 'none'。

表单可以提交到哪里。

Worker、SharedWorker 和 service worker 可以从哪里加载。

Web 应用清单可以从哪里加载。

把 http:// 的子资源请求改写成 https://。

直接拦掉所有 http:// 子资源(旧规范)。

  • ⚠ 没有 frame-ancestors:加上它(比如 'none' 或 'self')来决定谁能把这个页面放进框架。
  • ⚠ 没有 base-uri:加一条 base-uri 'self',挡住 <base> 标签注入。

Content-Security-Policy

default-src 'self'; script-src 'self'

怎么用

  1. 从表单或者从报告开始

    引导式表单会问脚本、样式、图片和连接各来自哪里。如果你已经有违规报告,把它们粘进来,来源就从实际加载过的东西里推导出来。

  2. 先以仅报告模式部署

    `Content-Security-Policy-Report-Only` 只记录违规,不拦截。跑上一周,报告会点出那个谁都不记得的第三方嵌入。

  3. 最后再去掉 `unsafe-inline`,而且要去得干净

    带着 `script-src 'unsafe-inline'` 的策略几乎什么都拦不住。换成每次响应一个 nonce,或者内联块的哈希——两种形式工具都能生成。

常见问题

这个工具会测试我的站点吗?

不会。它根据你告诉它的内容来组合并解释一份策略。检查一个在线站点当前发送了什么,是安全响应头体检工具的活。

为什么我的策略还是允许内联脚本?

出于向后兼容,当 `unsafe-inline` 和 nonce 或哈希同时出现在 `script-src` 里时,nonce 和哈希会被忽略。两者不能都留——回退的那个会赢。

只写 `default-src 'self'` 够吗?

它是个不错的基础,但有几条指令不会回退到它——`frame-ancestors`、`form-action` 和 `base-uri` 就在其中。这些必须显式设置,这个工具会设置它们。

可以从这些接进来

接下来

这些工具吃得下当前工具的产出,结果可以直接送过去。