iframe标签无csp属性，CSP只能通过HTTP响应头或标签作用于整页；父页CSP不直接约束iframe内脚本执行，真正生效的是iframe自身响应头策略、sandbox属性及父页对运行时环境的间接限制。
iframe 标签本身没有 csp 属性——这是个常见误解。CSP（Content-Security-Policy）不能通过 HTML 属性直接设在 iframe 上，它只能通过 HTTP 响应头或 <meta> 标签作用于整个页面，且对 iframe 内容的约束方式有严格限制。
为什么不能给 iframe 加 csp 属性
HTML 规范中根本不存在 csp 这个 iframe 属性。试图写 <iframe csp="script-src 'self'"></iframe> 不会产生任何安全效果，浏览器会忽略该属性，控制台无报错，但策略完全不生效。
真正起作用的是两层独立机制：
- 父页面的 CSP 头（如
Content-Security-Policy: script-src 'self'）只约束父页面自身资源加载，**不影响 iframe 内部脚本的执行逻辑**； - iframe 内容页面自身的 CSP（由其响应头或
<meta>定义）才决定它自己能否加载/执行脚本；父页面无法“覆盖”或“注入”这个策略。
iframe 内脚本被拦的真实原因：sandbox + 父页 CSP 的间接约束
你看到“iframe 里脚本执行被拒绝”，往往不是因为某个叫 csp 的属性，而是以下组合在起作用：
立即学习“前端免费学习笔记（深入）”；
-
sandbox="allow-scripts"开了外链脚本加载，但脚本实际发起的子资源请求（比如 fetch、import、图片、字体）仍受父页面 CSP 的connect-src、img-src等指令限制； - 如果 iframe 内脚本尝试
eval("alert(1)")或内联onclick，而父页面 CSP 含script-src 'self' 'nonce-xxx'且没开'unsafe-eval'或'unsafe-inline'，那么这些调用会被拦截——但这是父页面策略对 iframe 中 JS 执行环境的**运行时约束**，不是“iframe 的 CSP”； - 若 iframe
src是同源页面，它继承父页面部分策略上下文（如base-uri、form-action），但script-src依然以 iframe 自身响应头为准。
想真正限制 iframe 内不安全脚本，必须靠这三件事
别找不存在的 csp 属性，盯住三个可控入口：
- 用
sandbox=""或sandbox="allow-scripts"控制初始脚本加载能力——这是最直接、最底层的开关； - 确保 iframe 加载的页面（即
src指向的 URL）自身返回了严格的 CSP 响应头，例如：Content-Security-Policy: default-src 'none'; script-src 'self'; object-src 'none'; base-uri 'none'； - 父页面配好自己的 CSP，并显式禁用高危项：
script-src 'self' 'nonce-xxx'（不用'unsafe-inline'）、default-src 'none'、object-src 'none'，防止 iframe 内脚本利用父页宽松策略绕过限制。
最容易被忽略的是：iframe 的 srcdoc 属性内容完全不受父页 CSP 影响，但也不触发 sandbox 的脚本拦截（除非你手动加 sandbox）。用 srcdoc 嵌入含 <script></script> 的 HTML 时，它按普通内联脚本处理，是否执行全看父页面的 script-src 和 'unsafe-inline' 设置——这点和 src 加载完全不同。
