auditing-electron-ipc-trust

name	auditing-electron-ipc-trust
description	Audit an Electron desktop app for untrusted renderer content that reaches a Node or operating-system capability, after the webPreferences and the preload bridge surface are resolved. Covers nodeIntegration enabled with contextIsolation off, a preload that exposes raw ipcRenderer or a generic invoke passthrough, an ipcMain handler that trusts renderer input as a path, command, or URL, remote or attacker-influenced content loaded through loadURL with navigation unlocked, shell.openExternal called on a renderer-controlled string, and a custom protocol or deeplink routed into a privileged action without validation. Use when reviewing webPreferences, the preload and contextBridge surface, IPC handlers, and remote-content loading, not renderer-side markup injection the client-side DOM skill owns. Untrusted content in a renderer is the source, a Node or operating-system capability is the sink, and input crossing the bridge without validation while isolation is off is the bug.
license	MIT

Auditing Electron IPC trust: when renderer content reaches a native capability

An Electron app is dangerous where content in a renderer, whether remote, injected through a cross-site-scripting, or arriving over a custom protocol, reaches a Node or operating-system capability. The marquee chain is a renderer bug escalating to code execution because the renderer can require Node directly, or because the preload bridge hands untrusted input to a native call. You audit it by resolving, per native sink, whether context isolation and the sandbox stand between the renderer and Node and whether the preload and IPC surface validate what they pass. The single most important false-positive killer is that context isolation and the sandbox being on make an otherwise alarming exposed symbol harmless, so resolve those two settings before judging any bridge. Renderer-side markup injection itself belongs to the client-side DOM skill; this skill owns the bridge and the IPC substrate.

When to use

• You are reviewing an Electron app's window configuration, its preload scripts, and its IPC handlers.
• You see webPreferences, a contextBridge exposure, an ipcMain handler, or a loadURL or openExternal call.
• You want to know whether untrusted renderer content can reach a Node or operating-system capability.

Scope check

Audit only apps you own or are authorized to assess, and drive a renderer-to-main path only against a build in scope, an IPC handler that reaches a shell or the filesystem acts on your host. Adjudicate on the window configuration and the handlers. If you can't name the authorization, stop.

The loop

1. Resolve context isolation and the sandbox first. Read the webPreferences for each window: is nodeIntegration off, is contextIsolation on, is the sandbox on. These settings decide whether the renderer can reach Node at all, so an exposed require or a Node symbol is only exploitable when they are off. Settle them before judging any exposed surface, because they are the killer for most leads.

2. Check node integration and isolation. Look for nodeIntegration enabled with contextIsolation off, which lets any renderer, including one hosting an attacker's script, require a Node module such as the child-process module and execute a command directly.

3. Check the preload bridge surface. Look for a preload that exposes the raw ipcRenderer object, or a generic invoke-any-channel passthrough, or the filesystem or child-process modules over the contextBridge. A bridge that hands the renderer an open channel to every IPC handler, rather than named argument-typed functions, gives the renderer the whole main-process surface.

4. Check the IPC handlers. Look for an ipcMain handler that trusts renderer-supplied input as a filesystem path, a command, or a URL (path traversal, argument injection, server-side request forgery) without validating it against an allowlist or a normalized base.

5. Check remote content, navigation, and protocol handlers. Look for loadURL or loadFile pointed at remote or attacker-influenced content, navigation left unlocked (no will-navigate or window-open guard), shell.openExternal called on a renderer-controlled string (a file or protocol URL reaching a local handler), and a custom protocol or deeplink routed into a privileged action without parsing and validating the URL.

6. Confirm and record. Confirm by showing renderer-reachable content drives a Node or operating-system sink, because isolation or the sandbox is off, or because the preload or IPC surface passes untrusted input to a native capability. Kill the lead if contextIsolation and the sandbox are on so an exposed require or Node symbol is unreachable from the renderer, if the preload exposes only named typed functions over the contextBridge with no raw ipcRenderer and no filesystem or child-process module, if the IPC handler validates or normalizes the path or allowlists the channel and action, if the renderer only ever loads bundled local content and navigation is locked, if the openExternal argument is a constant or scheme-allowlisted to a safe scheme, or if the app runs a current Electron with the sandbox on by default and no legacy remote module. Record the renderer source, the native sink, and the settings that gate the path.

