破解思考题：为什么无法绕过 X-Frame-Options: SAMEORIGIN？

2026-03-21 6 纸飞机账号购买

引言

昨天我们在 iframe 文章的末尾留了一道思考题：

假定你打算于自身的博客之内嵌入一个源自“http://example.com”的页面，然而其对方设定了X-Frame-Options : SAMEORIGIN，你存有何种法子使其强行呈现呢，缘由是什么呢？

众多读者于评论区给出了自身的猜想，有人讲能够运用 iframe 的 sandbox 属性，有人称可以试着去修改 document.domain，另外有人提出采用代理服务器。今日我们就要去揭晓答案，并且借此深入领会浏览器的安全边界。

一、先给出结论

所给出的答案呢，是不能够借助纯粹前端方面的技术去强行进行嵌入的。要是你试着于自身的页面之中运用iframe来加载那个页面，那么浏览器便会径直拒绝加载啦，并且还会在控制台输出类似于下面这样的错误：

Refused to display 'http://example.com' in a frame because it set 'X-Frame-Options' to 'sameorigin'.

这属于浏览器的硬性安全策略范畴，是没办法借助，任何前端手段去达成绕过目的的。接下来，我们会对其中缘由展开阐释，你知道为什么？

二、X-Frame-Options 究竟是什么？

X - Frame - Options，这是一个 HTTP 响应头，其产生于服务器在向浏览器返回页面之际进行的设置操作，该操作的目的在于告知浏览器当前页面是否被允许嵌入到 iframe 之中，它具备三个可供选择的值：

当浏览器接收到这个响应头之后，在对页面进行渲染之时会展开检查，要是当前页面的父窗口，也就是 iframe 的父文档，跟子页面并不同源，并且头部被设置成 SAMEORIGIN，那么浏览器就会对加载加以阻止，还会抛出错误。

浏览器的角色：严格执行，不容商量

这个机制是被浏览器内置进去的，开发者没办法借助JavaScript去进行修改或者忽略。哪怕你于iframe之上设置再多的sandbox属性（像是allow-same-origin），也不会让浏览器的判断产生改变，因为X-Frame-Options的检查是在网络请求完成之后、页面渲染之前发生的，它根本不在意iframe的属性，仅仅关心父页面的来源是不是匹配。

三、为什么不能绕过？——安全设计的初衷

X - Frame - Options 因防御点击劫持（Clickjacking）而产生，点击劫持属于一种恶意攻击，攻击者把目标网站设置成透明状态，进而诱使用户去点击看上去并无危害的按钮，然而实际上用户点击的却是被嵌入页面上的按钮（像“点赞”或者“支付” button）。

要是准许前端随便绕开，那么任意网站都能够被恶意嵌入，用户的安全就没法得到保障。所以，浏览器一定要无条件遵循服务器返回的安全指令，这可是客户端不能协商的安全底线。

四、那种“看上去似乎能够行得通”的方案，为何会行不通呢，采用 iframe 的 sandbox 属性。

以限制iframe内行为为主要用途的sandbox，比如对脚本、表单等进行禁用，然而却没办法改变父页面与子页面的跨域状态，并且更加无法将服务器所设置的X-Frame-Options给抹除，此头由浏览器在网络层面进行拦截，sandbox毫无作用。

2. 修改 document.domain？

用于同主域跨子域通信的 document.domain，只能在比如将 a.example.com 和 b.example.com 都设置成 example.com 的情况下使用，而且仅限于同协议同端口，对于如 example.com 和 yourblog.com 这样完全不同的域名，此技巧是无效的，更重要的是，它不能对 X - Frame - Options 的检查机制造成影响。

3. 用代理服务器获取页面内容？

没错，你能够于自身的后端撰写一个代理接口，借助该接口从example.com那儿获取HTML内容，随后再将其返还予你的前端。如此一来，你页面所嵌入的便成了你自己域之下的内容，X - Frame - Options仅仅对原始请求才有作用，通过代理后，就如同是你的服务器在此进行请求，浏览器所看到的是由你的域返回的内容，自然而然也就不存在限制了。

但这种方法有几个致命问题：

因此，这仅仅是一种“理论上能够可行”的hack，并不是真正意义上的嵌入方案，同时也不被建议应用于生产环境当中。

4. 使用浏览器插件或修改浏览器设置？

可修改请求或响应头的浏览器插件，是针对用户自身安装的扩展，你不能要求所有访问你博客的用户都去安装插件，而且插件受限于浏览器权限模型，某些敏感头或许无法修改，即便能修改，那也是极少数用户的本地行为，不具备普适性。

5. 利用浏览器漏洞？

曾出现过能绕过X-Frame-Options的浏览器漏洞，不过一经发觉，生产厂家就立刻去修复。依靠漏洞是既不可靠又很危险的，你的网页随时可能失去作用，甚至引发安全方面的问题。

五、当代可供替换的办法是，Content-Security-Policy。

X - Frame - Options 正渐渐被 CSP 的 frame - ancestors 指令给替代掉，CSP 给出了更为精细的控制。

Content-Security-Policy: frame-ancestors 'self' https://trusted.com;

此条指令所表达的意思是，仅仅准许同源以及 https://trusted.com 进行嵌入，浏览器对于它的支持程度也是颇为高的（把 IE 排除在外）。

要是你的网站打算准许特定第三方进行嵌入，那就应当运用CSP，而不是已过时的X - Frame - Options。同样地，身为嵌入一方，要是目标网站并未许可你的域名，你依旧没办法强行去嵌入。

六、正确的做法是什么？

如果你确实有合法需求要嵌入某个页面，正确的流程是：

向网站所有者取得联系，恳请其准许你的域名嵌入。要是他们予以同意，那么能够于CSP里增添你的域名。采用官方所给出的嵌入办法，众多网站（像YouTube、Twitter）都给出专用的嵌入程序代码，而这些代码常常借助iframe达成，但它们是获得授权的，服务器会针对这些嵌入源头放宽限制。调用API来获取的数据，自行进行渲染。能够做到，若你要面对目标网站给出开放性的 API 这种情况，那你在取得数据后，采用自身的 UI 去进行呈现，从而彻底摆脱 iframe 的限制。七、总结：尊重安全，不越界。

服务器跟浏览器二者间存在的 X-Frame-Options: SAMEORIGIN 属于一种契约，它是用于保护用户的一道屏障。身为开发者，我们理应理解并且尊重这些安全方面的设计，而不是绞尽脑汁地去绕开它们。倘若绕过安全策略，最终受损的是用户的利益以及你的信誉。

有望借由这道思考题，你对于iframe的安全限制有了更为深刻的认知。下次碰到相似问题，你不但晓得“不能”，还晓得“为何不能”，以及“倘若确实需要，应当怎样做”。

能不能每天问一下：你于项目里有没有碰到过由于iframe安全头致使的嵌入方面的问题？那又是怎样去解决的？欢迎在评论区域分享你的经历！