跳到主要内容

安全

报告安全问题

有关如何正确披露 Electron 漏洞的信息，请参阅 SECURITY.md。

对于上游 Chromium 漏洞：Electron 与 Chromium 的交替版本保持同步。有关更多信息，请参阅 Electron 版本发布时间表 文档。

前言​

作为 Web 开发者，我们通常享受浏览器强大的安全保护网 —— 我们编写的代码相关的风险相对较小。我们的网站在沙盒中被授予有限的权限，并且我们相信我们的用户可以享受到由大型工程师团队构建的浏览器，该浏览器能够快速响应新发现的安全威胁。

当使用 Electron 时，重要的是要理解 Electron 不是 Web 浏览器。它允许您使用熟悉的 Web 技术构建功能丰富的桌面应用程序，但您的代码拥有更大的权力。JavaScript 可以访问文件系统、用户 shell 等。这使您能够构建高质量的本地应用程序，但固有的安全风险会随着授予您的代码的额外权限而增加。

考虑到这一点，请注意，显示来自不受信任来源的任意内容会带来严重的安全风险，而 Electron 并非旨在处理这种情况。事实上，最流行的 Electron 应用程序（Atom、Slack、Visual Studio Code 等）主要显示本地内容（或受信任的、安全的远程内容，不集成 Node）—— 如果您的应用程序执行来自在线来源的代码，您有责任确保该代码不是恶意的。

通用指南​

安全是每个人的责任​

重要的是要记住，您的 Electron 应用程序的安全性是框架基础（Chromium、Node.js）、Electron 本身、所有 NPM 依赖项和您的代码的总体安全性的结果。因此，您有责任遵循一些重要的最佳实践

  • 使您的应用程序与最新的 Electron 框架版本保持同步。 当发布您的产品时，您也同时发布了一个由 Electron、Chromium 共享库和 Node.js 组成的捆绑包。影响这些组件的漏洞可能会影响您的应用程序的安全性。通过将 Electron 更新到最新版本，您可以确保关键漏洞（例如 nodeIntegration 绕过）已被修补，并且无法在您的应用程序中被利用。有关更多信息，请参阅“使用当前版本的 Electron”。

  • 评估您的依赖项。 虽然 NPM 提供了五十万个可重用的软件包，但您有责任选择受信任的第三方库。如果您使用受已知漏洞影响的过时库或依赖于维护不善的代码，您的应用程序安全性可能会受到威胁。

  • 采用安全编码实践。 您的应用程序的第一道防线是您自己的代码。常见的 Web 漏洞，例如跨站脚本 (XSS)，对 Electron 应用程序具有更高的安全影响，因此强烈建议采用安全的软件开发最佳实践并执行安全测试。

隔离不受信任的内容​

每当您从不受信任的来源（例如，远程服务器）接收代码并在本地执行它时，就会存在安全问题。例如，考虑在默认的 BrowserWindow 中显示的远程网站。如果攻击者以某种方式设法更改了所述内容（无论是直接攻击源，还是位于您的应用程序和实际目标之间），他们将能够在用户的机器上执行本地代码。

警告

在任何情况下，您都不应在启用 Node.js 集成的情况下加载和执行远程代码。相反，仅使用本地文件（与您的应用程序打包在一起）来执行 Node.js 代码。要显示远程内容，请使用 <webview> 标签或 WebContentsView，并确保禁用 nodeIntegration 并启用 contextIsolation。

Electron 安全警告

安全警告和建议会打印到开发者控制台。它们仅在二进制文件的名称为 Electron 时显示，表明开发者当前正在查看控制台。

您可以通过在 process.env 或 window 对象上设置 ELECTRON_ENABLE_SECURITY_WARNINGS 或 ELECTRON_DISABLE_SECURITY_WARNINGS 来强制启用或强制禁用这些警告。

清单：安全建议​

您至少应遵循以下步骤来提高应用程序的安全性

  1. 仅加载安全内容
  2. 在所有显示远程内容的渲染器中禁用 Node.js 集成
  3. 在所有渲染器中启用上下文隔离
  4. 启用进程沙盒
  5. 在所有加载远程内容的会话中使用 ses.setPermissionRequestHandler()
  6. 不要禁用 webSecurity
  7. 定义 Content-Security-Policy 并使用限制性规则（即 script-src 'self'）
  8. 不要启用 allowRunningInsecureContent
  9. 不要启用实验性功能
  10. 不要使用 enableBlinkFeatures
  11. <webview>：不要使用 allowpopups
  12. <webview>：验证选项和参数
  13. 禁用或限制导航
  14. 禁用或限制创建新窗口
  15. 不要将 shell.openExternal 与不受信任的内容一起使用
  16. 使用当前版本的 Electron
  17. 验证所有 IPC 消息的 sender
  18. 避免使用 file:// 协议，而首选使用自定义协议
  19. 检查您可以更改哪些熔断器
  20. 不要将 Electron API 暴露给不受信任的 Web 内容

