Privilege Escalation via ContextBridge Exposure in Electron

Question

Electron's security model relies on contextIsolation to separate the renderer process from the main process. To facilitate communication, the contextBridge module allows developers to expose a limited API from a preload script to the renderer's global window object.

A critical design concern arises when complex objects or entire Electron modules are passed through exposeInMainWorld. If a function exposes a privileged module or a mutable object that can be manipulated by the renderer, the security boundary between the unprivileged renderer and the privileged main process may be compromised.

Given these constraints, what are the specific risks of exposing functions that return internal Electron objects to the renderer? How can a developer ensure that the contextBridge does not inadvertently allow a renderer process to execute arbitrary main-process commands?

Tasadduq Burney · Answer

Risks of exposing internal Electron objects via contextBridge
When a function exposed through contextBridge.exposeInMainWorld returns an Electron module or a mutable object (e.g., require('electron'), BrowserWindow, webContents, session), the renderer gains direct access to privileged main‑process capabilities. This bypasses the isolation intended by contextIsolation and can lead to:

Arbitrary file system or shell access via shell.openExternal or child_process.
Manipulation of windows (win.close(), win.setBounds) or web contents.
Creation of new privileged objects if a constructor is exposed.
Prototype pollution or function hijacking when the returned object is not deeply frozen.

Confirmed facts from Electron security research

Exposing require('electron') gives the renderer the same API surface as the main process.
Returning mutable objects such as BrowserWindow allows calls like win.webContents.send or session.clearStorageData.
If the exposed value is a constructor, the renderer can instantiate new privileged instances.
Even thin wrappers can be abused when the underlying object is not frozen, enabling attackers to replace methods.

Steps to prevent renderer‑initiated main‑process commands

Never expose require('electron') or any main‑process module directly.
Expose only primitive values (string, number, boolean) or plain objects whose properties are also primitives.
If you must return an object, create a shallow copy and call Object.freeze on it and on any nested objects.
Validate every argument that crosses the bridge; reject or sanitize unexpected types.
Limit the exposed API to specific, whitelisted functions that perform a single, well‑defined task.
After building the preload script, inspect the exposed properties in DevTools with Object.getOwnPropertyDescriptors to confirm they are non‑writable, non‑configurable, and lack dangerous methods.
Run a test renderer script that attempts to call known privileged APIs (e.g., window.electron.shell.openExternal) and verify that the calls throw or are blocked.
Package the app with the --enable-sandbox flag and observe that no renderer‑initiated main‑process action succeeds.

Privilege Escalation via ContextBridge Exposure in Electron

1 answer

Risks of exposing internal Electron objects via contextBridge

Confirmed facts from Electron security research

Steps to prevent renderer‑initiated main‑process commands

Your perspective belongs here.

0 question comments