How to test an Electron app for vulnerabilities
An Electron review needs to examine the boundary between web content and desktop privileges. Begin with configuration, then test which capabilities an untrusted renderer can actually reach.
Check renderer and navigation boundaries
Keep Electron current. Disable Node integration for remote content, enable context isolation and renderer sandboxing, and use a restrictive Content Security Policy. Review permission requests, navigation and new-window handling. Do not pass untrusted destinations directly to shell.openExternal. These are core recommendations in Electron’s official security guide.
Test the packaged application, not only the development window. Record which window opens the content and which configuration applies to it. A secure main window does not establish how a separate preview or login window behaves.
Treat the preload bridge as an API
Expose narrow operations through the bridge, validate the sender of IPC messages and validate their arguments. Context isolation does not make a broadly exposed privileged function safe. The Electron bridge guidance explains why unrestricted APIs should not be available to untrusted content.
For a hypothetical document-export feature, define the permitted operation first: export the current document into a user-selected location. Test an invalid document identifier, an unexpected argument type and a request from the wrong frame. The expected result is a controlled rejection. Use disposable files to examine write behavior without risking the user’s documents.
Review the distributed package and its backend
An ASAR file is an archive, not a secret store. Electron supports reading files inside it, as documented in the ASAR guide. Do not rely on packaging to conceal a privileged credential.
Keep separate notes for desktop and backend findings. A credential found in a package raises a different question from an API that accepts an unauthorized object identifier. The latter also needs an API authorization review. Fixing the renderer does not repair a server-side permission decision.
Record effects and retest the same operation
A configuration warning is a reason to investigate. Record what the tested content could actually do, which privileges it used and what remained unverified. A renderer XSS finding is not automatically proof of native code execution.
After a correction, repeat the failing operation and a valid user operation on the same build. Preserve the test conditions, build identifier and sanitized observations. This makes the retest useful to the engineer reviewing it.
This is an educational desktop review guide from Sintropyc. Our current Proof scan describes web application and API testing; a native desktop assessment needs a separately agreed scope. For the reporting approach, read proof of concept and exploit evidence.