远程代码执行（Remote Code Execution，RCE）是 Electron 应用面临的最危险的安全威胁之一。一旦攻击者成功利用 RCE 漏洞，就能在用户的操作系统上执行任意指令——读取文件、安装恶意软件、窃取隐私数据，后果不堪设想。理解 RCE 的常见攻击路径，并掌握对应的规避方法，是每个 Electron 开发者必须过的安全关。
24.2.1 RCE 是如何发生的
在 Electron 应用中，RCE 的核心根源几乎总是指向同一个问题：渲染进程获得了过高的权限，并且应用加载或执行了不可信的内容。最常见的攻击入口包括：
1. 加载远程内容且 Node 集成开启
这是历史上最典型的 RCE 场景。假设你的应用加载了一个远程页面（例如广告、帮助文档、第三方登录页），同时该窗口的 webPreferences 中设置了 nodeIntegration: true 且 contextIsolation: false。如果这个远程页面本身被攻击者篡改，或者页面中嵌入了恶意脚本，该脚本就能直接调用 require('child_process').exec() 在用户电脑上执行任意命令。
2. 不安全的 preload 脚本暴露敏感 API
即使关闭了 Node 集成，如果 preload 脚本通过 contextBridge 把危险的主进程能力暴露给了渲染进程，并且渲染进程加载了不可信的内容，攻击者同样可以利用这些暴露的接口。例如，一个看似无害的 shell.openExternal 被暴露出去后，攻击者可以传入精心构造的命令行参数，实现代码执行。
3. webview 标签配置不当
webview 相当于一个嵌入的迷你浏览器，默认情况下它的权限是受限的。但如果开发者为了便利，手工开启了 nodeintegration、allowpopups 等属性，或者没有正确配置 preload、sandbox 选项，那么 webview 中加载的第三方页面就可能成为攻击跳板。
4. 原型污染与依赖链投毒
渲染进程中如果使用了存在原型污染漏洞的第三方库，攻击者可能通过篡改 JavaScript 原生对象的原型，注入恶意代码并最终获得执行权限。近年来，npm 供应链攻击事件频发，恶意依赖包也可能直接将攻击代码植入你的构建产物中。
24.2.2 真实案例警示
- 某知名聊天应用的 Electron 客户端曾因加载了未被完全信任的第三方网页，且窗口开启了 Node 集成，导致攻击者通过跨站脚本（XSS）注入 Node.js 代码，实现了对用户文件系统的完全控制。
- 多个开发工具类应用因
shell.openExternal暴露不当，攻击者通过构造带有命令注入参数的 URL，在用户点击链接时执行了系统命令。
这些案例的共同点是：权限配置疏忽 + 加载内容不可信 = RCE。修复往往只需要调整几行配置，但在发现之前可能已造成巨大损失。
24.2.3 必须遵守的规避策略
防范 RCE 并不需要复杂的算法或昂贵的工具，关键在于严格遵守 Electron 的安全最佳实践，从根源上消除攻击面。
1. 永远不要在主窗口加载远程内容
这是最根本的一条规则。你的主应用界面应当完全从本地文件加载（win.loadFile('index.html')），任何来自网络的内容都应该被视为不可信。如果业务上必须展示远端页面（如第三方认证、帮助文档），使用 <webview> 标签或 BrowserView，并且严格隔离：关闭 Node 集成、启用上下文隔离、配置沙箱、限制导航。
2. 始终启用上下文隔离并禁用 Node 集成
自 Electron 12 起，contextIsolation: true 是默认值，Node 集成则默认为 false。这是官方强烈推荐的安全基线。如果你还在维护老项目，务必检查并升级这些配置：
const win = new BrowserWindow({
webPreferences: {
nodeIntegration: false,
contextIsolation: true,
sandbox: true, // 进一步开启沙箱（性能敏感场景可酌情）
}
});如果你需要在渲染进程中使用 Node 或 Electron 的能力，只能通过 preload 脚本和 contextBridge 精确暴露有限的、安全的函数。永远不要为了省事而直接禁用上下文隔离。
3. 最小化暴露给渲染进程的 API
preload 脚本应当像一扇带锁的窄门，只让必需的数据和方法通过。设计时要反复问自己：这个方法暴露出去后，即使被恶意调用，最坏能造成什么后果？遵循以下原则：
- 永远不要直接暴露
ipcRenderer.send或ipcRenderer.invoke的原始能力，而是封装成语义明确的方法（例如selectFile()、saveContent(text)）。 - 对于
shell.openExternal(url)，永远不要绕过 URL 验证。必须在主进程中对所有传入的 URL 做白名单检查，只允许https://和mailto:等安全协议，拒绝file://、javascript:或带有特殊字符的字符串。 - 不要暴露
require或任何能够动态加载模块的途径。
4. 正确处理外部链接
用户点击应用内的超链接时，大概率会唤起外部浏览器。但如果这个链接来自不可信来源（例如聊天消息、网页内容），直接用 shell.openExternal 可能会触发命令注入。正确的做法是先通过 URL 构造函数解析链接，验证协议，再进行路由：
// 主进程安全处理外部链接
ipcMain.handle('open-external', (event, url) => {
try {
const parsed = new URL(url);
if (parsed.protocol === 'https:' || parsed.protocol === 'http:') {
shell.openExternal(url);
} else {
console.warn('Blocked unsafe URL protocol:', url);
}
} catch {
// 不是合法 URL，拒绝
}
});5. 加固 webview 使用
如果业务必须使用 webview，应将其作为一个完全敌对的运行环境来配置：
<webview src="https://example.com"
nodeintegration="false"
allowpopups="false"
webpreferences="contextIsolation=yes, sandbox=yes"
preload="./webview-preload.js"
></webview>并且 webview-preload.js 同样要遵循最小暴露原则。
6. 定期审计第三方依赖
使用 npm audit、Snyk 等工具定期扫描依赖树中的已知漏洞。对原型污染敏感的库更要谨慎引入。在构建环节可以配置 Electron 的原型污染保护（例如使用 --disable-proto 启动参数，或主进程中冻结内置对象原型）。
7. 启用安全警告
在开发阶段，Electron 会在控制台输出安全相关警告（如未开启上下文隔离、启用了远程内容等）。不要忽视它们。将这些警告视为必须修复的 Bug，而不是“建议”。
24.2.4 总结：把信任边界刻在架构里
RCE 防御不是打补丁式的应急措施，而是一种从架构层面确立的原则：永远不要信任渲染进程中的任何内容。所有来自用户界面、第三方页面、甚至你自己前端代码的请求，都必须经过主进程的严格验证。把权限牢牢锁在主进程中，给渲染进程只留一条经过仔细审查的 IPC 通道，这才能让攻击者无空可钻。每当你准备在 preload 里多加一个 expose 时，不妨多想一想——这扇门打开之后，还会不会记得关上。