meta标签设置X-Frame-Options完全无效，因浏览器自2015年起废弃该用法，拦截决策发生在HTML解析前，而meta属解析阶段，无法干预；唯一可靠方式是服务端发送X-Frame-Options或Content-Security-Policy:frame-ancestors响应头。
meta 标签设置 X-Frame-Options **完全无效**，不能实现任何硬拦截。浏览器自 2015 年起已彻底废弃该用法，现在写它等于没写。
为什么 meta http-equiv="X-Frame-Options" 从不生效
浏览器在收到 HTML 前，就已根据 HTTP 响应头决定是否渲染 iframe —— 这个决策发生在解析 HTML 之前。meta 是 HTML 解析阶段才处理的内容，此时拦截早已完成，根本来不及干预。
- 你在页面里写
<meta http-equiv="X-Frame-Options" content="DENY">，Network 面板的 Response Headers 里永远看不到X-Frame-Options字段 - Chrome 120+、Firefox 125+、Safari 17+ 等全部忽略该标签，连警告都不报
- 旧版 IE（如 IE11）曾偶然“似乎”生效过，但属非标准行为，不可依赖、不可测试、不可上线
常见错误现象与误判点
开发者常因以下现象误以为 meta 生效了，实则另有原因：
- 嵌入后页面空白 + 控制台报
Refused to display 'xxx' in a frame because it set 'X-Frame-Options' to 'deny'→ 实际是服务端已正确返回了X-Frame-Options: DENY，和meta无关 - 本地开发时改了
meta，页面嵌入失败 → 很可能是本地服务器（如 Vite、Webpack Dev Server）默认注入了安全头，不是meta起的作用 - 用 curl -I 查不到该头，但页面看起来“被拦住了” → 大概率是 CDN 或反向代理（如 Cloudflare）自动加了 CSP 或 XFO，而非你写的
meta
真正起作用的硬拦截只来自 HTTP 响应头
唯一可靠的硬拦截方式，是让服务端在响应中明确发送 X-Frame-Options 或更优的 Content-Security-Policy: frame-ancestors。
立即学习“前端免费学习笔记（深入）”；
-
X-Frame-Options: DENY：浏览器强制拒绝所有 iframe 加载，兼容性好，但仅支持单指令 -
Content-Security-Policy: frame-ancestors 'none'：现代标准，等效于 DENY，且优先级高于 XFO；若同时存在，浏览器直接忽略 XFO - 两者可共存用于兜底（如支持 IE11），但必须由服务端发，
meta无法替代
别再用 JS 检测 iframe 作为“补救”
有人会写 JS 判断 window.top !== window.self 然后跳转或遮罩 —— 这属于软防护，极易被绕过：
- 攻击者可在 iframe 上层加
sandbox属性禁用脚本执行 - 可通过
document.domain或postMessage绕过同源检测 - 用户看到的是白屏或跳转，体验差，且无法阻止首次点击劫持（JS 执行前点击已发生）
真正容易被忽略的是：哪怕你把 meta 写得再规范、再早加载，只要服务端没发对应响应头，浏览器就当它不存在。硬拦截的控制权，从来不在 HTML 里，而在网络链路的第一跳 —— 服务端响应头。
