iFrame嵌入安全：Web开发人员的最佳实践 (ZH)

沙盒化您的iFrame始终使用sandbox属性限制iFrame功能，防止不可信内容执行脚本、访问本地存储或提交表单。

实施强大的CSP利用内容安全策略（CSP）头来控制您的页面可以加载和执行哪些资源，特别是针对iFrame，以防止混合内容问题和脚本注入。

利用X-Frame-Options和CSP Frame-Ancestors通过将X-Frame-Options设置为DENY或SAMEORIGIN来保护您的站点免受点击劫持，对于现代浏览器，请在您的CSP中使用更精细的frame-ancestors指令。

谨慎对待外部内容彻底审查通过iFrame嵌入的任何第三方内容，因为您隐式信任其安全实践。优先选择提供强大安全保证或允许服务器端处理的解决方案。

iFrame的双刃剑：便利性与安全性

iFrames（内联框架）是现代Web开发不可或缺的一部分，允许开发人员将其他来源的内容无缝嵌入到他们的网页中。无论是YouTube视频、支付网关、社交媒体小部件还是身份验证流程，iFrames都提供了无与伦比的灵活性。然而，这种强大功能伴随着显著的安全隐患。如果没有适当的预防措施，iFrames可能会成为各种攻击的载体，包括点击劫持、跨站脚本（XSS）和数据泄露。随着Web应用程序变得越来越复杂和相互关联，理解和实施iFrame安全最佳实践不再是可选项；它是一种必然。

iFrame的核心挑战在于，您实际上是允许外部内容在您自己页面的上下文中运行。此外部内容可能不符合您应用程序相同的安全标准，甚至可能具有恶意。因此，iFrame安全的目标是尽可能隔离这些嵌入内容，限制其与您的父文档和用户数据交互或损害的潜力。

基本的iFrame安全措施：沙盒和CSP

1. sandbox属性：您的第一道防线

HTML5的sandbox属性可以说是iFrame最关键的安全功能。它使您能够对iFrame内的内容应用一组严格的限制，将其与页面的其余部分隔离开来。默认情况下，简单地包含不带任何值的sandbox属性会应用最严格的限制，本质上将iFrame内容视为来自唯一来源，并阻止脚本运行、表单提交和访问本地存储。

虽然高度安全，但默认沙盒对于许多用例可能过于严格。您可以通过向sandbox属性提供特定值来选择性地解除限制：

• allow-forms：允许表单提交。
• allow-modals：允许iFrame打开模态窗口（例如alert()、confirm()、prompt()）。
• allow-popups：允许弹出窗口（例如window.open()）。
• allow-popups-to-escape-sandbox：允许沙盒文档打开新窗口而不继承沙盒限制。
• allow-pointer-lock：允许指针锁定API。
• allow-same-origin：允许iFrame内容被视为与父文档同源，这对于嵌入内容正常运行通常是必需的（例如，访问cookie、本地存储）。请务必谨慎使用。
• allow-scripts：允许JavaScript执行。这是一个强大的权限，只应授予受信任的来源。
• allow-top-navigation：允许iFrame导航顶级浏览上下文（即，更改父窗口的URL）。

最佳实践：始终使用sandbox属性。从默认值（无值）开始，并且只添加最少的必要权限。例如，如果您要嵌入支付表单，您可能需要allow-forms allow-scripts，但您绝对不希望allow-same-origin，除非绝对必要并经过彻底审查。

<iframe src="https://trusted-payment-gateway.com/form" sandbox="allow-forms allow-scripts"></iframe>

2. 内容安全策略（CSP）：控制内容加载

内容安全策略（CSP）是一种强大的安全机制，有助于缓解各种类型的攻击，包括XSS和数据注入。通过HTTP头（Content-Security-Policy）或<meta>标签定义CSP，您可以指定允许浏览器加载和执行哪些内容源。

对于iFrame安全，CSP在两个主要方面至关重要：

• 保护父级免受iFrame影响：父页面上的强大CSP可以防止被利用的iFrame将恶意脚本或内容加载到您的主应用程序中。
• 保护iFrame免受父级影响（反之亦然）：frame-src指令专门控制iFrame的有效来源。frame-ancestors指令规定了哪些来源被允许在iFrame中嵌入当前资源（您的页面），从而防止点击劫持。

CSP头示例：

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com; frame-src 'self' https://trusted-iframe-source.com; frame-ancestors 'self';

此CSP仅允许来自您自己来源和trusted-cdn.com的脚本，并且仅允许来自您自己来源和trusted-iframe-source.com的iFrame。至关重要的是，frame-ancestors 'self'确保您的页面只能由其本身嵌入，从而有效防止点击劫持。

防御点击劫持：X-Frame-Options和frame-ancestors

