...如果坏演员能够在您的页面上运行 javascript

这正是人们想要避免的一点。iframe 允许第三方（包括脚本）成为可见页面的一部分，而无需访问该特定第三方提供的 iframe 之外的页面部分。这比将第三方 HTML（用于表单）和脚本（用于表单控制，如输入检查）直接嵌入到主页中要安全得多。

如果 iframe 和主页来自不同的来源，那么同源策略将严重限制它们相互交互的方式。与标签中包含的第三方脚本相反，它script可以完全访问 DOM，并且可以执行同源script标签可以执行的所有操作。

我写这个作为答案，因为评论太长了。但是前段时间有一些恶意软件被用来感染一些电子商务网站，该恶意软件模拟了一个假的贝宝弹出窗口，或者类似的东西。为了检查窗口是真的还是假的，他们建议尝试将支付弹出窗口移到浏览器的窗口框架之外：如果你做不到，那么弹出窗口是假的（由恶意软件模拟）。

所以是的，如果电子商务网站被感染，那么页面中的所有内容都可以被替换、拦截、模拟。

然而，让第三方处理敏感数据仍有优势（只要这些第三方是可信且安全的）。如果您在服务器上处理支付数据，那么您需要非常小心如何存储这些数据。如果您的服务器被黑客入侵，数据泄露的责任将由您承担。但是，如果您让第三方处理数据（直接，通过 iframe 或不同的窗口），那么敏感数据永远不会触及您的服务器。

换句话说，我认为，如果网站上的数据被感染，没有任何东西可以保护它，但第三方处理器至少可以帮助保护过去的数据（在感染之前处理的数据，并且从未接触过您的服务器）。

您提出了一个很好的问题，并且上述许多答案都涵盖了 iframe 添加一层安全性的技术原因。但是，您也正确地观察到，如果攻击者可以访问父页面的内容并且可以插入他们自己的 JavaScript，那么他们可以在真实 iframe 之上创建一个虚拟支付表单，并“诱骗”客户将他们的支付卡数据输入到攻击者形成，所以你问这是否是“安全剧院”（或者可能是合规剧院）的问题。

但是假框架的情况，因为攻击者无法访问真实 iframe 中的数据，一旦他们窃取了客户的付款，攻击者就会从支付服务提供商 (PSP) 那里获得一个“秘密”令牌。卡数据，无法通过将其发回 PSP 来完成交易，因为他们没有该令牌。交易将失败，通常攻击者会生成失败的交易消息，然后让客户与“真实”iframe 进行交互。

由于交易失败，商家能够检测到假帧攻击，而不涉及帧的替代方案则更难检测。使用 PSP 中的 iframe 会使攻击者更难编写代码并允许检测，因为失败的事务数量较多。它不是安全剧院，但也不完美。然而，它确实使攻击更难、更容易被发现——降低了风险。

就个人而言，如果我经营一个电子商务网站，我会使用大多数 PSP 提供的选项，即完全将客户重定向到 PSP 自己的支付页面。同样，不是 100% 安全，因为攻击者总是可以毒害重定向，但更容易检测到，因此进一步降低了风险。

暂时忽略 PCI DSS 合规性，使用内容安全策略 (CSP) 和子资源完整性 (SRI) 结合外部合成用户检测服务是您击败电子商务浏览攻击的真正朋友。

我经营一家小型组织的电子商务业务。

您从浏览器内技术的角度来看待它，并假设每个组织都对其自身的安全性负责。 小型组织根本无法派驻一个称职的 IT 安全部门，因为门槛相当高——你必须相当大才能做到任何事情。这不会发生，这不是小企业的经济现实。如此多的有能力的第三方（如 Square、Quickbooks 等）已准备好为您提供交钥匙解决方案。

这使它变成了另一种“风险游戏”。 首先，我将我们的网站视为室外导管 - 电气规范要求您在 100% 的时间内将其视为 100% 充满水（并使用湿额定电线）......我认为我的“宣传册网站”100% 被黑了100％的时间，我永远不会知道。

所以我知道我完全被技术风险所淹没。我专注于商业风险——当黑客“除了大喊大叫”之外，“大喊大叫”将如何影响我？

对我来说，处理 PCI-DSS 的最有效方法是根本不处理我网站上的敏感数据，除了像 Square 这样的服务，它在封装设备和 PayPal 的服务器之间进行点对点加密 (P2PE)。我的服务器永远不会有任何代码来处理任何信用卡数据。我很乐意将它们发送到 <oursite>.ourvendor.com 以获取零售商品，但我们的供应商不支持该功能并需要 iframe。他们确实有一个 IT 团队，所以听从他们的专业建议是我们逃避违规民事责任的最佳方式。

我们更进一步，甚至没有我们自己的商家帐户，因为这使我们对我们的供应商未能遵守 PCI-DSS 负责。我们的供应商使用他们的账户收取的低于 1% 的附加费是我们销量的廉价保险。

因此，这最终与技术安全无关：它与民事责任有关。