条目页里那个 iframe 预览：目录站引用别人页面该配的几个响应头
条
iframe 在目录站上主要有两个用法：一是在条目详情页里嵌一个对方站点的预览小窗，二是在自己的站点截图页里展示合成的缩略图。前者风险大得多，因为它同时牵扯到你自己被别人嵌的问题。
图片来源：网络，版权归原作者所有，侵权请联系删除
两个响应头，谁说了算
控制「我的页面能不能被别人嵌进 iframe」，有两个东西能用：
| 响应头 | 能表达的 | 现状 |
|---|---|---|
| X-Frame-Options | DENY / SAMEORIGIN | 老标准，RFC 7034，兼容性兜底 |
| CSP frame-ancestors | none / self / 指定域名列表 | CSP Level 2 起，表达能力强得多 |
两个都写上时，支持 frame-ancestors 的浏览器会忽略 X-Frame-Options，按 CSP 的规则执行。所以不存在「谁更严格听谁的」这回事——只要浏览器认 CSP，XFO 就是摆设。XFO 的价值在于那些不认 CSP 的老客户端，留着当兜底。
还有两个坑：
- 写在 meta 标签里完全无效。这两个都只能通过 HTTP 响应头下发，写进 HTML 里浏览器不认。
- ALLOW-FROM 已经废弃。老教程里还常见 X-Frame-Options: ALLOW-FROM https://xxx，现代浏览器一律不认，别再抄了。要允许指定域名，只能用 CSP 的 frame-ancestors。
自己这边怎么配
目录站的页面大多不需要被外部嵌入，最省事的是全站下发：
add_header Content-Security-Policy "frame-ancestors 'self'" always;
add_header X-Frame-Options SAMEORIGIN always;注意 always 这个参数。nginx 默认只在 2xx、3xx 状态码上加自定义头，错误页不带。而攻击者最喜欢嵌的就是你的登录页和错误页——刚好可能走在 4xx 那条分支上。
如果你的 iframe 预览功能是自己站内嵌站内（比如把预览窗做成同一个域名下的代理页），'self'就够了。如果真的要允许合作的第三方嵌入你的某个页面，单独给那个路径下发更宽的策略，别全站放开。
嵌别人的页面：先接受会失败
这是很多人预期没调好的地方。你兴冲冲做了个内嵌预览，上线发现大半站点根本嵌不出来——因为对方配了 DENY，浏览器直接拒绝渲染。
这不是你的 bug，是对方的选择，而且从对方角度看完全合理。所以 iframe 预览必须做成「可选增强」而不是「核心功能」：
- 默认显示你自己的站点截图，点一下才尝试加载 iframe
- 加载失败要有明确的降级提示，而不是留一块白框
- 失败后自动回退到「新窗口打开」按钮
判断依据是：把这个 iframe 去掉，条目页还剩多少价值。如果去掉后页面还是完整的，那它就是增强；如果去掉后这个页面没意义了，说明你把核心功能押在了别人允许嵌入这件事上，风险是自找的。
被别人嵌才是真的危险
点击劫持的实际伤害不是「我的页面出现在别人的站里」，而是「用户在不知情的情况下对着我的页面点了鼠标」。典型的链条是：攻击者用完全透明的 iframe 把你某个需要登录才能操作的按钮盖在诱饵按钮下面，用户以为点的是领奖，实际触发的是你站上的删除或授权操作。
除了上面那两个响应头，还有一层值得顺手加上：给会话 Cookie 设 SameSite=Lax 或 Strict。这样从跨站 iframe 发出来的请求不会带上用户的登录态，即使某处的 frame-ancestors 配漏了，攻击者拿到的也只是未登录的那个版本。
这一层是纵深防御，不能替代响应头，但成本几乎为零。两项都配，比单独指望任何一项稳。
和 SEO 的关系
别人把你的页面嵌进 iframe，不会让你的内容算到对方头上——搜索引擎早就处理这类情况了，不存在「被嵌就被抄袭」。真正会出现问题的是另一种：你自己在站内大量使用 iframe 承载主要内容。
iframe 里的内容对搜索引擎来说属于另一个文档，权重传递、索引归属都含糊。如果条目页的核心文字全在 iframe 里，等于你自己把这块内容推远了。用 iframe 做预览可以，用 iframe 放正文不行。
上线前查三样
- 用
curl -I分别看首页、登录页、一个 404 页的响应头，确认三个地方都带到了 CSP 和 XFO - 建一个临时页面嵌自己的站点，确认被拒绝
- 打开浏览器控制台，看有没有 block 提示，再对着 CSP 报错修
Report-Only阶段遗漏的资源
这几项加起来花不了半小时，但能挡掉一大类问题。响应头这东西配对了没人夸你，配错了出事的时候来不及补。