好问题。FrameBusting 很难正确实现，几乎在所有情况下，由于浏览器不兼容、错误或开发人员错误等原因，它会被破坏。

最近在这里遇到了非常相似的问题：https : //stackoverflow.com/questions/958997/frame-buster-buster-buster-code-needed。据说在哪里提示用户简要说明正在发生的事情。不能不同意，更简单的解释 - 更好的用户理解，只是要注意不要错过涉及用户隐私的细节。有了给定的细节，用户必须自己思考要做什么才不会害怕。

OWASP 对此主题有很好的研究论文：http : //www.owasp.org/images/0/0e/OWASP_AppSec_Research_2010_Busting_Frame_Busting_by_Rydstedt.pdf

作为用户，我更喜欢的解决方案是：允许您的网站被陷害，但要确保恶意网站不会造成伤害。如果您在框架中，请不要从另一个选项卡继续用户的会话。在这种情况下，请考虑将站点设为只读。如果您允许用户在框架中重新登录，则显示警告。当然，对于一个罕见的用例来说，这需要大量的工作来实现，所以它可能不实用。

如果你真的想破坏框架，我会建议一个不显眼的解决方案。使用常规的 framebusting 代码，可能与X-Frame-Options HTTP 标头结合使用，并在页面上提供突出显示的注释而不是弹出窗口。

旁注：HTML 安全模型依赖于一个站点不能对其他站点执行操作这一事实。这给了我们同源策略。许多黑客都是基于绕过这一点，通过将代码注入其他站点等。点击劫持是相关的，但攻击页面不是使用代码在其他站点中执行功能，而是欺骗用户点击某处。

就我个人而言，我认为服务器信任浏览器以限制脚本的 HTML 安全模型在概念上存在缺陷。我更喜欢代码几乎可以做用户可以做的任何事情的模型，而不是你会依赖安全令牌。当然，攻击脚本可以提交表单来删除帖子，但如果没有正确的会话 ID 和密码，它将被忽略。这将允许更多有趣的应用程序，如混搭、仅限客户端的内容聚合器等。当然，现在将 Web 切换到这样的安全模型为时已晚。

我写这篇文章是为了激发我的建议：即使不依赖于浏览器强制分离（例如 framebusting），也可以编写安全站点，其中每个操作都由用户授权。不要让您的安全性依赖于无框架，而是假设您的站点是有框架的，SOP 受到损害并且框架站点可以按下按钮（无论是否对用户进行工具化）。