TL;DR iframe不能完全取代消毒，但它是一个很好的功能，可以用作深度安全。不幸的是，它确实妨碍了一些用户友好的功能。

我会很高兴听到更明智的答案，但我将发布一些我知道的观点。

同源策略双向工作。它可以防止iframe看到外部文档内容，这很棒。不幸的是，如果您选择文本，外部文档无法分辨iframe. （感谢@paj28）曾经可以通过向内页添加脚本来使用 postMessage 功能来解决这个问题，但这很不方便。iframe sandbox此外，如果您用作禁用scripts的方法，这将不起作用。（我强烈推荐）

您将需要使用内容安全策略（再次感谢@paj28）来禁用iframed 内容中的信标；以及禁用脚本和其他潜在问题。

我想指出，iframe最初的设计并不完整。如果您对消毒有任何疑问，该sandbox属性将是必须的。不幸的是，该sandbox功能是最近才实现的。随着较旧的浏览器开始从图表中消失，这一点的重要性正在减弱。

无论如何，禁用脚本会妨碍用户友好的功能，例如检测选定的文本。（您有可能摆脱沙盒的“禁用脚本并视为同源”规则，但这似乎有风险。）

每当您向iframe'd 文档添加自己的脚本或交互功能时，如果您仍然清理该文档，您将更加安全。虽然iframe sandbox与 CSP 结合可能会完全覆盖您，但该公式中可能缺少一些东西。

所以总而言之

• 对于不支持的浏览器sandbox，在iframe减轻显著安全隐患，但无法防止许多问题。内容安全策略或许能够在很大程度上隔离内容。但是您仍然需要进行消毒以防止出现<a target="_top".

• 对于支持 的浏览器sandbox，结合良好的内容安全策略，您可能可以替换清理，但不建议这样做，因为很难确定您是否 100% 安全。（另一方面，消毒程序较旧且经过更好的审查）

• 如果你有消毒（你可能应该这样做），并且卫生经过严格审查，那么iframes 只会妨碍用户友好。另一方面，如果在您的清理过程中发现了一个缺陷，那么您会很高兴您iframe使用sandbox属性和 CSP 来减少攻击范围。

旁注：桌面应用程序在将其 web 视图沙箱化方面具有更大的自由度，甚至比iframe沙箱属性更好。因此，例如，Android 应用程序可能会受益。

为了在 iFrame 中提供任何内容，Google 需要禁用该站点的一些现有的断帧脚本（Google 将添加这些脚本以缓解针对旧 Web 客户端的点击劫持）。

我想谷歌确定禁用帧中断脚本的风险将大于在 iFrame 中呈现内容的回报。