Build Secure Electron Desktop Applications
Security-first Electron desktop app guidance covering process isolation, IPC whitelisting, packaging, code signing, and auto-update.
Why it matters
Develop robust, production-ready desktop applications using Electron. This skill focuses on secure architecture, efficient IPC, and reliable packaging for seamless distribution.
Outcomes
What it gets done
Architect secure Electron applications with multi-process isolation.
Implement secure IPC communication between main, renderer, and preload.
Package and distribute applications using electron-builder or electron-forge.
Integrate auto-update mechanisms with electron-updater.
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-electron-development | bash Overview
Electron Development
Electron Development gives security-first guidance for building production Electron desktop apps - process isolation defaults, whitelisted IPC design, a security hardening checklist, state management, and build/signing/auto-update setup. Use it when building, securing, packaging, or debugging an Electron desktop application; not for web-only, Tauri, Chrome extension, backend-only, or mobile projects.
What it does
Electron Development provides senior-level guidance for secure, production-grade Electron desktop applications, covering the multi-process model, IPC security, native OS integration, packaging, code signing, and auto-update. It works through a fixed instruction sequence: analyze the project's process boundaries, enforce security defaults (contextIsolation: true, nodeIntegration: false, sandbox: true), design IPC channels with explicit whitelisting in the preload script, implement/test/build with appropriate tooling, then validate against a Production Security Checklist before shipping.
It covers seven core expertise areas. Project structure lays out a recommended main/preload/renderer/shared layout, with the principle that the shared/ directory holds only types, constants, and enums - never executable code crossing process boundaries - and that the main process should stay lean, orchestrating windows and IPC rather than holding business logic. The process model explains the distinct roles and Node.js/DOM access of the Main, Renderer, Preload, and Utility processes, and mandates BrowserWindow security defaults:
webPreferences: {
// ── SECURITY DEFAULTS (NEVER CHANGE THESE) ──
contextIsolation: true, // Isolates preload from renderer context
nodeIntegration: false, // Prevents require() in renderer
sandbox: true, // OS-level process sandboxing
// ── PRELOAD SCRIPT ──
preload: path.join(__dirname, '../preload/preload.js'),
// ── ADDITIONAL HARDENING ──
webSecurity: true, // Enforce same-origin policy
allowRunningInsecureContent: false,
experimentalFeatures: false,
},
Secure IPC communication requires contextBridge with an explicit send/receive channel whitelist in the preload script, ipcMain.handle()/ipcRenderer.invoke() for request-response calls, and never ipcRenderer.sendSync() since it blocks the renderer's event loop. Security hardening adds a full Production Security Checklist (contextIsolation, sandboxing, CSP headers, no eval/innerHTML with untrusted data, ASAR packaging, code signing), plus concrete patterns for blocking unexpected navigation via will-navigate, denying pop-ups via setWindowOpenHandler, and registering custom protocols that reject paths escaping their base directory.
State management covers keeping the main process as the single source of truth with a small file-backed Store class, using the electron-store library as a lighter alternative, and broadcasting state changes to all open windows via webContents.send(). Build, signing, and distribution covers electron-builder configuration for macOS (hardened runtime, entitlements, dmg/zip), Windows (nsis), and Linux (AppImage, deb) targets, code signing certificates, wiring electron-updater for auto-update (checking on an interval, downloading, and installing on quit), and bundle-size optimization (asar, maximum compression, excluding dev dependencies, tree-shaking, @electron/rebuild for native modules). Developer experience covers hot-reload dev setups with electron-vite or electron-forge, VS Code main-process debugging via a launch.json, and testing with Vitest/Jest for units and Playwright's Electron support for E2E, including a sample playwright.config.ts.
The skill also includes application lifecycle wiring (registering IPC handlers, restoring/saving window bounds, macOS dock-icon reactivation, quitting on window-all-closed except macOS, blocking <webview> tag attachment) and diagnostics for five common issues - white screen on launch, IPC messages not received, native module crashes, auto-update not working, and bundle size over 200MB - each with symptoms, root causes, and solutions.
When to use - and when NOT to
Use this skill for building new Electron desktop apps from scratch, securing an existing app's contextIsolation/sandbox/CSP/nodeIntegration settings, setting up main/renderer/preload IPC, packaging and distributing with electron-builder or electron-forge, implementing auto-update with electron-updater, debugging main-process or renderer issues, managing multiple windows and app lifecycle, integrating native OS features like menus/tray/notifications/file dialogs, or optimizing performance and bundle size.
Do not use it for web-only apps without desktop distribution (use react-patterns or nextjs-best-practices instead), Tauri-based desktop apps (use tauri-development), Chrome extensions (use chrome-extension-developer), deep backend/server logic (use nodejs-backend-patterns), or mobile apps (use react-native-architecture or flutter-expert). The skill also names hard limitations: Electron's Chromium+Node.js bundle has a roughly 150MB minimum app size, making it unsuitable where install size is critical; multi-window state sync needs careful IPC design; electron-updater has limited Linux auto-update support (Snap/Flatpak or custom mechanisms are needed instead); and macOS notarization requires a paid Apple Developer account and is mandatory for distribution outside the Mac App Store.
Inputs and outputs
Input is the Electron project's structure and requirements. Output is architectural guidance and code following the mandatory security defaults, whitelisted IPC channel design, a Production Security Checklist validation pass, build/signing configuration (electron-builder.yml, code-signing setup), and, when debugging, a diagnosis matching symptoms to root cause and solution for the five common issue categories the skill enumerates.
Integrations
The skill centers on electron-builder or electron-forge for packaging, electron-updater and electron-store for updates and persistence, Vitest/Jest plus Playwright's _electron support for testing, and VS Code for main-process debugging. It cross-references related skills for adjacent concerns: chrome-extension-developer for browser extensions, docker-expert for containerizing the build pipeline, react-patterns/react-best-practices for the renderer UI, typescript-pro for multi-target TypeScript configuration, nodejs-backend-patterns for complex main-process backend logic, and github-actions-templates for cross-platform CI/CD.
Who it's for
Engineers building or hardening production Electron desktop applications who need concrete, security-first guidance on process isolation, IPC design, packaging, code signing, and auto-update rather than generic Electron tutorials.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.