<meta>标签设置X-Frame-Options完全无效，因该头必须由服务端通过HTTP响应头发送，浏览器在HTML解析前已根据响应头决定是否渲染iframe；现代浏览器自2015年起已废弃此用法，仅IE 8–10偶然支持。
根本不起作用，别再往 <meta> 里写 X-Frame-Options 了。
为什么 <meta http-equiv="X-Frame-Options" content="DENY"> 完全无效
这个写法看起来很像响应头，但浏览器从不解析它作为安全策略。所有主流浏览器（Chrome、Firefox、Safari、Edge）自 2015 年起已明确废弃该用法；它只在 IE 8–10 的极早期版本中偶然生效，现在填了等于白填。
- HTTP 安全头必须由服务端在响应阶段发出，
<meta>是 HTML 解析阶段的行为，防御窗口早已错过 - 攻击者可直接用
curl https://yoursite.com/page加载你的页面，根本不会触发 HTML 解析，更不会读取<meta> - 用浏览器开发者工具的 Network 面板查看响应头，你永远看不到
X-Frame-Options字段——因为它压根没发出去
真正有效的配置方式：服务端响应头优先级排序
防点击劫持只有一条可靠路径：服务端返回正确的 HTTP 响应头。现代浏览器按如下顺序执行策略：
- 先检查
Content-Security-Policy中的frame-ancestors指令 —— 这是当前 W3C 标准，Chrome/Firefox/Edge 自 2020 年起以它为准 - 若未设置
frame-ancestors，才退而求其次看X-Frame-Options - 两者同时存在时，
frame-ancestors生效，X-Frame-Options被静默忽略
所以正确做法是：优先配 frame-ancestors，旧浏览器兜底加 X-Frame-Options，但绝不单独依赖后者。
立即学习“前端免费学习笔记（深入）”；
常见服务端配置示例（非伪代码，可直接抄）
不同环境写法差异大，但核心就三件事：值要对、位置要早、覆盖要全。
- Nginx：
add_header X-Frame-Options "DENY" always;——always关键字不能少，否则 304 或 5xx 页面不带该头 - Express：
res.setHeader('X-Frame-Options', 'SAMEORIGIN')—— 必须在res.send()或next()前调用 - Next.js：
headers()函数中按路由匹配添加，例如{ source: '/admin', headers: [{ key: 'Content-Security-Policy', value: "frame-ancestors 'none'" }] } - Django：关闭中间件自动注入（
SECURE_FRAME_DENY = False），改用django-csp统一管理frame-ancestors
容易被忽略的兼容性陷阱
很多人以为配了就万事大吉，但实际部署中几个点极易翻车：
-
ALLOW-FROM已被 Chrome 79+ 和 Firefox 69+ 彻底移除，任何还用它的配置都形同虚设 -
frame-ancestors 'self'不支持路径限制（比如不能写'self'/dashboard），只能控制域名粒度 - CDN 或反向代理（如 Cloudflare）可能缓存并覆盖原始响应头，需确认其是否透传或重写安全头
- 某些前端框架（如 Vue Router 的 history 模式）在 404 页面或错误边界中可能漏配头，要单独验证
最稳妥的做法：用 curl -I https://yoursite.com/any-path 实测每个关键路径的响应头，别信配置文件写了就等于生效。
