3、Node.js集成安全：nodeIntegration开关详解、远程模块加载风险、require()函数安全限制

好，咱们今天聊一个Electron安全里最核心的话题——Node.js集成。

说实话，我见过太多开发者在这个地方翻车了。我自己早期做的一个项目，就因为没管好nodeIntegration，差点让整个应用变成“裸奔”。嗯，咱们一步步来拆解。

3.1 nodeIntegration开关：一个决定生死的配置

先问个问题：你的渲染进程能不能直接调用Node.js的API？

答案就在nodeIntegration这个开关上。它默认是false，但很多人为了图方便，直接设成true。

为什么这么说？你想想看，渲染进程跑的是用户能接触到的页面代码。如果这里能直接调用require('child_process')，那用户随便加载一个恶意脚本，就能执行系统命令。

我个人习惯是：永远保持nodeIntegration: false。除非你有100%的把握，并且做了额外的安全加固。

来看一个典型的错误配置：

// ❌ 危险配置
const mainWindow = new BrowserWindow({
  webPreferences: {
    nodeIntegration: true,
    contextIsolation: false
  }
});

这个配置，说白了就是把整个Node.js的威力暴露给了网页。我在项目中遇到过，有人用这个方式直接读取了服务器上的敏感文件。嗯，后果很严重。

正确的做法是这样的：

// ✅ 安全配置
const mainWindow = new BrowserWindow({
  webPreferences: {
    nodeIntegration: false,
    contextIsolation: true,
    preload: './preload.js'
  }
});

3.2 远程模块加载风险：别让第三方代码进你家

接下来聊远程模块加载。这个坑，我踩过。

Electron允许渲染进程加载远程URL的内容。比如你嵌入了一个第三方网站的页面。如果这个页面里包含了恶意脚本，而你又开了nodeIntegration，那后果不堪设想。

我曾经帮一个客户做安全审计，发现他们的应用直接加载了一个广告联盟的页面。那个页面里有一段JS，尝试通过require('fs')读取用户本地文件。还好他们当时没开nodeIntegration，不然数据就全漏了。

怎么防范？我建议这么做：

• 禁用远程脚本执行：设置webSecurity: true，开启CSP（内容安全策略）
• 限制加载来源：只允许加载你自己服务器上的资源
• 使用sandbox选项：把渲染进程关进沙箱里

看一个CSP配置的例子：

// 在main.js中设置
mainWindow.webContents.session.webRequest.onHeadersReceived((details, callback) => {
  callback({
    responseHeaders: {
      ...details.responseHeaders,
      'Content-Security-Policy': [
        "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'"
      ]
    }
  });
});

这个配置，说白了就是告诉浏览器：只加载我自己家的脚本和样式。外来的，一律拒绝。

3.3 require()函数安全限制：给Node.js加把锁

最后咱们聊聊require()。这个函数在Electron里是个双刃剑。

当nodeIntegration为true时，渲染进程可以直接require('electron')或者require('fs')。但即使你关了nodeIntegration，如果contextIsolation是false，攻击者还是有可能通过原型链污染等方式，间接调用到Node.js的API。

来看一个preload脚本的示例：

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

contextBridge.exposeInMainWorld('myAPI', {
  // 只暴露一个读文件的方法
  readFile: (path) => {
    // 这里可以做路径校验
    if (!path.startsWith('/safe/directory/')) {
      throw new Error('不允许访问该路径');
    }
    return ipcRenderer.invoke('read-file', path);
  },
  // 暴露一个写日志的方法
  log: (message) => {
    ipcRenderer.send('log-message', message);
  }
});

这样，渲染进程只能通过window.myAPI.readFile()来读文件，而且路径还被限制死了。攻击者就算拿到了这个API，也翻不出什么浪花。

我曾经见过一个项目，他们直接在preload里把整个fs模块暴露了出去：

// ❌ 危险做法
contextBridge.exposeInMainWorld('fs', require('fs'));

嗯，这跟没关nodeIntegration没啥区别。攻击者拿到window.fs，想删啥删啥。

3.4 总结一下关键点

咱们把今天的内容捋一捋：

配置项	推荐值	原因
nodeIntegration	false	防止渲染进程直接调用Node.js API
contextIsolation	true	隔离渲染进程和Electron的上下文
sandbox	true	把渲染进程关进沙箱，限制系统调用
preload	使用contextBridge	只暴露必要的API，做细粒度控制

记住一句话：最小权限原则。只给渲染进程它真正需要的能力，多一点都不给。

好了，这一章的内容就到这儿。下一章咱们聊聊contextIsolation的深层原理，以及怎么在隔离环境下安全地通信。到时候我会分享一个我踩过的坑——嗯，那个坑让我加班到凌晨三点。