为了自动化检测错误配置和不安全模式，可以使用 Electronegativity。有关使用 Electron 开发应用程序时潜在的弱点和实现错误的更多详细信息，请参阅此 开发者和审计师指南。

1. 仅加载安全内容​

任何未包含在您的应用程序中的资源都应使用安全协议（如 HTTPS）加载。换句话说，不要使用不安全协议（如 HTTP）。同样，我们建议使用 WSS 而不是 WS，使用 FTPS 而不是 FTP，等等。

为什么？​

HTTPS 有两个主要优点

  1. 它确保数据完整性，断言数据在您的应用程序和主机之间传输时未被修改。
  2. 它加密您的用户和目标主机之间的流量，使其更难以窃听您的应用程序和主机之间发送的信息。

如何操作？​

main.js（主进程）
// Bad
browserWindow.loadURL('http://example.com')

// Good
browserWindow.loadURL('https://example.com')
index.html（渲染进程）
<!-- Bad -->
<script crossorigin src="http://example.com/react.js"></script>
<link rel="stylesheet" href="http://example.com/style.css">

<!-- Good -->
<script crossorigin src="https://example.com/react.js"></script>
<link rel="stylesheet" href="https://example.com/style.css">

2. 不要为远程内容启用 Node.js 集成​

信息

此建议是 Electron 5.0.0 以来的默认行为。

至关重要的是，您不要在任何加载远程内容的渲染器（BrowserWindow、WebContentsView 或 <webview>）中启用 Node.js 集成。目标是限制您授予远程内容的权限，从而使攻击者如果能够获得在您的网站上执行 JavaScript 的能力，就难以对您的用户造成损害。

在此之后，您可以为特定主机授予额外的权限。例如，如果您正在打开一个指向 https://example.com/ 的 BrowserWindow，您可以为该网站提供它所需的确切能力，但不能更多。

为什么？​

如果攻击者可以跳出渲染器进程并在用户的计算机上执行代码，则跨站脚本 (XSS) 攻击会更加危险。跨站脚本攻击相当常见 —— 虽然是一个问题，但它们的力量通常仅限于破坏它们在其上执行的网站。禁用 Node.js 集成有助于防止 XSS 升级为所谓的“远程代码执行” (RCE) 攻击。

如何操作？​

main.js（主进程）
// Bad
const mainWindow = new BrowserWindow({
  webPreferences: {
    contextIsolation: false,
    nodeIntegration: true,
    nodeIntegrationInWorker: true
  }
})

mainWindow.loadURL('https://example.com')
main.js（主进程）
// Good
const mainWindow = new BrowserWindow({
  webPreferences: {
    preload: path.join(app.getAppPath(), 'preload.js')
  }
})

mainWindow.loadURL('https://example.com')
index.html（渲染进程）
<!-- Bad -->
<webview nodeIntegration src="page.html"></webview>

<!-- Good -->
<webview src="page.html"></webview>

当禁用 Node.js 集成时，您仍然可以将 API 公开给您的网站，这些 API 确实会使用 Node.js 模块或功能。预加载脚本继续可以访问 require 和其他 Node.js 功能，允许开发者通过 contextBridge API 向远程加载的内容公开自定义 API。

3. 启用上下文隔离​

信息

上下文隔离是 Electron 12.0.0 以来的默认行为。

上下文隔离是 Electron 的一项功能，允许开发者在专用的 JavaScript 上下文中运行预加载脚本和 Electron API 中的代码。实际上，这意味着像 Array.prototype.push 或 JSON.parse 这样的全局对象不能被渲染器进程中运行的脚本修改。

Electron 使用与 Chromium 的 内容脚本 相同的技术来启用此行为。

即使使用 nodeIntegration: false，为了真正强制执行强隔离并防止使用 Node 原语，也必须使用 contextIsolation。

信息

