17. 加载远程内容与安全

本节目标

掌握用 loadURL 加载远程地址的方式
了解 webview 标签的用途与官方态度
认识 XSS 升级为远程代码执行的风险
落实本地优先、隔离不可信内容、开启沙箱的防护

Electron 能显示本地文件，也能直接打开一个远程网址。但这两者风险完全不同。加载 https://example.com 这样的远程内容，等于把别人的代码请进了你的桌面程序里运行。

本章先说怎么加载远程地址，再讲 <webview> 标签的用途和官方态度，然后重点剖析 XSS 与远程代码执行（RCE）的风险链条，最后给出一套可落地的防护建议。

17-1 用 loadURL 打开远程地址

最常见的远程加载方式是 BrowserWindow 的 loadURL。它接收一个完整 URL，可以是 https:// 站点，也可以是你自己的接口页面。

// main.js（主进程）
const { app, BrowserWindow } = require('electron/main')

app.whenReady().then(() => {
  const win = new BrowserWindow({
    webPreferences: {
      // 远程内容必须保持这些默认安全值
      contextIsolation: true,
      nodeIntegration: false
    }
  })
  // 加载一个远程地址
  win.loadURL('https://example.com')
})

打开远程地址本身没有错，问题在于：该页面里的任何 JavaScript 都会在你的应用进程里执行。如果这个页面被篡改、或它本身不可信，攻击者就能借机动手脚。所以远程内容应被视为「不可信」，并施加所有安全限制。

很多知名 Electron 应用（如 VS Code、Slack）只显示本地内容，或只显示禁用了 Node 集成的可信远程内容。这并非偶然，而是行业共识：远程代码一旦进入桌面进程，危害等级就从「网页 bug」升级成「本机安全问题」。

17-2 用 webview 标签嵌入网页

<webview> 标签能在你的页面里嵌入一块「访客」内容，比如显示一个外部站点。它和普通 <iframe> 的关键区别是：<webview> 跑在独立进程里，和你主页面权限隔离。

<!-- index.html（渲染进程） -->
<webview
  id="guest"
  src="https://example.com/"
  style="width: 640px; height: 480px">
</webview>

但要注意，官方文档明确提醒：<webview> 基于 Chromium 的旧版 webview 实现，架构正在剧烈变动，稳定性存疑。Electron 当前建议尽量避免使用它，优先考虑 <iframe>、WebContentsView，或者直接避免嵌入外部内容。

如果你确实要用 <webview>，务必保持默认安全值：不要加 nodeintegration 属性，不要用 disablewebsecurity，不要开启 allowpopups。下面是正确的最小化写法：

<!-- 正确：不暴露 Node、不关安全 -->
<webview src="https://example.com/"></webview>

<!-- 不要这样做：给访客内容开放 Node 权限 -->
<webview src="https://example.com/" nodeintegration></webview>

17-3 XSS 与远程代码执行风险

在普通浏览器里，跨站脚本（XSS）的危害大多被沙箱限制在当前网页内。但在 Electron 里，如果渲染进程同时开着 Node 集成，一次 XSS 就可能升级成远程代码执行（RCE），攻击者的脚本能直接读写文件、执行系统命令。

这就是那条最硬的安全红线：绝不为远程内容开启 nodeIntegration。在 v43.2.0 里它默认就是 false，你只需要「别去打开它」。

// ❌ 不要这样做：把 Node 权限交给远程页面（仅作反例，切勿复制）
// const win = new BrowserWindow({
//   webPreferences: {
//     nodeIntegration: true,      // 危险：页面脚本能读写文件、执行命令
//     contextIsolation: false     // 危险：preload 与页面共用同一个 window
//   }
// })
// win.loadURL('https://example.com')

正确的写法是保持默认值，什么都不改：

// ✅ 正确：远程内容一律使用安全默认值
const win = new BrowserWindow({
  webPreferences: {
    contextIsolation: true,
    nodeIntegration: false,
    sandbox: true
  }
})
win.loadURL('https://example.com')

即便关掉了 Node 集成，XSS 仍能盗窃渲染进程里的敏感数据、伪造界面、诱导用户操作。所以远程内容必须叠加多层防护：上下文隔离、进程沙箱、内容安全策略（CSP）。

17-4 建议一：本地优先

