What an Electron pentest covers
Electron apps ship to end users who control the physical machine. That changes the threat model significantly compared to a web app. An attacker who can run arbitrary code on the user's machine before the app launches, or who can intercept the app's network traffic, has multiple leverage points. Our pentest covers all of them.
1. nodeIntegration and contextIsolation configuration
The most dangerous Electron configuration is enabling nodeIntegration: true in the renderer process BrowserWindow. This allows any JavaScript running in the renderer (including injected scripts via XSS) to call Node.js APIs directly, giving it full access to the filesystem, network stack, and process execution on the user's machine.
Modern Electron apps disable nodeIntegration and use a preload script combined with contextBridge to expose a restricted API surface to the renderer. We audit the preload script and contextBridge surface in detail, because an overly broad contextBridge API is only marginally safer than nodeIntegration enabled:
// VULNERABLE contextBridge that exposes too much
contextBridge.exposeInMainWorld('electron', {
// Exposes shell.openExternal with no URL validation
openUrl: (url) => shell.openExternal(url),
// Exposes direct IPC send with no channel whitelist
send: (channel, data) => ipcRenderer.send(channel, data)
});If a renderer-side XSS vulnerability exists and openUrl accepts arbitrary strings, an attacker can pass a file:// or javascript: URI to escalate into main-process context. We also verify that all IPC channels used on the main process side validate the sender identity.
2. asar archive extraction and source analysis
Extracting an Electron app's source code is a single command:
npx asar extract app.asar ./extracted-sourceAfter extraction, we have the full JavaScript (or TypeScript-compiled) source of the application. We scan for hardcoded API keys, internal endpoint URLs, JWT signing secrets, database connection strings, and encryption keys. We have found production AWS credentials, Stripe secret keys, and internal REST API tokens inside asar archives of shipping production applications.
3. Auto-updater endpoint and signature validation
Electron apps that use electron-updater or electron-builder's built-in update mechanism fetch a manifest file from an update server. We test this update flow against three scenarios: HTTP downgrade (can we force the update check over unencrypted HTTP?), manifest tampering (can we inject a malicious version number pointing to our binary?), and signature bypass (does the app verify the code signature of a downloaded update before running it?)
4. IPC privilege escalation
The Electron IPC system (ipcMain/ipcRenderer) is the communication channel between the sandboxed renderer and the privileged main process. If the main process handles IPC messages without validating the message source or the message payload, a renderer-side XSS can send arbitrary IPC commands to trigger privileged operations: file reads, process spawning, or external program execution.
Hardcoded production database credentials in asar archive
During a pentest of a financial reporting desktop tool, we extracted the app.asar archive. Inside the database configuration module, we found a hardcoded PostgreSQL connection string with production credentials, including host, port, username, and password. The database was publicly accessible. We connected directly and read the complete transaction ledger. Fix priority: critical. Remediated by moving the connection string to a backend API that authenticated the desktop client with a rotating session token.
Shipping an Electron desktop application? Book a security assessment before your users receive it.
Book an Electron PentestFrequently asked questions
Is nodeIntegration the biggest Electron security risk?
nodeIntegration is the most well-known risk but not always the most critical in practice. In modern Electron apps with nodeIntegration disabled, the highest-risk findings tend to be contextBridge API surface abuse and insecure IPC channel handling that allows renderer-side code to trigger privileged main-process operations.
What is asar extraction and why does it matter?
Electron apps package their JavaScript source into an .asar archive file. Extracting this archive (with a single CLI command) gives an attacker full access to the application source code, any hardcoded secrets, API endpoints, and business logic. Code obfuscation is not a substitute for server-side authorization.
Can Electron auto-updater be exploited?
Yes. If the auto-updater fetches update manifests over HTTP instead of HTTPS, or if the update server does not validate code signatures on downloaded binaries, an attacker on the same network can push a malicious update to every connected desktop client.
Related reading
Blog: Tauri vs Electron security comparison · Tauri desktop app audits · Hardcoded API keys in apps
Services: Penetration testing · Secure architecture review