iframe 本身不触发 XSS，但其 src 属性若被用户可控内容注入（如 javascript:、data: 协议或未校验 URL），则成为 XSS 载体；必须在服务端对 src 做白名单校验和 HTML 编码。
iframe 本身不会触发 XSS，但它是 XSS 的常见载体
直接在 HTML 中写 <iframe src="..."> 不会执行脚本，但一旦 src 指向的内容由用户可控（比如拼接 URL 参数、渲染富文本、从数据库读取未过滤的 HTML），就极易成为 XSS 入口。真实风险往往不在 iframe 标签本身，而在它加载的页面内容或动态生成的 src 值。
常见错误现象：
- 评论区或后台编辑器允许用户输入 HTML，结果存入了
<iframe src="javascript:alert(1)"> - 前端用
innerHTML拼接用户提交的链接：el.innerHTML = `<iframe src="%24%7BuserInput%7D">`</iframe>，而 userInput 是javascript:fetch('/api/steal?c='+document.cookie) - 服务端返回的 HTML 片段里包含未转义的 iframe src，且该 src 来自 query string 或表单字段
必须对 iframe 的 src 值做输出编码和白名单校验
不能只依赖前端 JS 过滤——攻击者可绕过 JS 直接构造请求。关键防线在服务端生成 HTML 时。
- 所有动态拼入
src属性的值，必须先通过 URL 白名单校验（只允许https://trusted.com/等已知域名） - 若需支持协议相对路径或相对路径，应限制为
/path或//trusted.com/path，禁止javascript:、data:、vbscript:等危险协议 - 对非白名单 URL，不渲染 iframe；对合法 URL，仍需做 HTML 属性值编码：将
"→"，&→&，→ <code>< - 避免使用
document.write()或innerHTML动态插入 iframe —— 改用document.createElement('iframe')+setAttribute('src', safeUrl)
启用 sandbox 属性并禁用高危权限
哪怕 iframe 加载的是可信域名，也应默认加 sandbox —— 它能切断 iframe 内脚本的大部分能力，大幅降低 XSS 利用链长度。
立即学习“前端免费学习笔记（深入）”；
- 最安全起点：
<iframe sandbox="allow-scripts" src="...">→ 错！allow-scripts和allow-same-origin绝对不能同时开 - 推荐组合：
<iframe sandbox="allow-scripts allow-popups allow-forms" src="...">，但前提是目标页面不需 DOM 读写或 localStorage - 若 iframe 内容完全不可信（如广告、用户上传的 HTML），用最小权限：
sandbox=""（即全禁），再按需开启，例如仅允许图片加载：sandbox="allow-images" - 注意：
sandbox对javascript:协议无效 —— 所以白名单 + 编码仍是前置条件
CSP 的 frame-ancestors 和 X-Frame-Options 不防 XSS，但防挂马嵌套
这两个响应头管的是“谁能把你的页面塞进 iframe”，不是“你塞进去的内容安不安全”。它们解决的是点击劫持和恶意挂马，不是 XSS 本身。
- 如果你的页面被黑后注入了恶意 iframe，
Content-Security-Policy: frame-ancestors 'self'能阻止其他网站把你的页面当壳加载，但无法阻止你自己的页面里渲染出恶意 iframe -
X-Frame-Options: DENY只影响当前页面是否可被嵌套，不影响你嵌套别人 - 真正防 XSS 注入 iframe 的，还是输入验证 + 输出编码 + sandbox + CSP 的
script-src和frame-src - 建议补充：
Content-Security-Policy: frame-src 'self' https://trusted.com; script-src 'self'
最容易被忽略的点是：sandbox 属性一旦设置，iframe 内页面的 window.top、document.cookie、localStorage 全部失效，连同源页面也无法通信 —— 如果你依赖 postMessage，必须显式加 allow-scripts，但此时务必确认目标源可信且消息校验严格。
