Security
For information on how to properly disclose an Electron vulnerability, see SECURITY.md.
For upstream Chromium vulnerabilities: Electron keeps up to date with alternating Chromium releases. For more information, see the Electron Release Timelines document.
Preface
As web developers, we usually enjoy the strong security net of the browser — the risks associated with the code we write are relatively small. Our websites are granted limited powers in a sandbox, and we trust that our users enjoy a browser built by a large team of engineers that is able to quickly respond to newly discovered security threats.
When working with Electron, it is important to understand that Electron is not a web browser. It allows you to build feature-rich desktop applications with familiar web technologies, but your code wields much greater power. JavaScript can access the filesystem, user shell, and more. This allows you to build high quality native applications, but the inherent security risks scale with the additional powers granted to your code.
With that in mind, be aware that displaying arbitrary content from untrusted sources poses a severe security risk that Electron is not intended to handle. In fact, the most popular Electron apps (Atom, Slack, Visual Studio Code, etc) display primarily local content (or trusted, secure remote content without Node integration) — if your application executes code from an online source, it is your responsibility to ensure that the code is not malicious.
General guidelines
Security is everyone's responsibility
It is important to remember that the security of your Electron application is the result of the overall security of the framework foundation (Chromium, Node.js), Electron itself, all NPM dependencies and your code. As such, it is your responsibility to follow a few important best practices:
-
Keep your application up-to-date with the latest Electron framework release. When releasing your product, you’re also shipping a bundle composed of Electron, Chromium shared library and Node.js. Vulnerabilities affecting these components may impact the security of your application. By updating Electron to the latest version, you ensure that critical vulnerabilities (such as nodeIntegration bypasses) are already patched and cannot be exploited in your application. For more information, see "Use a current version of Electron".
-
Evaluate your dependencies. While NPM provides half a million reusable packages, it is your responsibility to choose trusted 3rd-party libraries. If you use outdated libraries affected by known vulnerabilities or rely on poorly maintained code, your application security could be in jeopardy.
-
Adopt secure coding practices. The first line of defense for your application is your own code. Common web vulnerabilities, such as Cross-Site Scripting (XSS), have a higher security impact on Electron applications hence it is highly recommended to adopt secure software development best practices and perform security testing.
Isolation for untrusted content
A security issue exists whenever you receive code from an untrusted source (e.g.
a remote server) and execute it locally. As an example, consider a remote
website being displayed inside a default BrowserWindow. If
an attacker somehow manages to change said content (either by attacking the
source directly, or by sitting between your app and the actual destination), they
will be able to execute native code on the user's machine.
Under no circumstances should you load and execute remote code with
Node.js integration enabled. Instead, use only local files (packaged together
with your application) to execute Node.js code. To display remote content, use
the <webview> tag or a WebContentsView
and make sure to disable the nodeIntegration and enable contextIsolation.
Security warnings and recommendations are printed to the developer console. They only show up when the binary's name is Electron, indicating that a developer is currently looking at the console.
You can force-enable or force-disable these warnings by setting
ELECTRON_ENABLE_SECURITY_WARNINGS or ELECTRON_DISABLE_SECURITY_WARNINGS on
either process.env or the window object.
Checklist: Security recommendations
You should at least follow these steps to improve the security of your application:
- Only load secure content
- Do not enable Node.js integration for remote content
- Enable context isolation in all renderers
- Enable process sandboxing
- Use
ses.setPermissionRequestHandler()in all sessions that load remote content - Do not disable
webSecurity - Define a
Content-Security-Policyand use restrictive rules (i.e.script-src 'self') - Do not enable
allowRunningInsecureContent - Do not enable experimental features
- Do not use
enableBlinkFeatures <webview>: Do not useallowpopups<webview>: Verify options and params- Disable or limit navigation
- Disable or limit creation of new windows
- Do not use
shell.openExternalwith untrusted content - Use a current version of Electron
- Validate the
senderof all IPC messages - Avoid usage of the
file://protocol and prefer usage of custom protocols - Check which fuses you can change
- Do not expose Electron APIs to untrusted web content
1. Only load secure content
Any resources not included with your application should be loaded using a
secure protocol like HTTPS. In other words, do not use insecure protocols
like HTTP. Similarly, we recommend the use of WSS over WS, FTPS over
FTP, and so on.
Why?
HTTPS has two main benefits:
- It ensures data integrity, asserting that the data was not modified while in transit between your application and the host.
- It encrypts the traffic between your user and the destination host, making it more difficult to eavesdrop on the information sent between your app and the host.
How?
// Bad
browserWindow.loadURL('http://example.com')
// Good
browserWindow.loadURL('https://example.com')
<!-- Bad -->
<script crossorigin src="http://example.com/react.js"></script>
<link rel="stylesheet" href="http://example.com/style.css">
<!-- Good -->
<script crossorigin src="https://example.com/react.js"></script>
<link rel="stylesheet" href="https://example.com/style.css">
2. Do not enable Node.js integration for remote content
This recommendation is the default behavior in Electron since 5.0.0.
It is paramount that you do not enable Node.js integration in any renderer
(BrowserWindow, WebContentsView, or
<webview>) that loads remote content. The goal is to limit the
powers you grant to remote content, thus making it dramatically more difficult
for an attacker to harm your users should they gain the ability to execute
JavaScript on your website.
After this, you can grant additional permissions for specific hosts. For example,
if you are opening a BrowserWindow pointed at https://example.com/, you can
give that website exactly the abilities it needs, but no more.
Why?
A cross-site-scripting (XSS) attack is more dangerous if an attacker can jump out of the renderer process and execute code on the user's computer. Cross-site-scripting attacks are fairly common - and while an issue, their power is usually limited to messing with the website that they are executed on. Disabling Node.js integration helps prevent an XSS from being escalated into a so-called "Remote Code Execution" (RCE) attack.
How?
// Bad
const mainWindow = new BrowserWindow({
webPreferences: {
contextIsolation: false,
nodeIntegration: true,
nodeIntegrationInWorker: true
}
})
mainWindow.loadURL('https://example.com')
// Good
const mainWindow = new BrowserWindow({
webPreferences: {
preload: path.join(app.getAppPath(), 'preload.js')
}
})
mainWindow.loadURL('https://example.com')
<!-- Bad -->
<webview nodeIntegration src="page.html"></webview>
<!-- Good -->
<webview src="page.html"></webview>
When disabling Node.js integration, you can still expose APIs to your website that
do consume Node.js modules or features. Preload scripts continue to have access
to require and other Node.js features, allowing developers to expose a custom
API to remotely loaded content via the contextBridge API.
3. Enable Context Isolation
Context Isolation is the default behavior in Electron since 12.0.0.
Context isolation is an Electron feature that allows developers to run code
in preload scripts and in Electron APIs in a dedicated JavaScript context. In
practice, that means that global objects like Array.prototype.push or
JSON.parse cannot be modified by scripts running in the renderer process.
Electron uses the same technology as Chromium's Content Scripts to enable this behavior.
Even when nodeIntegration: false is used, to truly enforce strong isolation
and prevent the use of Node primitives contextIsolation must also be used.
Beware that disabling context isolation for a renderer process by setting
nodeIntegration: true also disables process sandboxing for that process.
See section below.
For more information on what contextIsolation is and how to enable it please
see our dedicated Context Isolation document.
4. Enable process sandboxing
This recommendation is the default behavior in Electron since 20.0.0.
Additionally, process sandboxing can be enforced for all renderer processes application wide: Enabling the sandbox globally
Disabling context isolation (see above) also disables process sandboxing,
regardless of the default, sandbox: false or globally enabled sandboxing!
Sandboxing is a Chromium feature that uses the operating system to significantly limit what renderer processes have access to. You should enable the sandbox in all renderers. Loading, reading or processing any untrusted content in an unsandboxed process, including the main process, is not advised.
For more information on what Process Sandboxing is and how to enable it please see our dedicated Process Sandboxing document.
5. Handle session permission requests from remote content
You may have seen permission requests while using Chrome: they pop up whenever the website attempts to use a feature that the user has to manually approve ( like notifications).
The API is based on the Chromium permissions API and implements the same types of permissions.
Why?
By default, Electron will automatically approve all permission requests unless the developer has manually configured a custom handler. While a solid default, security-conscious developers might want to assume the very opposite.
How?
const { session } = require('electron')
const { URL } = require('node:url')
session
.defaultSession
.setPermissionRequestHandler((webContents, permission, callback) => {
const parsedUrl = new URL(webContents.getURL())
if (permission ===