iframe的csp配置本质是frame-src指令,用于控制父页面允许嵌入哪些外部源,需在tauri.conf.json中以json格式显式声明,不继承default-src,且必须精确匹配协议、域名与子域名。

iframe 的 CSP 配置本质是 frame-src 指令,不是给 iframe 标签加属性
HTML 的 <iframe></iframe> 标签本身没有叫 csp 的属性——这是常见误解。真正起作用的是 HTTP 响应头或 <meta> 标签里的 Content-Security-Policy 中的 frame-src(或更现代的 child-src 已被弃用,统一用 frame-src)指令。它控制「当前页面允许哪些源嵌入自己」,而反过来,「当前页面里的 iframe 能加载哪些外部地址」,由父页的 frame-src 决定。
比如你在主页面中写:<iframe src="https://evil.com"></iframe>,浏览器会检查主页面的 CSP 是否允许 frame-src https://evil.com;如果不允许,请求直接被拦截,控制台报 Refused to frame 'https://evil.com' because it violates the following Content Security Policy directive。
-
frame-src必须显式声明,不能靠default-src继承(除非你明确写了default-src且没覆盖frame-src) - 值为空格分隔,支持
'self'、协议+域名(如https://maps.google.com)、不支持通配符子域名(https://*.example.com无效) - 若要允许 data URL(如某些图表库生成的内联 SVG),必须显式加
data: - 旧版浏览器(IE)不支持
frame-src,只认X-Frame-Options,建议双写
frame-src 和 frame-ancestors 容易混淆,但作用完全相反
frame-src 是“我(父页)能嵌谁”,frame-ancestors 是“谁(外站)能嵌我”。两者必须分开配置,且目标不同。
典型错误是把防点击劫持的逻辑错套到 iframe 加载控制上:比如想阻止第三方嵌自己的登录页,却去改 frame-src,结果毫无作用——那该配 frame-ancestors 'self' 或 frame-ancestors https://trusted.example.com。
-
frame-src 'none'表示禁止所有 iframe 加载(包括同域),连<iframe src="./local.html"></iframe>都会失败 -
frame-ancestors 'none'表示禁止任何页面用 iframe 嵌入当前页,等效于X-Frame-Options: DENY - 二者可共存:父页设
frame-src https://widget.example.com允许加载小工具,同时设frame-ancestors 'self'防止自己被钓鱼页嵌套 -
frame-ancestors不继承,也不 fallback,写错(比如漏分号、多空格)等于没写
Tauri 等桌面框架里,CSP 配置位置和格式完全不同
Tauri 的 CSP 不走 HTTP 响应头,而是写在 tauri.conf.json 的 security.csp 字段里,格式是 JSON 对象,不是字符串。直接复制 Web 的 CSP 字符串会解析失败。
例如,想让 Tauri 应用里的 iframe 加载 https://docs.example.com,必须这样写:
{"app": {"security": {"csp": {"frame-src": "'self' https://docs.example.com"}}}}
注意:frame-src 值是数组形式的字符串,不是对象;'self' 仍表示同协议+主机+端口;Tauri 当前不支持 report-uri,但支持 report-to。
- 如果用
<meta http-equiv="Content-Security-Policy">在 Tauri 页面里硬塞,会被忽略——Tauri 只认配置文件里的策略 - Tauri 默认禁用所有外链,所以哪怕只加一个第三方 iframe,也必须在配置中显式放行
frame-src,否则白屏无报错 - 开发时先用
report-only模式(Tauri 支持csp.reportOnly: true)观察 console,确认没有漏掉合法域名
真正影响 iframe 安全的,是 sandbox + allow + CSP 三层叠加
只配 frame-src 远不够。攻击者一旦拿到可加载的 iframe 地址,下一步就是利用其执行能力做坏事。这时 sandbox 属性和 allow 列表才是关键闸门。
比如:<iframe src="https://third-party.com/widget" sandbox="allow-scripts" allow="clipboard-read"></iframe> 看似限制了脚本,但漏掉了 allow-same-origin —— 这反而更危险:脚本可运行,又因没同源权限无法读取父页 DOM,但若子页存在 XSS,它就能用 fetch 以父页 origin 发请求(后端仅校验 Origin 会误判)。
-
sandbox不带值 = 默认全禁(脚本、表单、弹窗、插件全关),最安全起点 - 加
allow-scripts后,必须同步评估是否需要allow-same-origin;只要不确定子页内容完全可控,就别加后者 -
allow="geolocation"这类敏感权限,应在用户触发动作(如点按钮)后再动态添加,而非初始就声明 -
frame-src控制“能不能加载”,sandbox控制“加载后能干什么”,allow是sandbox的细化开关——三者缺一不可
frame-src 和 frame-ancestors 的语义颠倒,以及 Tauri 等非标准环境里 CSP 的 JSON 格式约束。配错一层,整个 iframe 链路的安全假设就崩了。前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!