有关 contextIsolation 是什么以及如何启用它的更多信息，请参阅我们的专用 上下文隔离 文档。

4. 启用进程沙盒​

沙盒 是 Chromium 的一项功能，它使用操作系统来显着限制渲染器进程可以访问的内容。您应该在所有渲染器中启用沙盒。不建议在未沙盒的进程（包括主进程）中加载、读取或处理任何不受信任的内容。

信息

有关进程沙盒是什么以及如何启用它的更多信息，请参阅我们的专用 进程沙盒 文档。

5. 处理来自远程内容的会话权限请求​

您可能在使用 Chrome 时看到过权限请求：每当网站尝试使用用户必须手动批准的功能（例如通知）时，它们就会弹出。

该 API 基于 Chromium 权限 API，并实现相同类型的权限。

为什么？​

默认情况下，Electron 将自动批准所有权限请求，除非开发者手动配置了自定义处理程序。虽然这是一个可靠的默认值，但具有安全意识的开发者可能希望采取完全相反的做法。

如何操作？​

main.js（主进程）
const { session } = require('electron')
const { URL } = require('url')

session
  .fromPartition('some-partition')
  .setPermissionRequestHandler((webContents, permission, callback) => {
    const parsedUrl = new URL(webContents.getURL())

    if (permission === 'notifications') {
      // Approves the permissions request
      callback(true)
    }

    // Verify URL
    if (parsedUrl.protocol !== 'https:' || parsedUrl.host !== 'example.com') {
      // Denies the permissions request
      return callback(false)
    }
  })

6. 不要禁用 webSecurity​

信息

此建议是 Electron 的默认设置。

您可能已经猜到，禁用渲染器进程（BrowserWindow、WebContentsView 或 <webview>）上的 webSecurity 属性会禁用关键的安全功能。

不要在生产应用程序中禁用 webSecurity。

为什么？​

禁用 webSecurity 将禁用同源策略并将 allowRunningInsecureContent 属性设置为 true。换句话说，它允许执行来自不同域的不安全代码。

如何操作？​

main.js（主进程）
// Bad
const mainWindow = new BrowserWindow({
  webPreferences: {
    webSecurity: false
  }
})
main.js（主进程）
// Good
const mainWindow = new BrowserWindow()
index.html（渲染进程）
<!-- Bad -->
<webview disablewebsecurity src="page.html"></webview>

<!-- Good -->
<webview src="page.html"></webview>

7. 定义内容安全策略​

内容安全策略 (CSP) 是针对跨站脚本攻击和数据注入攻击的额外保护层。我们建议您为您在 Electron 中加载的任何网站启用它们。

为什么？​

CSP 允许提供内容的服务器限制和控制 Electron 可以为给定网页加载的资源。应该允许 https://example.com 从您定义的来源加载脚本，而不应允许运行来自 https://evil.attacker.com 的脚本。定义 CSP 是提高应用程序安全性的简单方法。

如何操作？​

以下 CSP 将允许 Electron 执行来自当前网站和 apis.example.com 的脚本。

// Bad
Content-Security-Policy: '*'

// Good
Content-Security-Policy: script-src 'self' https://apis.example.com

CSP HTTP 标头​

Electron 遵循 Content-Security-Policy HTTP 标头，可以使用 Electron 的 webRequest.onHeadersReceived 处理程序进行设置

main.js（主进程）
const { session } = require('electron')

session.defaultSession.webRequest.onHeadersReceived((details, callback) => {
  callback({
    responseHeaders: {
      ...details.responseHeaders,
      'Content-Security-Policy': ['default-src \'none\'']
    }
  })
})

CSP meta 标签​

CSP 的首选交付机制是 HTTP 标头。但是，当使用 file:// 协议加载资源时，无法使用此方法。在某些情况下，直接在标记中使用 <meta> 标签在页面上设置策略可能很有用

index.html（渲染进程）
<meta http-equiv="Content-Security-Policy" content="default-src 'none'">

8. 不要启用 allowRunningInsecureContent​

信息

此建议是 Electron 的默认设置。

默认情况下，Electron 不允许通过 HTTPS 加载的网站从不安全来源 (HTTP) 加载和执行脚本、CSS 或插件。将属性 allowRunningInsecureContent 设置为 true 会禁用该保护。

通过 HTTPS 加载网站的初始 HTML 并尝试通过 HTTP 加载后续资源也称为“混合内容”。

为什么？​

