Why Electron apps need their own testing
In a browser, a cross-site scripting bug is contained by the sandbox. In Electron, if the app is misconfigured, the same bug can reach the file system, spawn processes, or read the user's secrets — because the page is running next to Node.js. Most real Electron findings are not exotic; they are a handful of insecure defaults left switched the wrong way.
The high-risk areas, in order
1. Renderer security flags
This is where most of the risk lives. For every BrowserWindow and webview check the webPreferences:
nodeIntegrationmust befalse— if it is on, injected JavaScript gets Node APIs (fs,child_process), and an XSS becomes remote code execution.contextIsolationmust betrue— keeps the preload and page contexts separate so the page cannot tamper with privileged objects.sandboxshould betrue— runs the renderer in an OS-level sandbox.- No
enableRemoteModule— the old remote module is a known foot-gun. - A strict Content-Security-Policy — the main defence against injected scripts.
2. The ASAR archive and hardcoded secrets
An app's code ships inside an app.asar file. This is not encryption — it is a plain archive. Run npx asar extract app.asar out/ and read the source. Grep it for API keys, tokens, signing secrets and backend URLs. Secrets baked into a desktop binary are effectively public.
3. The preload bridge and IPC
The preload script is the door between the untrusted page and the privileged main process. Review what it exposes through contextBridge: every function handed to the renderer is attack surface. Then look at the ipcMain handlers — do they validate arguments, or will they happily run a path or command the renderer sends? Unvalidated IPC is a common privilege-escalation path.
4. The renderer as a web app
Whatever loads in the window is still HTML and JavaScript, so test it like any web target: reflected and DOM XSS, injection into anything that builds a query or command, and especially any place the app loads remote content. Loading remote URLs into a privileged window is one of the most dangerous patterns in Electron.
5. Auto-update
Confirm updates are fetched over HTTPS and that the update is signature-checked before it is applied. An update channel without signature verification is a direct path to shipping attacker code to every user.
Detection is not proof
A linter can tell you nodeIntegration is on. It cannot tell you whether that actually leads to code execution in this app. The valuable step is driving the running app, landing a real payload, and watching it reach Node — turning a config warning into a proof of exploit you can act on.
Doing it automatically
Because Electron is Chromium under the hood, it can be driven through the same remote-debugging interface (CDP) used to automate a browser. That is exactly how Sintropyc's App Proof mode works: it launches the packaged app in a sandbox, drives it like a real user, and proves whether a weakness — an exposed IPC handler, an XSS that reaches Node, a leaked key in the bundle — is genuinely exploitable, then writes the fix and replays the exploit to confirm it is gone.
Frequently asked questions
How do I test an Electron app for security vulnerabilities?
Audit the renderer security flags (nodeIntegration off, contextIsolation on, sandbox on), extract the ASAR archive to inspect the source and hunt for hardcoded secrets, review the preload bridge and IPC handlers, test the renderer for XSS and injection like a normal web app, and verify auto-update uses HTTPS with signature checks.
Is the ASAR archive in an Electron app encrypted?
No. An ASAR file is a concatenation archive, not encryption. Anyone can run npx asar extract app.asar out and read the full JavaScript source, including any secrets left inside it.
Why is nodeIntegration dangerous?
With it enabled, any JavaScript in the renderer — including injected XSS — can call Node APIs like the file system and child_process, so a single XSS can escalate to command execution on the user's machine.