预加载脚本在 Electron 的安全模型中扮演着“守门人”的角色 —— 它是渲染进程与主进程之间唯一的桥梁，也正因如此，它成了攻击者最想攻破的目标。一旦预加载脚本暴露出过多的能力，任何一个渲染进程中的 XSS 漏洞都有可能被放大为系统级的入侵。因此，编写预加载脚本时，必须坚定不移地遵循两条原则：能力最小化暴露和接口白名单机制。
23.3.1 能力最小化暴露：渲染进程不该拿到“万能钥匙”
“最小化暴露”意味着：只给渲染进程它完成工作所必需的方法，绝不多给任何多余的能力。
初学者很容易写出这样的预加载脚本：
// ❌ 危险写法：直接暴露整个 ipcRenderer
const { contextBridge, ipcRenderer } = require('electron');
contextBridge.exposeInMainWorld('electronAPI', {
ipcRenderer: ipcRenderer
});这种写法相当于把 ipcRenderer.send、ipcRenderer.invoke、ipcRenderer.on 等全部方法原封不动地交给了渲染进程。攻击者只要在网页中注入一行代码，就可以向主进程发送任意消息：
window.electronAPI.ipcRenderer.send('delete-all-files');正确的方式是：将每一个可能被渲染进程使用的具体功能封装为一个命名明确的方法。比如，你的应用需要在渲染进程中让用户选择并读取一个文件，那么预加载脚本中只暴露一个 openFile 函数：
// ✅ 安全写法：按功能暴露最小接口
const { contextBridge, ipcRenderer } = require('electron');
contextBridge.exposeInMainWorld('app', {
openFile: () => ipcRenderer.invoke('dialog:openFile'),
saveFile: (content) => ipcRenderer.invoke('dialog:saveFile', content),
getAppVersion: () => ipcRenderer.invoke('app:getVersion')
});在渲染进程中，代码就只能调用这三个精确的函数：
document.getElementById('btn').addEventListener('click', async () => {
const filePath = await window.app.openFile();
// 无法调用任何其他 ipc 方法
});这种封装带来的好处非常直接：即便渲染进程被完全控制，攻击者能调用的也只有你显式暴露的那几个函数，而无法直接操作主进程、无法注册任意的 IPC 监听器、也无法向主进程发送你未预料到的消息。
23.3.2 接口白名单：让每一个通道都“有据可查”
有些场景下，应用主进程会对外提供几十甚至上百个 IPC 通道，每一个对应不同的业务操作。如果只是在预加载脚本里按功能逐个暴露，维护成本会比较高。一种更系统化的做法是：在预加载脚本中建立一个通道白名单，只允许通过白名单内的通道进行通信。
具体实现上，你可以定义一个数组，存放所有允许渲染进程调用的通道名，然后在暴露的 send 和 invoke 方法中进行校验：
// preload.js
const { contextBridge, ipcRenderer } = require('electron');
// 允许的 IPC 通道白名单
const INVOKE_CHANNELS = [
'dialog:openFile',
'dialog:saveFile',
'app:getVersion',
'user:getProfile'
];
const SEND_CHANNELS = [
'window:minimize',
'window:maximize',
'window:close'
];
contextBridge.exposeInMainWorld('api', {
invoke: (channel, ...args) => {
if (INVOKE_CHANNELS.includes(channel)) {
return ipcRenderer.invoke(channel, ...args);
}
throw new Error(`不允许调用的 invoke 通道: ${channel}`);
},
send: (channel, ...args) => {
if (SEND_CHANNELS.includes(channel)) {
ipcRenderer.send(channel, ...args);
return;
}
throw new Error(`不允许调用的 send 通道: ${channel}`);
},
on: (channel, callback) => {
// 对于监听事件，同样要限制通道
const allowedChannels = ['app:update-available', 'user:logged-in'];
if (allowedChannels.includes(channel)) {
ipcRenderer.on(channel, (event, ...args) => callback(...args));
}
}
});这样做既保留了按通道通信的灵活性，又把攻击面收缩到了一个可审计的列表里。任何新增的通道都必须在预加载脚本的白名单中显式注册才能被渲染进程使用，杜绝了“无中生有”的恶意调用。
注意：白名单校验要尽可能在预加载脚本中进行，因为预加载脚本可以访问 Node.js 环境，渲染进程无法篡改。绝对不要把白名单逻辑放到渲染进程中执行 —— 那样它自身就可以被恶意代码绕过。
23.3.3 一个完整的实战示例
假设我们开发一个 Markdown 编辑器，需要提供新建文件、打开文件、保存文件三个功能，同时允许窗口最小化。预加载脚本可以这样组织：
preload.js
const { contextBridge, ipcRenderer } = require('electron');
// 严格定义允许的接口
const allowedApi = {
// 文件操作（invoke 异步返回结果）
newFile: () => ipcRenderer.invoke('file:new'),
openFile: () => ipcRenderer.invoke('file:open'),
saveFile: (content) => ipcRenderer.invoke('file:save', content),
// 窗口控制（fire-and-forget 的 send）
minimizeWindow: () => ipcRenderer.send('window:minimize'),
// 监听主进程状态（on 回调）
onFileChanged: (callback) => {
ipcRenderer.on('file:changed', (event, data) => callback(data));
},
removeFileChangedListener: () => {
ipcRenderer.removeAllListeners('file:changed');
}
};
contextBridge.exposeInMainWorld('editor', allowedApi);渲染进程
// 安全地使用编辑器 API
document.getElementById('open-btn').addEventListener('click', async () => {
try {
const filePath = await window.editor.openFile();
console.log('打开了文件:', filePath);
} catch (e) {
console.error('操作失败:', e);
}
});
window.editor.onFileChanged((newContent) => {
// 文件内容被外部修改后自动更新编辑器
updateTextArea(newContent);
});在这个设计中，渲染进程完全不知道 ipcRenderer 的存在，也不知道有哪些通道。它只知道 window.editor 下挂载的几个具体方法。任何一个前端 XSS 都无法获取到未暴露的通道，也无法伪造未列入白名单的请求。
23.3.4 常见误区和最佳实践
- 绝不暴露
ipcRenderer本身
哪怕你觉得已经限制了 send 和 invoke 的通道，但如果把原始的 ipcRenderer 对象暴露出去，攻击者仍然可以通过 .send('任意通道') 绕过你的包装函数。
- 避免在预加载脚本中暴露 Node.js 模块
例如 require('fs') 或 require('child_process') 绝不能直接交到渲染进程手中。即使你需要文件操作，也应该交给主进程去完成，预加载脚本只充当桥梁。
- 使用
contextIsolation: true
这是 Electron 12 之后的默认值，确保预加载脚本运行在独立的 JavaScript 上下文中，渲染进程无法通过原型污染等方式篡改暴露出的对象。永远不要为了图省事将其设为 false。
- 对来自渲染进程的参数进行严格校验
即使是白名单内的通道，预加载脚本也应该对传入的参数类型和内容做验证（例如路径不能包含 .. 穿越），防止参数注入攻击。可以在预加载脚本中引入简单的校验逻辑，比如使用 typeof 检查和正则过滤。
- 定期审计预加载脚本
随着项目迭代，接口可能会越来越多。建议在主进程定义统一的通道常量文件（例如 channels.js），预加载脚本直接引用该常量数组作为白名单，这样任何新增通道都必须先注册，便于代码审查和自动化安全扫描。
当你的 Electron 应用面向公网内容或允许加载第三方网页时，预加载脚本的安全实践就不再是可选的了，而是防止灾难性安全事件的刚性要求。能力最小化和白名单机制用简单的编码规范，为你的应用构筑起了一道坚实的纵深防线。