通过 HTTPS 加载内容可确保加载资源的真实性和完整性，同时加密流量本身。有关更多详细信息，请参阅有关 仅显示安全内容 的部分。

如何操作？​

main.js（主进程）
// Bad
const mainWindow = new BrowserWindow({
  webPreferences: {
    allowRunningInsecureContent: true
  }
})
main.js（主进程）
// Good
const mainWindow = new BrowserWindow({})

9. 不要启用实验性功能​

信息

此建议是 Electron 的默认设置。

Electron 的高级用户可以使用 experimentalFeatures 属性启用实验性 Chromium 功能。

为什么？​

顾名思义，实验性功能是实验性的，尚未为所有 Chromium 用户启用。此外，它们对整个 Electron 的影响可能尚未经过测试。

存在合理的用例，但是除非您知道自己在做什么，否则不应启用此属性。

如何操作？​

main.js（主进程）
// Bad
const mainWindow = new BrowserWindow({
  webPreferences: {
    experimentalFeatures: true
  }
})
main.js（主进程）
// Good
const mainWindow = new BrowserWindow({})

10. 不要使用 enableBlinkFeatures​

信息

此建议是 Electron 的默认设置。

Blink 是 Chromium 背后的渲染引擎的名称。与 experimentalFeatures 一样，enableBlinkFeatures 属性允许开发者启用默认情况下已禁用的功能。

为什么？​

一般来说，如果某个功能默认情况下未启用，则可能存在充分的理由。存在启用特定功能的合理用例。作为开发者，您应该确切地知道为什么需要启用某个功能、其后果是什么以及它如何影响应用程序的安全性。在任何情况下，您都不应推测性地启用功能。

如何操作？​

main.js（主进程）
// Bad
const mainWindow = new BrowserWindow({
  webPreferences: {
    enableBlinkFeatures: 'ExecCommandInJavaScript'
  }
})
main.js（主进程）
// Good
const mainWindow = new BrowserWindow()

11. 不要对 WebViews 使用 allowpopups​

信息

此建议是 Electron 的默认设置。

如果您正在使用 <webview>，您可能需要加载到您的 <webview> 标签中的页面和脚本来打开新窗口。allowpopups 属性使它们能够使用 window.open() 方法创建新的 BrowserWindow。否则，<webview> 标签不允许创建新窗口。

为什么？​

如果您不需要弹出窗口，最好默认情况下不允许创建新的 BrowserWindow。这遵循最小所需访问权限的原则：除非您知道网站需要该功能，否则不要让网站创建新的弹出窗口。

如何操作？​

index.html（渲染进程）
<!-- Bad -->
<webview allowpopups src="page.html"></webview>

<!-- Good -->
<webview src="page.html"></webview>

12. 在创建之前验证 WebView 选项​

在未启用 Node.js 集成的渲染器进程中创建的 WebView 将无法自行启用集成。但是，WebView 始终会创建一个独立的渲染器进程，并带有自己的 webPreferences。

最好控制从主进程创建新的 <webview> 标签，并验证它们的 webPreferences 是否未禁用安全功能。

为什么？​

由于 <webview> 存在于 DOM 中，因此即使 Node.js 集成在其他情况下被禁用，它们也可以由在您的网站上运行的脚本创建。

Electron 使开发者能够禁用控制渲染器进程的各种安全功能。在大多数情况下，开发者不需要禁用任何这些功能 —— 因此您不应允许为新创建的 <webview> 标签使用不同的配置。

如何操作？​

在附加 <webview> 标签之前，Electron 将在托管 webContents 上触发 will-attach-webview 事件。使用此事件来阻止创建可能具有不安全选项的 webViews。

main.js（主进程）
app.on('web-contents-created', (event, contents) => {
  contents.on('will-attach-webview', (event, webPreferences, params) => {
    // Strip away preload scripts if unused or verify their location is legitimate
    delete webPreferences.preload

    // Disable Node.js integration
    webPreferences.nodeIntegration = false

    // Verify URL being loaded
    if (!params.src.startsWith('https://example.com/')) {
      event.preventDefault()
    }
  })
})

同样，此列表仅最大限度地降低风险，但并未消除风险。如果您的目标是显示网站，则浏览器将是更安全的选择。

13. 禁用或限制导航​

如果您的应用程序不需要导航，或者只需要导航到已知的页面，那么最好将导航完全限制在已知的范围内，不允许任何其他类型的导航。

