W3C 在 1997 年解决了这个问题，解释了如何在“实现 HTML 框架”中实现框架：

任何想将任何祖先使用的 URL 分配为其 SRC 的帧都将被视为根本没有 SRC URL（基本上是空白帧）。

Iframe 递归错误/攻击历史

正如Kingdago在上面的评论中发现并提到的那样，一个错过了为此实施保护措施的浏览器是1999年的Mozilla。引用其中一位开发人员的话：

这是一个奇偶校验错误（也是可能的尴尬来源），因为 MSIE5 对这些类型的页面没有问题。

我决定对此进行更多研究，结果发现在 2004 年这种情况再次发生。然而，这次 JavaScript 参与其中：

这是代码，是什么原因造成的：<iframe name=“productcatalog” id=“productcatalog” src=“page2.htm”></iframe>紧跟一个脚本：frames.productcatalog.location.replace（frames.productcatalog.location + location.hash）;

...

实际结果：父窗口以递归方式加载到 iframe 中，有时会导致崩溃。

预期结果： 只需像在 Internet Explorer 中一样显示它。

然后在 2008 年再次使用 Firefox 2（这也涉及 JavaScript）。

2009年再次出现。有趣的是，这个错误仍然开放，这个附件：（你会克制你的好奇心吗？）仍然会崩溃/冻结你的Firefox（我刚刚测试了它，我几乎崩溃了整个Ubuntu）。在Chrome中，它只是无限期加载（可能是因为每个选项卡都存在于单独的进程中）。https://bugzilla.mozilla.org/attachment.cgi?id=414035

至于其他浏览器：

• 2005 年，Konqueror 在其保护措施中有一个错误，允许在另一个内部渲染 iframe（但似乎不知何故它没有冻结/崩溃整个应用程序）。
• 据报道，IE6，Opera 7.54和Firefox 0.9.3也容易受到基于iframe递归的攻击。