iframe的CSP配置本质是frame-src指令，用于控制父页面允许嵌入哪些外部源，需在tauri.conf.json中以JSON格式显式声明，不继承default-src，且必须精确匹配协议、域名与子域名。
iframe 的 CSP 配置本质是 frame-src 指令，不是给 iframe 标签加属性
HTML 的 <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">都会失败 -
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"> 看似限制了脚本，但漏掉了 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 链路的安全假设就崩了。 