最稳妥的策略是「本地优先」。把应用界面、脚本、样式都作为本地文件打包进程序，用 loadFile 加载。本地文件不会被中间人篡改，也不依赖网络，安全风险最低。

// 推荐：加载随应用打包的本地页面
const path = require('node:path')
win.loadFile(path.join(__dirname, 'index.html'))

只有必须展示外部信息（如官方文档、内嵌网页）时，才考虑远程加载，并且对那块内容单独设防。这样绝大多数界面都处在可信边界内。

17-5 建议二：隔离不可信内容

如果一定要显示不可信的远程内容，把它放进独立的、权限最小的环境。要么是单独的 BrowserWindow，要么是 <webview> / WebContentsView，并且绝不给它 Node 集成。

还可以在主进程拦截它的创建与跳转，强制校验来源。例如下面这段代码会在 <webview> 挂载前检查地址，并清掉可能不安全的选项：

// main.js（主进程）
const { app } = require('electron/main')

app.on('web-contents-created', (event, contents) => {
  contents.on('will-attach-webview', (e, webPreferences, params) => {
    // 只允许指定来源
    if (!params.src.startsWith('https://example.com/')) {
      e.preventDefault()
      return
    }
    // 强制最小权限
    webPreferences.nodeIntegration = false
    delete webPreferences.preload
  })
})

17-6 建议三：开启沙箱与 CSP

沙箱（sandbox）是 Chromium 用操作系统机制限制渲染进程权限的能力。在 v43.2.0 里，渲染进程默认已启用沙箱，你应保持它开启，不要主动设 sandbox: false。

内容安全策略（CSP）是另一道防线。它告诉页面只允许从哪些来源加载脚本，从而挡住注入的恶意脚本。对本地页面可以用 <meta> 标签设置：

<!-- index.html（渲染进程） -->
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self'">

对远程内容，更推荐由服务端通过 HTTP 响应头下发 CSP。还可以用 session 的 webRequest.onHeadersReceived 在主进程强制注入，确保即便远程服务器没带 CSP，你的应用也会补上。

17-7 限制导航与新窗口

除了上节手段，还应从源头减少攻击面。当你确定应用不需要跳转到外部站点时，可在主进程拦截 will-navigate，只允许白名单内的地址，其余一律 preventDefault。

// main.js（主进程）
const { app } = require('electron/main')
const { URL } = require('node:url')

app.on('web-contents-created', (event, contents) => {
  contents.on('will-navigate', (e, url) => {
    if (new URL(url).origin !== 'https://example.com') {
      e.preventDefault()
    }
  })
})

新窗口的创建同样建议拦截。webContents.setWindowOpenHandler 里对不确定的地址返回 { action: 'deny' }，必要时才用 shell.openExternal 交给系统浏览器打开，且传入的 URL 必须可信。

17-8 用自定义协议服务本地内容

安全清单还建议：尽量用自定义协议（如 app://）替代 file:// 来加载本地页面。file:// 在 Electron 里比浏览器拥有更多权限，一旦遇到 XSS，攻击者能读取本机任意文件。自定义协议则可以把可访问范围限制在你指定的资源内。

// main.js（主进程）
const { protocol } = require('electron/main')
const path = require('node:path')

const appRoot = path.resolve(__dirname)

protocol.handle('app', (request) => {
  // 取 URL 中的路径部分（URL 解析器会自动归一化 ../ 之类的跳转）
  const urlPath = new URL(request.url).pathname
  // 拼成绝对路径，并确认它仍然落在应用目录内
  const filePath = path.resolve(appRoot, '.' + urlPath)
  if (!filePath.startsWith(appRoot)) {
    return new Response('Not Found', { status: 404 })
  }
  return fetch('file://' + filePath)
})

此外，preload 里不要直接把 ipcRenderer.on 这类原始 API 整体暴露给不可信页面。应只暴露封装好的、带参数校验的接口，避免远程内容拿到整个 IPC 事件系统。

17-9 小结

加载远程内容是 Electron 的双刃剑。它能让桌面应用直接展示网页，但也把不可信代码请进了本机环境。核心原则是：本地优先，远程内容一律视为不可信。

具体落地三件事：第一，远程内容绝不开 nodeIntegration、保持 contextIsolation: true；第二，把不可信内容隔离进独立进程并校验来源；第三，保持沙箱开启、补上 CSP。做到这几点，XSS 就很难升级成真正的系统级攻击。