25.1 权限最小化原则：能力按需暴露、默认关闭

在 Electron 应用的安全性考量中，“权限最小化”是一条需要贯穿开发始终的基本准则。它的核心思想是：每个模块、每个进程、每个窗口，都只应拥有完成其功能所必需的最小权限，任何多余的权限默认一律关闭。

Electron 为开发者提供了强大的原生能力——文件系统访问、系统命令执行、进程管理、网络请求——但这些能力一旦被攻击者通过 XSS 或依赖链污染劫持，就可能直接威胁到用户的计算机安全。权限最小化原则，就是要在开发期就通过一系列配置和代码约定，主动收缩这块攻击面。

25.1.1 渲染进程：默认无 Node 权限

过去，很多入门教程习惯直接在渲染进程中开启 nodeIntegration: true，让前端代码可以直接使用 require 加载原生模块。这种做法极大地便利了开发，但也将所有的 Node.js 和 Electron 原生权限完全暴露在了网页环境中。一旦页面中存在 XSS 漏洞，攻击者就能通过注入的脚本读写整个文件系统、执行任意系统命令。

现代 Electron（官方推荐从 Electron 12 以上版本）的默认配置已经将安全级别大幅提高：

nodeIntegration 默认为 false。
contextIsolation 默认为 true。
sandbox 默认开启（部分版本逐步默认开启）。

权限最小化的第一步，就是保持这些默认值，绝不在生产环境开启全局的 Node 集成。

这意味着渲染进程中的 JavaScript 代码只能像普通浏览器页面一样使用 DOM API 和 Web API（除非通过预加载脚本精确暴露某些功能）。如果你习惯性地在 main.js 中写下这样的旧式窗口配置：

// ⚠️ 不安全的写法：直接暴露 Node 和 Electron API
const win = new BrowserWindow({
  webPreferences: {
    nodeIntegration: true,
    contextIsolation: false,
  },
});

请立即改为：

// ✅ 安全的默认配置
const win = new BrowserWindow({
  webPreferences: {
    nodeIntegration: false,       // 默认已是 false，显式声明更清晰
    contextIsolation: true,       // 开启上下文隔离
    sandbox: true,                // 开启沙箱（如果不需要特殊权限）
    preload: path.join(__dirname, 'preload.js'),
  },
});

25.1.2 通过预加载脚本精确暴露 API

既然渲染进程已经关闭了直接访问 Node.js 的能力，那么应用如何在界面上实现“选择文件”、“保存数据”、“调用系统通知”等功能？答案就是 预加载脚本（preload script）。它是一个运行在渲染进程中的特殊脚本，拥有访问部分 Node.js 和 Electron API 的权限，但同时受到上下文隔离的保护。

contextIsolation 开启后，预加载脚本和网页内容运行在不同的 JavaScript 环境中。网页无法直接访问预加载中的变量或函数，只能通过 contextBridge.exposeInMainWorld 暴露的 API 对象进行通信。这就实现了“按需暴露”：你需要哪些主进程能力，就谨慎地、一个一个地添加到桥接对象中。

示例：只暴露一个安全的“打开文件”功能

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

contextBridge.exposeInMainWorld('fileAPI', {
  // 只提供打开文件的接口，其他能力一概不暴露
  openFile: () => ipcRenderer.invoke('dialog:openFile'),
});

在渲染进程中，你的业务代码只能调用 window.fileAPI.openFile()，而完全接触不到 fs、child_process 或 Electron 的其他原生模块。

主进程收到 IPC 请求后，再以自己的权限执行系统操作：

// main.js
const { ipcMain, dialog } = require('electron');

ipcMain.handle('dialog:openFile', async () => {
  const { canceled, filePaths } = await dialog.showOpenDialog({
    properties: ['openFile'],
  });
  if (!canceled) {
    return filePaths[0];
  }
  return null;
});

这种模式将危险的系统调用从渲染进程剥离，主进程成为唯一的权限执行方。即便渲染进程被攻破，攻击者也仅限于调用你预先定义好的那三个函数，无法直接读取任意文件或执行命令。

25.1.3 只允许必要的外部资源

另一个常见的权限过度开放场景是加载外部内容。Electron 窗口可以加载任意的远程 URL，但这同样可能引入不可控的第三方脚本。除非你的应用本身就是加载一个受信任的 Web 应用（如将公司的 SaaS 产品打包成桌面壳），否则应尽量只加载本地 HTML 文件：

win.loadFile('index.html');

如果必须加载远程内容，务必配合 webContents.session.webRequest 进行请求过滤，或者设置 Content Security Policy（CSP）来限制脚本、样式、图像的来源。

此外，webPreferences 中还有一些默认开放但可能引发安全问题的选项，建议主动关闭：

allowRunningInsecureContent: false（禁止加载混合内容）
experimentalFeatures: false（除非明确需要）
enableRemoteModule: false（remote 模块已不推荐，应禁用）

25.1.4 主进程自身也保持克制

权限最小化不光是针对渲染进程。主进程同样应该避免在全局注入大而全的函数库，或者将整个 ipcMain 的 handle 权限开放给未经验证的消息。例如，永远不要在 ipcMain.on 的回调中接收渲染进程发来的任意文件路径，然后直接传给 shell.openPath 或 fs.readFile，至少要经过严格的路径校验，确保文件位于应用的沙箱目录或用户明确选择的范围内。

另一个常见风险是 shell.openExternal。它可以打开外部链接或文件，但如果链接由渲染进程的不可信内容构造，就可能被利用来执行本地程序。应对传入的 URL 进行协议校验（只允许 https:、mailto: 等白名单协议）。

25.1.5 权限最小化的实战清单

总结成可操作的检查项，你可以逐条核对自己的 Electron 应用：

渲染进程全局安全配置

nodeIntegration: false
contextIsolation: true
sandbox: true（如无特殊需求）
enableRemoteModule: false

预加载脚本

只通过 contextBridge 暴露具体的方法，不暴露整个 ipcRenderer 或 process 对象
避免在预加载中直接引入 fs、child_process 等模块并暴露给网页

IPC 通道

主进程只处理白名单的 IPC 通道，对传入参数做严格校验和净化
避免“万能通道”（例如 ipcMain.handle('execute', (_, cmd) => exec(cmd))）

外部内容

尽量使用本地 HTML 文件（loadFile）
加载远程 URL 时设置严格的 CSP 和请求拦截

主进程 API 调用

使用 shell.openExternal 前校验 URL 协议
文件操作始终以用户交互为基础（如通过 dialog 选择的路径）

权限最小化不是一套死板的教条，而是一种持续的安全意识。它要求你在每次打算“为了省事开一个大权限”的时候，多花几分钟思考：“这个功能真的需要那么高的权限吗？有没有更小的接口可以替代？” 正是这每一次的克制，构筑起了一道让攻击者难以逾越的坚实屏障。