为什么？​

导航是一种常见的攻击媒介。如果攻击者可以说服您的应用程序导航离开其当前页面，他们可能会强制您的应用程序打开 Internet 上的网站。即使您的 webContents 配置为更安全（例如禁用 nodeIntegration 或启用 contextIsolation），让您的应用程序打开随机网站也会使攻击者更容易利用您的应用程序。

一种常见的攻击模式是攻击者说服您的应用程序的用户以某种方式与应用程序交互，使其导航到攻击者的页面之一。这通常通过链接、插件或其他用户生成的内容来完成。

如何操作？​

如果您的应用程序不需要导航，您可以在 will-navigate 处理程序中调用 event.preventDefault()。如果您知道您的应用程序可能导航到哪些页面，请在事件处理程序中检查 URL，并且仅当它与您期望的 URL 匹配时才允许导航发生。

我们建议您使用 Node 的解析器来解析 URL。简单的字符串比较有时可能会被愚弄 —— startsWith('https://example.com') 测试会让 https://example.com.attacker.com 通过。

main.js（主进程）
const { URL } = require('url')
const { app } = require('electron')

app.on('web-contents-created', (event, contents) => {
  contents.on('will-navigate', (event, navigationUrl) => {
    const parsedUrl = new URL(navigationUrl)

    if (parsedUrl.origin !== 'https://example.com') {
      event.preventDefault()
    }
  })
})

14. 禁用或限制创建新窗口​

如果您有一组已知的窗口，那么最好限制在您的应用程序中创建其他窗口。

为什么？​

与导航非常相似，创建新的 webContents 是一种常见的攻击媒介。攻击者试图说服您的应用程序创建新的窗口、框架或其他渲染器进程，这些进程比以前拥有更多的权限；或者打开他们以前无法打开的页面。

如果您不需要创建除您知道需要创建的窗口之外的其他窗口，禁用创建会以零成本为您购买一点额外的安全性。对于打开一个 BrowserWindow 并且不需要在运行时打开任意数量的额外窗口的应用程序来说，通常是这种情况。

如何操作？​

webContents 将在创建新窗口之前委托给其 窗口打开处理程序。处理程序将接收窗口请求打开的 url 以及用于创建它的选项等参数。我们建议您注册一个处理程序来监视窗口的创建，并拒绝任何意外的窗口创建。

main.js（主进程）
const { app, shell } = require('electron')

app.on('web-contents-created', (event, contents) => {
  contents.setWindowOpenHandler(({ url }) => {
    // In this example, we'll ask the operating system
    // to open this event's url in the default browser.
    //
    // See the following item for considerations regarding what
    // URLs should be allowed through to shell.openExternal.
    if (isSafeForExternalOpen(url)) {
      setImmediate(() => {
        shell.openExternal(url)
      })
    }

    return { action: 'deny' }
  })
})

15. 不要将 shell.openExternal 与不受信任的内容一起使用​

shell 模块的 openExternal API 允许使用桌面的本地实用程序打开给定的协议 URI。例如，在 macOS 上，此功能类似于 open 终端命令实用程序，并将根据 URI 和文件类型关联打开特定的应用程序。

为什么？​

不正确地使用 openExternal 可能会被利用来危害用户的主机。当 openExternal 与不受信任的内容一起使用时，它可以被利用来执行任意命令。

如何操作？​

main.js（主进程）
//  Bad
const { shell } = require('electron')
shell.openExternal(USER_CONTROLLED_DATA_HERE)
main.js（主进程）
//  Good
const { shell } = require('electron')
shell.openExternal('https://example.com/index.html')

16. 使用当前版本的 Electron​

您应该努力始终使用最新可用的 Electron 版本。每当发布新的主要版本时，您都应尝试尽快更新您的应用程序。

为什么？​

使用较旧版本的 Electron、Chromium 和 Node.js 构建的应用程序比使用较新版本的这些组件的应用程序更容易成为攻击目标。一般来说，较旧版本的 Chromium 和 Node.js 的安全问题和漏洞利用程序更广泛可用。

Chromium 和 Node.js 都是由成千上万才华横溢的开发者构建的令人印象深刻的工程壮举。鉴于它们的普及性，它们的安全性受到了同样熟练的安全研究人员的仔细测试和分析。许多研究人员 负责任地披露漏洞，这通常意味着研究人员会给 Chromium 和 Node.js 一些时间来修复问题，然后再发布它们。如果您的应用程序正在运行最新版本的 Electron（以及 Chromium 和 Node.js），那么潜在的安全问题就不会那么广为人知，您的应用程序将会更安全。

