Electron 早期的版本允许渲染进程直接使用 require('fs') 或 require('electron')，这对于快速原型开发很方便，但也埋下了严重的安全隐患。如果页面中某个第三方脚本或潜在的 XSS 攻击能够执行任意 JavaScript，攻击者就等于获得了用户电脑的完整控制权。为了解决这个问题，Electron 引入了上下文隔离和 contextBridge 机制，强制让能力在受控的前提下暴露给渲染进程。
1. 关闭默认权限，开启上下文隔离
现代 Electron 应用的标准安全配置是：
nodeIntegration: false—— 禁用渲染进程中的 Node.js 集成，require将不可用。contextIsolation: true—— 开启上下文隔离，让预加载脚本运行在独立的 JavaScript 上下文中，与网页内容完全隔离。
这意味着渲染进程的 window 对象和预加载脚本的 window 对象不是同一个，网页代码无法直接访问预加载脚本中定义的变量或函数，除非你明确通过 contextBridge 暴露出来。
这样做的实际效果是：渲染进程的世界里只有纯粹的 DOM、CSS 和你通过桥接提供的一小部分 API，它是一个“沙盒”。即使网页内容被恶意代码入侵，攻击者也触碰不到文件系统、系统命令或是 Electron 的原生模块。
2. contextBridge 的工作原理
在预加载脚本中，你使用 contextBridge.exposeInMainWorld(apiKey, apiObject) 将一组安全的、白名单化的功能挂载到渲染进程的 window 对象上。网页代码就可以通过 window.apiKey 来调用这些被暴露的方法，但完全看不到预加载脚本里的 require 或 Node.js 能力。
一个典型的例子：
preload.js
const { contextBridge, ipcRenderer } = require('electron');
contextBridge.exposeInMainWorld('myApp', {
// 只暴露一个触发“打开文件”请求的方法
openFile: () => ipcRenderer.invoke('dialog:openFile'),
// 只暴露一个加密后的字符串，不会暴露原始 Node.js 对象
getVersion: () => process.env.npm_package_version,
});renderer.js（渲染进程）
document.getElementById('btn').addEventListener('click', async () => {
const filePath = await window.myApp.openFile();
document.getElementById('path').textContent = filePath;
});在这个模式中，渲染进程永远不知道它调用的 openFile 背后是 Node.js 还是主进程的 dialog，它只是通过一个极其狭窄的通道发出请求，并获得一个结果。预加载脚本就是那个负责把“脏活”（权限操作）委托给主进程的中间人。
3. 为什么不能直接把 Node.js API 暴露出去？
很多刚接触 Electron 的开发者会试图直接在 preload 里传递 fs 对象：
// 危险示范！不要这样做
contextBridge.exposeInMainWorld('fs', require('fs'));这样一来，渲染进程中的任何代码都可以通过 window.fs.writeFile 直接写入系统文件，破坏了沙箱隔离。攻击者如果能成功注入一段脚本，就能无声无息地创建或修改用户电脑上的任意文件（比如植入后门、窃取数据），这正是 contextBridge 特别要预防的场景。
正确的做法是：把具体的操作能力封装在主进程中，由渲染进程通过 IPC 请求，并在主进程里做好校验（例如限制可读写的路径范围、文件类型），然后只把执行结果返回。contextBridge 暴露的不是能力本身，而是你筛选过的一层安全调用接口。
4. 真实项目中的白名单暴露模式
在实际项目中，我们通常会在预加载脚本中维护一个清晰的白名单对象，列举应用所有需要从渲染进程触发的操作：
// preload.js
const { contextBridge, ipcRenderer } = require('electron');
contextBridge.exposeInMainWorld('electronAPI', {
// 文件操作
saveFile: (content) => ipcRenderer.invoke('file:save', content),
loadFile: () => ipcRenderer.invoke('file:load'),
// 系统交互
showMessageBox: (options) => ipcRenderer.invoke('dialog:message', options),
setWindowTitle: (title) => ipcRenderer.send('window:setTitle', title),
// 只读状态
platform: process.platform,
});然后在主进程中处理这些 IPC 通道：
// main.js
const { ipcMain, dialog } = require('electron');
const fs = require('fs');
ipcMain.handle('file:save', async (event, content) => {
const { filePath } = await dialog.showSaveDialog({ /* ... */ });
if (filePath) {
fs.writeFileSync(filePath, content, 'utf-8');
return true;
}
return false;
});这带来的好处是：所有涉及系统权限的代码全部集中在主进程的几十行逻辑里，便于审计和维护。你清楚知道自己的应用到底开放了哪些口子给界面层，不会有遗漏的“后门”。
5. TypeScript 友好与类型安全
如果你的项目使用 TypeScript，可以使用 interface 来约束暴露的 API 形状，然后在预加载和渲染进程两侧共享：
// electron.d.ts
interface ElectronAPI {
saveFile: (content: string) => Promise<boolean>;
loadFile: () => Promise<string>;
platform: string;
}
declare global {
interface Window {
electronAPI: ElectronAPI;
}
}这样在渲染进程中调用 window.electronAPI.saveFile('hello') 时会有完整的类型提示和检查，进一步减少了运行时被攻击者利用的可能。
6. 安全底线：最小权限原则
contextBridge 的设计本质上贯彻了最小权限原则：渲染进程只获得它完成界面展示和用户交互所必需的最少能力，其余的一概不知、不可触及。这种设计让 Electron 应用的安全性从“防火墙”模式进化到了“逐间上锁”模式，即便一处失守，也不会导致全局沦陷。
当你建立一个新的 Electron 项目时，默认就应遵循这套受控暴露模型：contextIsolation 开启、nodeIntegration 关闭、预加载脚本通过 contextBridge 提供经过严格封装的函数。对于特殊的场景（如内嵌的可信页面、开发者工具面板），可以基于具体源和上下文进一步收紧或放宽规则，但绝不能再退回全权限的老路上。
最终，你的应用不仅功能完整，而且安全可控——这正是现代桌面应用开发的基本素养。