点击劫持（UI重定向）是一种攻击，恶意网站将您的网站的透明iFrame叠加到他们自己的网站上，诱骗用户点击您网站的元素，同时让他们以为正在与恶意网站交互。这可能导致未经授权的操作，例如进行购买、更改设置或泄露敏感信息。

1. X-Frame-Options HTTP头

X-Frame-Options HTTP头是防止点击劫持的传统方法。它告诉浏览器页面是否可以在<frame>、<iframe>、<embed>或<object>中呈现。

• X-Frame-Options: DENY：页面不能在框架中显示，无论尝试这样做的网站是什么。这是最安全的选择。
• X-Frame-Options: SAMEORIGIN：页面只能在与页面本身同源的框架中显示。

最佳实践：除非您明确需要您的页面被其他网站嵌入（如果是这样，请谨慎使用frame-ancestors），否则对于所有处理敏感用户操作的页面，请设置X-Frame-Options: DENY。

2. CSP的frame-ancestors指令

内容安全策略中的frame-ancestors指令是X-Frame-Options的更现代和更灵活的替代方案。它允许您指定允许嵌入您的内容的多个来源。

示例：

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

这允许您的页面被其本身和partner-site.com嵌入。如果同时存在X-Frame-Options和frame-ancestors，在现代浏览器中，frame-ancestors通常会优先。为了更广泛的浏览器兼容性，同时使用两者是良好的实践。

负责任的数据处理和通信

当iFrame需要与其父窗口通信时（反之亦然），直接的JavaScript访问通常会被同源策略阻止。跨源通信的推荐安全方法是window.postMessage()。

安全使用window.postMessage()

window.postMessage()允许窗口安全地跨不同来源进行通信。但是，正确使用它对于避免漏洞至关重要。

• 始终验证发送者的来源：接收消息时，务必检查event.origin属性，以确保消息来自预期的来源。
• 指定目标来源：发送消息时，提供确切的目标来源（例如，iframeWindow.postMessage('hello', 'https://expected-origin.com');），而不是'*'。使用'*'意味着任何窗口都可能接收您的消息，这是一种安全风险。
• 净化接收到的数据：将通过postMessage()接收到的任何数据视为不可信输入，并在使用前对其进行净化，以防止XSS。

示例（父级发送到iFrame）：

const iframe = document.getElementById('myIframe');
iframe.contentWindow.postMessage('Hello from parent!', 'https://trusted-iframe-source.com');

示例（iFrame从父级接收）：

window.addEventListener('message', (event) => {
  if (event.origin !== 'https://parent-domain.com') {
    // 消息不是来自预期来源，忽略或记录。
    return;
  }
  console.log('Message from parent:', event.data);
  // 处理数据，但首先要净化它！
});

Didit如何帮助实现安全可嵌入工作流

Didit作为一个一体化身份平台，经常利用可嵌入组件来支持其身份验证流程。我们的方法以安全为核心构建，理解强大的iFrame和工作流隔离的关键需求。Didit提供安全的托管验证链接和Web SDK，旨在无缝集成，同时遵守最高的安全标准。

• 托管验证链接：Didit为每个验证会话生成安全、唯一的URL。这些链接将用户重定向到Didit托管的隔离环境，将敏感的验证过程与您的应用程序域完全分离。这消除了您为核心验证进行复杂iFrame沙盒化的需要。
• 具有强大隔离功能的Web SDK：对于需要上下文嵌入的场景，Didit的Web SDK旨在在安全的iFrame中运行，利用最严格必要的sandbox属性。我们使用postMessage()管理安全的跨源通信的复杂性，确保iFrame和您的应用程序之间只交换必要的、经过净化的数据。
• 合规性和认证：Didit通过SOC 2 Type II和ISO 27001认证，并符合GDPR。我们的基础设施和流程旨在安全处理敏感身份数据，从而降低您的合规负担和风险。
• 最小化数据暴露：Didit的架构是隐私设计。对于生物识别验证，自拍照在内存中处理并删除，您的应用程序接收布尔值（例如，“已验证”），而不是原始生物识别数据。这最大限度地减少了任何可嵌入组件中处理的敏感信息。

通过使用Didit预构建的安全可嵌入解决方案，企业可以集成高级身份验证，而无需成为iFrame安全专家，从而使他们能够专注于其核心产品，同时确保用户信任和数据保护。

准备好开始了吗？

保护您的iFrame是构建弹性和值得信赖的Web应用程序的关键一步。通过认真应用沙盒、CSP、X-Frame-Options和安全的postMessage()实践，您可以利用嵌入内容的强大功能，而不会将您的用户或应用程序暴露给不必要的风险。探索Didit的安全身份验证解决方案，了解将强大的安全性集成到您的工作流中是多么容易。

查看Didit定价 | 探索Didit文档 | 试用演示