Where IPC trust leaks

• Isolation and the sandbox are the killer, so resolve them first. With contextIsolation and the sandbox on, an exposed require or Node symbol is harmless; with them off, a renderer bug reaches Node.
• A raw ipcRenderer bridge exposes every handler. Handing the renderer the raw object or a generic invoke passthrough gives it the whole IPC surface; named typed functions expose only what you intend.
• An IPC handler that trusts a renderer path is a native sink. Renderer-supplied paths, commands, and URLs must be validated in the main process; the renderer is the untrusted side of the bridge.
• Remote content in a renderer is the on-ramp. loadURL of remote content, or unlocked navigation, puts attacker-influenced script one bug away from the bridge; bundled local content with locked navigation does not.
• openExternal and custom protocols route to the OS. A renderer-controlled string handed to openExternal or a deeplink handler reaches a local protocol handler; the argument has to be validated or scheme-allowlisted.

Worked example (a confirm and a kill)

Confirm. A window is created with nodeIntegration on and contextIsolation off, and it loads a remote page for a live feature. A cross-site-scripting in that page runs require('child_process').exec with an attacker command. Confirmed renderer-to-Node code execution through a non-isolated window loading remote content, critical, remediation = enable contextIsolation and the sandbox, disable nodeIntegration, expose only named typed functions over a preload bridge, and stop loading remote content in a privileged window.

Kill. Another window has contextIsolation and the sandbox on, nodeIntegration off, and a preload that exposes a single readConfig() function returning a fixed file's contents; no raw ipcRenderer, no child-process or filesystem module crosses the bridge, and it loads only bundled local content with navigation locked. A renderer bug reaches no Node capability. Killed, kill_reason = "context isolation and the sandbox are on, the preload exposes only a typed read function, and no untrusted input reaches a native sink."

Rationalizations to reject

• "We expose require, but it is behind the bridge." -> Are contextIsolation and the sandbox on? With them on, the renderer cannot reach that require; with them off, the bridge is not a barrier.
• "The preload just forwards IPC." -> Forwarding raw ipcRenderer or a generic invoke exposes every handler; expose named typed functions, not an open channel.
• "The handler takes a path from the renderer." -> Then validate it in the main process; the renderer is untrusted, and an unvalidated path is traversal or argument injection.
• "It only opens a link." -> With openExternal on a renderer-controlled string, a file or protocol URL reaches a local handler; constant or scheme-allowlist the argument.
• "It is our own deeplink." -> Is the URL parsed and validated before it drives an action? An unvalidated custom-protocol route is the desktop analogue of an open redirect into a privileged call.

Executing this in practice

You need each window's webPreferences (nodeIntegration, contextIsolation, sandbox), the preload scripts and exactly what they expose over the contextBridge, the ipcMain handlers and what they do with renderer input, the loadURL and loadFile targets and the navigation guards, and the openExternal and custom-protocol handlers. For each native sink, decide whether isolation and the sandbox gate the renderer and whether the bridge validates what it passes. Reading webPreferences tells you whether the barrier is up; reading the preload and handlers tells you what crosses it.

Related

• auditing-browser-extension-trust - the browser-extension sibling with the same untrusted-content-to- privileged-capability shape, across a message boundary rather than the Electron preload bridge.
• auditing-editor-extension-workspace-trust - the editor-extension sibling, where the untrusted source is a cloned workspace rather than renderer content.
• auditing-mobile-deeplink-trust - the mobile analogue of the custom-protocol and deeplink bug shape; the parsing logic rhymes, the Electron IPC and native substrate is owned here.
• FINDING-SCHEMA.md - source = untrusted content in a renderer, sink = a Node or operating-system capability, evidence = the isolation and sandbox settings, the bridge surface, and the input crossing to the native call.