iframe sandbox属性必须显式声明值（如sandbox=""或sandbox="allow-scripts"）才生效；不写、只写sandbox或写无效字符串（如sandbox="true"）均被忽略，且allow-scripts与allow-same-origin共存会触发浏览器静默拒绝沙箱，导致安全失效。
iframe sandbox 属性必须显式声明，空值才生效
不写 sandbox 或只写 sandbox（无等号、无值），浏览器会忽略该属性——这不是兼容性问题，而是 HTML 规范明确要求：必须写成 sandbox="" 或 sandbox="allow-scripts" 这类带值形式，才会触发沙箱机制。
常见错误现象：
- 写成
sandbox="true"或sandbox="enabled"：这些字符串值无效，等同于没加 - 写成
sandbox（无引号无值）：部分旧版 Safari 和 IE 完全不识别 - 忘记加引号导致 HTML 解析失败，
sandbox=allow-scripts被截断为sandbox=allow
实操建议：
- 默认起步配置用
sandbox="allow-scripts"，仅放开脚本执行，其他能力全部禁用 - 需要表单提交？追加
allow-forms；需要弹窗？加allow-popups；但不要一次性全开 - 若内容来自同一源（如
https://app.example.com/widget.html），仍优先用postMessage通信，而非开allow-same-origin
allow-scripts 和 allow-same-origin 绝对不能共存
这是最危险的配置陷阱。一旦 sandbox 中同时出现 allow-scripts 和 allow-same-origin，现代浏览器会静默拒绝整个 sandbox 属性，相当于 iframe 完全裸奔——能读取父页 DOM、窃取 Cookie、调用 top.location.href 跳转。
立即学习“前端免费学习笔记（深入）”；
原因在于：同源策略是浏览器安全基石，allow-same-origin 的语义是“让这个 iframe 假装和父页同源”，而脚本执行能力让它能立刻利用该身份做坏事。
实操建议：
- 第三方内容（广告、小工具、用户上传 HTML）一律禁止
allow-same-origin，哪怕它声称“可信” - 自家子域名内容需 DOM 通信？改用
window.postMessage()+event.origin校验，这是唯一合规路径 - 遗留系统迁移过渡期确需同源脚本？确保服务端已配
Content-Security-Policy: frame-ancestors 'self'，且 iframe src 不可被 XSS 注入
crossorigin 属性决定跨域资源能否读取响应体
crossorigin 控制的是“能否通过 JS 读取该资源的响应内容”，不是“能否加载”。比如嵌入字体、埋点脚本、私有图片时，不设或设错会导致 Failed to execute 'toDataURL' on 'HTMLCanvasElement' 或监控上报丢失堆栈信息。
两个合法值：
-
crossorigin="anonymous"：发送请求时不带 Cookie 和认证头，响应头需含Access-Control-Allow-Origin: *或具体源 -
crossorigin="use-credentials"：带 Cookie 和认证头，响应头必须精确匹配源（不能是*），且需含Access-Control-Allow-Credentials: true
容易踩的坑：
- 设了
use-credentials但响应头漏了Access-Control-Allow-Credentials→ 浏览器直接报 CORS 错误 - 字体文件用了
anonymous，但 CDN 响应头返回Access-Control-Allow-Origin: https://a.com（非通配）→ Firefox 拒绝渲染 -
crossorigin对srcdoc内容无效，只影响网络请求
CSP frame-src 指令优先级高于 HTML 属性
即使你写了 <iframe src="https://trusted.com"></iframe>，如果父页 HTTP 响应头里有 Content-Security-Policy: frame-src 'self'，浏览器仍会拦截并报 Refused to frame 'https://trusted.com/' because it violates the following Content Security Policy directive。
这意味着：HTML 层面的 sandbox、src 都是“软约束”，而服务端下发的 CSP 是“硬闸门”。
实操建议：
- 检查后端框架（Express/Django/Next.js）是否默认注入 CSP，并确认
frame-src或default-src已放行目标域名 - 开发阶段可用
<meta http-equiv="Content-Security-Policy" content="frame-src https://trusted.com;">快速测试，但它无法覆盖服务端头 - 别依赖
onload或onerror判断 iframe 是否加载成功——CSP 拦截、502、混合内容都会让它们不触发，得轮询iframe.contentWindow?.document?.readyState并设超时