如何？​

一次迁移一个主要版本的应用程序，同时参考 Electron 的 Breaking Changes 文档，查看是否需要更新任何代码。

17. 验证所有 IPC 消息的 sender​

您应该始终验证传入的 IPC 消息 sender 属性，以确保您不会对不受信任的渲染器执行操作或发送信息。

为什么？​

理论上，所有 Web 框架都可以向主进程发送 IPC 消息，包括 iframe 和某些情况下的子窗口。如果您有 IPC 消息通过 event.reply 向发送者返回用户数据，或者执行渲染器本身无法执行的特权操作，则应确保您没有监听来自第三方 Web 框架的消息。

默认情况下，您应该验证所有 IPC 消息的 sender。

如何？​

main.js（主进程）
// Bad
ipcMain.handle('get-secrets', () => {
  return getSecrets()
})

// Good
ipcMain.handle('get-secrets', (e) => {
  if (!validateSender(e.senderFrame)) return null
  return getSecrets()
})

function validateSender (frame) {
  // Value the host of the URL using an actual URL parser and an allowlist
  if ((new URL(frame.url)).host === 'electronjs.org') return true
  return false
}

18. 避免使用 file:// 协议，并优先使用自定义协议​

您应该从自定义协议而不是 file:// 协议提供本地页面。

为什么？​

与 Web 浏览器相比，file:// 协议在 Electron 中获得更多特权，即使在浏览器中，它与 http/https URL 的处理方式也不同。使用自定义协议可以让您更符合经典的 Web URL 行为，同时保留更多关于可以加载什么以及何时加载的控制权。

在 file:// 上运行的页面可以单方面访问您机器上的每个文件，这意味着 XSS 问题可用于从用户机器加载任意文件。使用自定义协议可以防止此类问题，因为您可以将协议限制为仅提供一组特定的文件。

如何？​

按照 protocol.handle 示例学习如何从自定义协议提供文件/内容。

19. 检查您可以更改哪些熔断器（fuses）​

Electron 附带了许多有用的选项，但大部分应用程序可能不需要。为了避免构建您自己的 Electron 版本，可以使用 Fuses 来关闭或打开这些选项。

为什么？​

某些熔断器（fuses），如 runAsNode 和 nodeCliInspect，允许应用程序在使用特定的环境变量或 CLI 参数从命令行运行时表现不同。这些可用于通过您的应用程序在设备上执行命令。

这可能允许外部脚本运行它们可能不允许的命令，但您的应用程序可能具有运行这些命令的权限。

如何？​

我们制作了一个模块 @electron/fuses，以简化这些熔断器（fuses）的切换。查看该模块的 README 以了解更多关于用法和潜在错误情况的详细信息，并参考我们文档中的 如何切换熔断器（fuses）？。

20. 不要将 Electron API 暴露给不受信任的 Web 内容​

您不应直接将 Electron 的 API（尤其是 IPC）暴露给预加载脚本中不受信任的 Web 内容。

为什么？​

暴露像 ipcRenderer.on 这样的原始 API 是危险的，因为它使渲染器进程可以直接访问整个 IPC 事件系统，允许它们监听任何 IPC 事件，而不仅仅是那些 intended for them 的事件。

为了避免这种暴露，我们也不能直接传递回调：IPC 事件回调的第一个参数是 IpcRendererEvent 对象，其中包含诸如 sender 之类的属性，这些属性提供对底层 ipcRenderer 实例的访问。即使您只监听特定的事件，直接传递回调也意味着渲染器可以访问此事件对象。

简而言之，我们希望不受信任的 Web 内容只能访问必要的信息和 API。

如何？​

预加载
// Bad
contextBridge.exposeInMainWorld('electronAPI', {
  on: ipcRenderer.on
})

// Also bad
contextBridge.exposeInMainWorld('electronAPI', {
  onUpdateCounter: (callback) => ipcRenderer.on('update-counter', callback)
})

// Good
contextBridge.exposeInMainWorld('electronAPI', {
  onUpdateCounter: (callback) => ipcRenderer.on('update-counter', (_event, value) => callback(value))
})
信息

有关 contextIsolation 是什么以及如何使用它来保护您的应用程序的更多信息，请参阅 Context Isolation 文档。