2、渲染进程安全：上下文隔离原理与配置、预加载脚本安全实践

好，咱们接着聊渲染进程的安全。这一章我打算重点说说上下文隔离（Context Isolation）和预加载脚本。这两个东西，说白了就是 Electron 安全体系里的「守门员」。很多新手容易忽略它们，但我可以负责任地告诉你——不配好上下文隔离，你的应用基本等于裸奔。

2.1 上下文隔离：为什么它是必须的？

先问个问题：你有没有想过，渲染进程里跑的 JavaScript，到底能不能直接访问 Node.js 的 API？

在早期的 Electron 版本里，默认是可以的。你直接在渲染进程里写 require('fs')，就能读写用户文件。听起来很方便对吧？但方便的背后是巨大的安全隐患。你想啊，如果渲染进程加载了一个恶意第三方脚本，它就能直接调用 child_process.exec 去执行系统命令。这画面太美我不敢看。

上下文隔离，就是来解决这个问题的。它的核心思路是：把渲染进程的 JavaScript 执行环境，和 Node.js 的原生环境彻底隔开。就像两个独立的房间，中间只有一扇装了防盗门的通道——也就是预加载脚本。

核心结论：没有上下文隔离，你的 Electron 应用在 XSS 攻击面前就是纸糊的。我个人习惯，新建项目第一件事就是检查 contextIsolation 有没有设为 true。

2.2 配置上下文隔离

配置其实很简单，就在创建 BrowserWindow 的时候设置。我直接上代码：

const { app, BrowserWindow } = require('electron')

function createWindow () {
  const win = new BrowserWindow({
    width: 800,
    height: 600,
    webPreferences: {
      contextIsolation: true,   // 开启上下文隔离
      nodeIntegration: false,   // 关闭 Node.js 集成
      preload: path.join(__dirname, 'preload.js')
    }
  })

  win.loadFile('index.html')
}

app.whenReady().then(createWindow)

这里有三件事要同时做：

  • contextIsolation: true —— 开启隔离，这是前提
  • nodeIntegration: false —— 关闭 Node.js 直接集成，防止渲染进程直接调用 require
  • preload —— 指定预加载脚本，作为安全通信的桥梁

注意：我曾经见过有人只开了 contextIsolation，但忘了关 nodeIntegration。结果隔离了个寂寞。这两个必须配合使用，缺一不可。

2.3 预加载脚本：安全的桥梁

好，现在隔离已经打开了。渲染进程不能直接碰 Node.js 了。那问题来了——如果渲染进程确实需要调用一些系统功能，比如读写文件、访问剪贴板，怎么办？

答案就是预加载脚本。它运行在一个特殊的「中间层」环境里，既能访问 Node.js API，又能通过 contextBridge 把安全的接口暴露给渲染进程。

我举个例子。假设你需要让渲染进程能读取一个配置文件：

// preload.js
const { contextBridge, ipcRenderer } = require('electron')

contextBridge.exposeInMainWorld('electronAPI', {
  getConfig: () => ipcRenderer.invoke('get-config'),
  setConfig: (config) => ipcRenderer.invoke('set-config', config),
  onUpdate: (callback) => ipcRenderer.on('config-updated', callback)
})

然后在渲染进程里，你就可以这样用：

// renderer.js
const config = await window.electronAPI.getConfig()
console.log('当前配置:', config)

你看，渲染进程只拿到了一个 window.electronAPI 对象，它根本不知道背后是 ipcRenderer 在通信。这就是最小权限原则的体现——只给需要的能力，不给多余的能力。

我的建议：预加载脚本里暴露的接口，越少越好。能只暴露一个函数，就别暴露一个对象。我见过有人直接把整个 fs 模块通过 contextBridge 扔给渲染进程……那跟没开隔离有什么区别？

2.4 预加载脚本的安全陷阱

嗯，这里要注意。预加载脚本虽然安全，但用不好也会出问题。我总结几个常见的坑：

2.4.1 不要暴露 require 本身

有些开发者图省事，直接在预加载脚本里写：

// ❌ 危险做法
contextBridge.exposeInMainWorld('node', {
  require: require
})

这等于把后门钥匙直接交给了渲染进程。恶意脚本拿到 require 后，想加载什么模块都行。

2.4.2 小心参数注入

预加载脚本暴露的函数，接收的参数可能来自不可信的渲染进程。举个例子：

// ❌ 危险做法
contextBridge.exposeInMainWorld('api', {
  readFile: (path) => fs.readFileSync(path, 'utf-8')
})

如果渲染进程传进来一个 ../../etc/passwd 这样的路径，你的系统文件就暴露了。正确的做法是：在预加载脚本里做参数校验和路径白名单。

// ✅ 安全做法
const ALLOWED_PATHS = ['config.json', 'user-data.json']

contextBridge.exposeInMainWorld('api', {
  readFile: (filename) => {
    if (!ALLOWED_PATHS.includes(filename)) {
      throw new Error('不允许访问该文件')
    }
    return fs.readFileSync(filename, 'utf-8')
  }
})

2.4.3 避免在预加载脚本里执行动态代码

不要用 eval、new Function 或者动态 require。这些操作会绕过上下文隔离的安全限制。我曾经在一个项目里看到预加载脚本里写了 eval(userInput)，当时我就知道——这应用迟早要出事。

2.5 上下文隔离的版本变迁

说到这，我得提一下版本问题。Electron 从 12 版本开始，contextIsolation 的默认值变成了 true。如果你还在用老版本，我强烈建议升级。

Electron 版本 contextIsolation 默认值 建议
< 12 false 必须手动设为 true
12+ true 保持默认，不要改回 false

一句话总结：上下文隔离 + 预加载脚本 + IPC 通信，这是 Electron 渲染进程安全的铁三角。少一个，你的应用就多一分风险。

2.6 实战检查清单

最后，我分享一个自己常用的检查清单。每次发布前，我都会过一遍：

  1. 确认 contextIsolation 为 true —— 在 webPreferences 里显式设置
  2. 确认 nodeIntegration 为 false —— 别留后门
  3. 预加载脚本只暴露最小接口 —— 每个暴露的函数都要问自己：真的需要吗？
  4. 对预加载脚本的参数做校验 —— 永远不要信任渲染进程传来的数据
  5. 避免在预加载脚本里使用动态执行 —— eval 和 new Function 是禁区

嗯，这一章的内容差不多就这些。上下文隔离和预加载脚本，说白了就是给渲染进程加了一道「安检门」。配置起来不复杂，但一旦漏掉，后果很严重。下一章我会聊聊更进阶的话题——沙箱化与进程权限控制，到时候咱们再细聊。

← 上一章 📖 返回目录 下一章 →