在 Electron 的早期版本中，为了让渲染进程能够方便地调用 Node.js 和 Electron 的原生功能，开发者往往会直接在创建窗口时启用 nodeIntegration: true，并在渲染进程里随意 require('fs') 或 require('electron')。这种“敞开大门”的做法虽然开发便捷，却埋下了严重的安全隐患：页面中运行的任何脚本（包括可能被注入的恶意代码）都能获得与桌面应用完全相同的系统权限。一旦你的应用加载了不可信的外部内容，或者存在 XSS 漏洞，攻击者就能直接读写用户文件、执行系统命令、窃取敏感数据。
为了解决这一问题，Electron 从安全设计的根本上引入了一套完整的上下文隔离机制，通过 contextIsolation、preload 脚本和 contextBridge 三者的配合，在渲染进程与主进程之间架起了一座严格受控的“安检通道”。这一机制目前（自 Electron 12 起）已是默认启用的推荐配置，也是每一个 Electron 应用都应当遵循的安全基线。
4.4.1 什么是上下文隔离
在默认情况下，Electron 的渲染进程内部其实存在两个独立的 JavaScript 执行环境：
- 网页上下文（Web Context）：运行你写的 HTML 页面脚本，可以访问 DOM、
window对象、Web API，但不能直接访问 Node.js 或 Electron 的模块。你日常使用的document.querySelector、fetch等都处在这个环境中。 - 预加载上下文（Preload Context）：在页面脚本执行之前运行的沙箱环境，这个环境有权使用一部分 Node.js 和 Electron 的 API（例如
require、process、ipcRenderer等），但它无法直接访问 DOM，也不能被网页脚本直接访问。
启用 contextIsolation: true（Electron 12+ 的默认值）后，这两个上下文会被彻底隔离。网页脚本中绝对不能直接 require 任何模块，也无法获取到 Electron 的内部对象。这意味着即使攻击者在页面中成功执行了恶意 JS，他能接触的最大范围也只限于普通的浏览器 API，完全摸不到文件系统或系统级接口。
这是现代 Electron 应用安全的第一道防线：权限分离。渲染进程不再是一个拥有 root 权限的环境，而回归到了它本来的面貌：一个纯粹的展示层。
4.4.2 contextBridge：安全暴露的桥梁
上下文隔离了之后，渲染进程如何与主进程通信呢？答案就是 contextBridge。
contextBridge 是 Electron 提供的一个专门用于在预加载脚本中将主进程能力安全暴露给网页上下文的 API。它的作用类似一扇只能从“预加载侧”打开的小窗，你可以精确控制网页能够看到和调用哪些方法，以及这些方法背后执行的是什么代码。
一个典型的预加载脚本如下：
// preload.js
const { contextBridge, ipcRenderer } = require('electron');
contextBridge.exposeInMainWorld('electronAPI', {
// 发送单向消息（不期待返回值）
sendMessage: (channel, data) => {
const validChannels = ['toMain:save-file', 'toMain:open-dialog'];
if (validChannels.includes(channel)) {
ipcRenderer.send(channel, data);
}
},
// 调用主进程方法并获取返回值（Promise 形式）
invoke: (channel, ...args) => {
const validChannels = ['dialog:openFile', 'app:getVersion'];
if (validChannels.includes(channel)) {
return ipcRenderer.invoke(channel, ...args);
}
return Promise.reject(new Error('Invalid channel'));
},
// 监听来自主进程的消息
onReceive: (channel, callback) => {
const validChannels = ['fromMain:update-status'];
if (validChannels.includes(channel)) {
ipcRenderer.on(channel, (event, ...args) => callback(...args));
}
},
});然后在网页脚本中就可以安全地使用：
// renderer.js
window.electronAPI.invoke('dialog:openFile').then(filePath => {
console.log('选择的文件：', filePath);
});
window.electronAPI.onReceive('fromMain:update-status', (status) => {
document.getElementById('status').textContent = status;
});关键点在于：网页看到的只是一个普通的 JS 对象 window.electronAPI，它根本不知道背后有 ipcRenderer 的存在。这个对象里只包含你精心挑选并暴露出去的方法，攻击者即便拿到了这个对象，也只能调用你允许的那些功能，并且每条通道还加了白名单校验。这是安全机制的第二道防线：接口裁剪与通道白名单。
4.4.3 为什么不能直接暴露 ipcRenderer
有些开发者可能会偷懒，在 preload 中把整个 ipcRenderer 对象直接挂到 window 上：
// ❌ 极度危险的做法
contextBridge.exposeInMainWorld('ipc', {
send: ipcRenderer.send,
invoke: ipcRenderer.invoke,
on: ipcRenderer.on,
// ...
});这样做虽然代码量少，但相当于把大门钥匙交给了所有人。网页脚本可以借此向主进程发送任意通道的消息，进而触发可能危险的操作（例如通过 fs 模块删除文件）。假如你有一段主进程代码监听了 delete-all-files 这个通道并执行了危险操作，恶意脚本只要发送这个通道消息就能完成攻击。通道白名单正是为了防止这种“万能钥匙”式的滥用。
所以，实践中必须做到两点：
- 永远不要直接暴露
ipcRenderer或任何能直接使用它的对象。 - 在 preload 中封装具体功能函数，只暴露有限、明确、经过参数校验的接口。
4.4.4 安全通信最佳实践
除了上述的 contextBridge 与通道白名单之外，以下几个实践能够让通信安全性再提升一个等级：
1. 使用 invoke/handle 替代 send/on 进行请求-响应式通信
ipcRenderer.invoke 和 ipcMain.handle 返回 Promise，更适合“请求-应答”模式，它们天然是一次性的、有明确返回值的，不容易留下长期监听带来的安全隐患。同时，你可以在 handle 中对参数做更严格的校验和净化。
// 主进程
ipcMain.handle('file:save', async (event, filePath, content) => {
// 校验路径是否合法，防止目录遍历攻击
if (!isValidPath(filePath)) throw new Error('Invalid path');
await fs.promises.writeFile(filePath, content, 'utf-8');
return { success: true };
});2. 对从渲染进程传来的所有数据进行严格验证
永远不要信任来自渲染进程的任何数据，即使它们是通过你精心设计的通道传过来的。攻击者可能控制了渲染进程并调用你暴露的 API，传入格式异常或包含恶意载荷的数据。在主进程的 handle 或 on 回调中，务必检查参数类型、长度、范围，并使用白名单而非黑名单进行过滤。
3. 永远不要用 eval 或动态执行来自 IPC 的代码
无论任何情况下，都不要在主进程中对从渲染进程接收到的字符串执行 eval() 或 new Function() 等操作。这类行为会直接破坏进程隔离的保护边界。
4. 慎用 remote 模块（已废弃）
如果你在一些老项目中看到 require('@electron/remote')，应该清楚它正是为了绕过上下文隔离而存在的，它几乎让渲染进程再次获得了主进程的全部权限。新项目必须彻底禁用 remote 模块，旧项目也应尽快迁移到基于 IPC 的安全通信模式。
5. 结合内容安全策略（CSP）加固
在 HTML 中设置严格的 CSP 头可以防止 XSS 攻击，进一步减小恶意脚本成功运行的可能性。例如：
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self'">这会让攻击者即使找到了注入点，也无法加载外部恶意脚本或执行内联 JS，使得上下文隔离的安全优势得到充分发挥。
4.4.5 一个完整的实操例程
让我们把上述原则落实到一个实际的小例子：一个安全的文本编辑器，渲染进程只能通过指定通道请求“打开文件”和“保存文件”，主进程执行操作并返回结果。
主进程 main.js：
const { app, BrowserWindow, ipcMain, dialog } = require('electron');
const fs = require('fs');
const path = require('path');
function createWindow() {
const win = new BrowserWindow({
width: 800,
height: 600,
webPreferences: {
preload: path.join(__dirname, 'preload.js'),
contextIsolation: true, // 启用上下文隔离
nodeIntegration: false, // 关闭 Node 集成
sandbox: true // 开启沙箱进一步限制
}
});
win.loadFile('index.html');
}
// 安全的文件打开
ipcMain.handle('file:open', async () => {
const { canceled, filePaths } = await dialog.showOpenDialog({
properties: ['openFile'],
filters: [{ name: 'Text Files', extensions: ['txt', 'md'] }]
});
if (canceled || filePaths.length === 0) return null;
const filePath = filePaths[0];
const content = await fs.promises.readFile(filePath, 'utf-8');
return { filePath, content };
});
// 安全的文件保存
ipcMain.handle('file:save', async (event, filePath, content) => {
// 简单校验：不允许路径包含非法字符
if (!filePath || filePath.includes('..')) throw new Error('Invalid path');
await fs.promises.writeFile(filePath, content, 'utf-8');
return { success: true };
});
app.whenReady().then(createWindow);预加载脚本 preload.js：
const { contextBridge, ipcRenderer } = require('electron');
contextBridge.exposeInMainWorld('fileAPI', {
openFile: () => ipcRenderer.invoke('file:open'),
saveFile: (filePath, content) => ipcRenderer.invoke('file:save', filePath, content)
});渲染进程 renderer.js（通过 index.html 引入）：
document.getElementById('btn-open').addEventListener('click', async () => {
const result = await window.fileAPI.openFile();
if (result) {
document.getElementById('editor').value = result.content;
document.getElementById('filepath').textContent = result.filePath;
}
});
document.getElementById('btn-save').addEventListener('click', async () => {
const filePath = document.getElementById('filepath').textContent;
const content = document.getElementById('editor').value;
await window.fileAPI.saveFile(filePath, content);
alert('保存成功');
});在这个架构下，渲染进程只看得见 window.fileAPI.openFile 和 saveFile 两个纯粹的方法，根本没有触及任何文件系统模块。即使有人在开发工具控制台里胡乱调用，也不可能脱离这两个方法的设计范围去任意读文件。主进程在收到请求后还会进行路径合法性校验，防止目录穿越攻击。这就是上下文隔离带来的真正安全 —— 你可以安心地把注意力放在业务实现上，而框架层的防线已经帮你挡住了绝大多数常见的攻击面。
4.4.6 常见误解与警示
误解1：“我的应用不加载外部内容，不需要上下文隔离。”
错。即使你的应用全部使用本地资源，依然可能存在漏洞。比如渲染进程从某个持久化存储（如 IndexedDB）读取了一段不受信任的数据，并插入了 innerHTML，就可能触发 XSS。上下文隔离使得即使发生这种情况，攻击者也无法接触到 Node.js 环境，将损害降到最低。
误解2：“我已经用了 contextBridge，通道白名单无所谓。”
通道白名单是纵深防御的重要一环。如果你只用 contextBridge 暴露了一个通用 invoke 方法但不限制通道名，攻击者仍可以发送任意 IPC 消息给主进程，触发主进程中任意已注册的 handle。而主进程的监听往往是全量注册的，如果不加限制，无异于将全部后端能力拱手送出。
综上所述，上下文隔离与 contextBridge 的组合不是一座可选的装饰性拱门，而是 Electron 应用安全大厦的承重墙。它让每个进程专心于自己的职责，并强迫开发者养成“最小权限”“接口契约”的安全思维。你会发现，一旦适应了这种模式，它不仅没带来效率上的损失，反而因为边界清晰、易于维护，让整体开发体验变得更加清爽和可靠。