Aller au contenu principal

Sécurité

Signaler des problèmes de sécurité

Pour plus d’informations sur la façon de communiquer correctement une vulnérabilité d'Electron, voir SECURITY.md.

Pour les vulnérabilités Chromium en amont : Electron se tient à jour par rapport aux nouvelles versions de Chromium. Pour plus d'informations, voir le document Electron Release Timelines.

Préface

Généralement, en tant que développeurs Web, nous apprécions le solide filet de sécurité du navigateur - les risques associés au code que nous écrivons sont relativement faibles. Nos sites Web bénéficient de pouvoirs limités dans un bac à sable, et nous sommes convaincus que nos utilisateurs bénéficient d'un navigateur construit par une grande équipe d'ingénieurs capables de répondre rapidement aux menaces de sécurité récemment découvertes.

Lorsque vous travaillez avec Electron, il est important de comprendre que l’Electron n’est pas un navigateur web. Il vous permet de developper des applications de bureau riche en fonctionnalités avec des technologies web familières, mais votre code exerce un pouvoir beaucoup plus grand. JavaScript peut accéder au système de fichiers, au shell et bien plus. Cela vous permet de développer des applications natives de haute qualité, mais les risques de sécurité inhérents évoluent avec les pouvoirs supplémentaires accordés à votre code.

Dans cet esprit, sachez qu’afficher un contenu arbitraire de sources peu fiables est un grave risque pour la sécurité qu'Electron n’est pas destiné à gérer. En fait, les applications Electron les plus populaires (Atom, Slack, Visual Studio Code, etc) affichent principalement du contenu local (ou du contenu fiable distant et sans intégration de Node ) si votre application exécute du code à partir d'une source en ligne, il vous incombe de vous assurer que celi-ci n'est pas malveillant.

Directives générales

La sécurité est la responsabilité de tous

Il est important de se rappeler que la sécurité de votre application Electron dépend de la sécurité globalement de la fondation du framework (Chromium, Node.js), Electron lui-même, toutes les dépendances NPM et votre code. Ainsi, il est de votre responsabilité de suivre quelques pratiques essentielles de test :

  • Gardez votre application à jour avec la dernière version de framework Electron. Lorsque vous libérez votre produit, vous expédiez également un paquet composé d'Electron, bibliothèque partagée Chromium et Node.js. Les vulnérabilités affectant ces composants peuvent affecter la sécurité de votre application. En mettant à jour Electron vers la dernière version vous vous assurez que les vulnérabilités critiques (telles que nodeIntegration bypasses) sont déjà corrigées et ne peuvent pas être exploitées dans votre application. Pour plus d'informations, voir "Utiliser une version actuelle d'Electron".

  • Évaluez vos dépendances. Alors que NPM fournit un demi-million de paquets réutilisables, il est de votre responsabilité de choisir des bibliothèques de tiers de confiance. Si vous utilisez des bibliothèques obsolètes affectées par des vulnérabilités connues ou si vous êtes dépendants d'un code mal géré, la sécurité de votre application pourrait être compromise.

  • Adoptez des pratiques de codage sécurisées. La première ligne de défense pour votre application est votre propre code. Des vulnérabilités web courantes, telles que le cross-site scripting (XSS), ont un impact de sécurité plus élevé sur les applications Electron, c'est pourquoi il est fortement recommandé d'adopter des meilleures pratiques de développement de logiciel sécurisé et d'effectuer des tests de sécurité.

Isolation du contenu non fiable

Un problème de sécurité existe chaque fois que vous recevez du code d'une source non fiable (par exemple, un serveur distant) et que vous l'exécutez localement. À titre d'exemple, considérez qu'un site Web distant est affiché à l'intérieur d'un BrowserWindow par défaut. Si un attaquant parvient d'une manière ou d'une autre à modifier ledit contenu (soit en s'attaquant directement à la source, ou en se plaçant entre votre application et la destination voulue), il sera en mesure d'exécuter le code natif sur la machine de l'utilisateur.

:::avertissement

En aucune circonstance vous devriez charger et exécuter du code distant avec l'intégration de Node.js activé. À la place, utilisez uniquement des fichiers locaux (empaquetés ensemble avec votre application) pour exécuter le code Node.js. Pour afficher du contenu distant, utilisez la balise <webview> ou BrowserViewet assurez-vous de désactiver nodeIntegration et d'activer contextIsolation.

:::

Avertissements de sécurité d'Electron

Security warnings and recommendations are printed to the developer console. Ils n'apparaissent que lorsque le nom du binaire est Electron, indiquant ainsi qu'un développeur peut voir actuellement la console.

Vous pouvez forcer l'activation ou la désactivation ces avertissements en définissant ELECTRON_ENABLE_SECURITY_WARNINGS ou ELECTRON_DISABLE_SECURITY_WARNINGS sur process.env ou sur l’objet window.

Checklist : recommandations de sécurité

Vous devriez au moins suivre ces étapes pour améliorer la sécurité de votre application :

  1. Charger uniquement du contenu sécurisé
  2. Désactiver l'intégration de Node.js dans tous les moteurs de rendu qui affichent du contenu distant
  3. Activer l'isolement du contexte dans tous les moteurs de rendu qui affichent le contenu distant
  4. Activer le sandboxing de processus
  5. Utiliser ses.setPermissionRequestHandler() dans toutes les sessions qui se chargent de contenu distant
  6. Ne pas désactiver webSecurity
  7. Définissez une Content-Security-Policy et utilisez des règles restrictives (c.-à-d. script-src 'self')
  8. Ne pas activer allowRunningInsecureContent
  9. Ne pas activer les fonctionnalités expérimentales
  10. Ne pas utiliser enableBlinkFeatures
  11. <webview> : N'utilisez pas allowpopups
  12. <webview>: Vérifier les options et les paramètres
  13. Désactiver ou limiter la navigation
  14. Désactiver ou limiter la création de nouvelles fenêtres
  15. Ne pas utiliser shell.openExternal avec un contenu non fiable
  16. Utiliser une version actuelle d'Electron

Pour automatiser la détection de mauvaises configurations et de procédures non sécurisés, il est possible d'utiliser electronegativity. Pour plus de détails sur les faiblesses potentielles et les bogues d'implémentation lorsque développant des applications utilisant Electron, veuillez vous référer à ce guide pour développeurs et auditeurs.

1. Charger uniquement du contenu sécurisé

Toutes les ressources non incluses avec votre application doivent être téléchargées à l’aide d’un protocole sécurisé HTTPS. En d’autres termes, n’utilisez pas de protocoles non sécurisés tels que HTTP. De même, nous vous recommandons d’utiliser WSS plutôt WS, FTPS par FTP et ainsi de suite.

Pourquoi ?

HTTPS a trois principaux avantages :

  1. Il authentifie le serveur distant, ce qui certifie que votre application se connecte à l'hôte réel plutôt qu'un imposteur.
  2. Il assure l'intégrité des données, certifiant que les données n'ont subit aucune modification durant le transfert entre votre application et l'hôte.
  3. Il encrypte le trafic entre votre l'utilisateur et l'hôte de destination, ce qui complique la tâche de quiconque voudrait épier les informations échangées entre l'hôte et votre application.

Comment ?

main.js (Main Process)
// Incorrect
browserWindow.loadURL('http://example.com')

// Correct
browserWindow.loadURL('https://example.com')
index.html (Renderer Process)
<!-- Incorrect -->
<script crossorigin src="http://example.com/react.js"></script>
<link rel="stylesheet" href="http://example.com/style.css">

<!-- Correct -->
<script crossorigin src="https://example.com/react.js"></script>
<link rel="stylesheet" href="https://example.com/style.css">

2. Ne pas activer l'intégration de Node.js pour du contenu distant

info

Cette recommandation est le comportement par défaut d'Electron depuis la version 5.0.0.

Il est primordial que vous n'activiez pas l'intégration de Node.js dans aucun moteur de rendu (BrowserWindow, BrowserView, ou <webview><3></2>) qui charge le contenu distant. Le but est de limiter les permissions accordées aux contenus distants, ce qui complique drastiquement la tâche pour un attaquant qui souhaiterait nuire à vos utilisateurs (si jamais cet attaquant réussissait à exécuter du javascript sur votre site).

Une fois cela fait, vous pouvez accorder des permissions supplémentaires à des hôtes spécifiques. Par exemple, si vous ouvrez un BrowserWindow pointé sur https://example. om/, vous pouvez donner à ce site exactement les capacités dont il a besoin, mais pas plus.

Pourquoi ?

Une attaque cross-site-scripting (XSS) est plus dangereuse si un attaquant peut sortir du processus de rendu et exécuter du code sur l'ordinateur de l'utilisateur. Les attaques de type cross-site-scripting sont assez courantes - et tant qu'un problème, leur pouvoir se limite généralement à gâcher avec le site Web sur lequel ils sont exécutés. La désactivation de l'intégration de Node.js aide à empêcher un XSS d'être escaladé pour devenir une attaque appelée "Exécution de Code distant" (RCE).

Comment ?

main.js (Main Process)
// Mauvais
const mainWindow = new BrowserWindow({
webPreferences: {
contextIsolation: false,
nodeIntegration: true,
nodeIntegrationInWorker: true
}
})

mainWindow.loadURL('https://example.com')
main.js (Main Process)
// Bon
const mainWindow = new BrowserWindow({
webPreferences: {
preload: path.join(app.getAppPath(), 'preload.js')
}
})

mainWindow.loadURL('https://example.com')
index.html (Renderer Process)
<!-- Incorrect -->
<webview nodeIntegration src="page.html"></webview>

<!-- Correct -->
<webview src="page.html"></webview>

Lors de la désactivation de l'intégration de Node.js, vous pouvez toujours exposer des API à votre site web qui consomment des modules ou des fonctionnalités de Node.js. Les scripts de préchargement continuent d'avoir accès à require et aux autres fonctionnalités de Node.js, permettant aux développeurs d'exposer une API personnalisée au contenu distant chargé via l'API de contextBridge .

3. Activer l'isolement du contexte pour du contenu distant

info

Cette recommandation est le comportement par défaut d'Electron depuis la version 12.0.0.

L'isolement du contexte est une fonctionnalité d'Electron qui permet aux développeurs d'exécuter du code dans les scripts de préchargement et dans les API Electron dans un contexte JavaScript dédié. Dans la pratique cela signifie que les objets globaux comme Array.prototype.push ou JSON.parse ne peuvent pas être modifiés par les scripts exécutés dans le processus de rendu.

Electron utilise la même technologie que Chromium Content Scripts pour permettre ce comportement.

Même lorsque nodeIntegration: false est utilisé, pour vraiment appliquer une isolation forte et empêcher l'utilisation des primitives de Node contextIsolation doit également être utilisé.

info

Pour plus d'informations sur ce qu'est contextIsolation et comment l'activer, veuillez voir notre document dédié Isolation du contexte.

4. Activer le sandboxing de processus

Sandboxing est une fonctionnalité de Chromium qui utilise le système d’exploitation pour limiter considérablement les processus de rendu auxquels ils ont accès. Vous devez activer le bac à sable dans tous les moteurs de rendu. Charger, lire ou traiter tout contenu non fiable dans un processus non protégé par le bac à sable, y compris le processus principal, n'est pas conseillé.

info

For more information on what contextIsolation is and how to enable it please see our dedicated Process Sandboxing document.

5. Gestion des demandes d’autorisation de session à partir d'un contenu distant

Vous avez peut-être vu des demandes d'autorisation lors de l'utilisation de Chrome : elles apparaissent chaque fois que le site Web tente d'utiliser une fonctionnalité que l'utilisateur doit approuver manuellement ( comme les notifications).

L'API se base sur l'API de permissions Chromium et implémente le même type de permissions.

Pourquoi ?

Par défaut, Electron approuvera automatiquement toutes les demandes de permission, sauf si le développeur a manuellement configuré un gestionnaire personnalisé. Bien que la valeur par défaut soit solide, les développeurs soucieux de la sécurité pourraient vouloir assumer le contraire.

Comment ?

main.js (Main Process)
const { session } = require('electron')

session
.fromPartition('some-partition')
.setPermissionRequestHandler((webContents, permission, callback) => {
const url = webContents.getURL()

if (permission === 'notifications') {
// Approves the permissions request
callback(true)
}

// Verify URL
if (!url.startsWith('https://example.com/')) {
// Denies the permissions request
return callback(false)
}
})

6. Ne pas désactiver webSecurity

info

This recommendation is Electron's default.

Vous avez peut-être déjà deviné que la désactivation de la propriété webSecurity sur un processus de rendu (BrowserWindow, BrowserView, ou <webview>) désactive les fonctionnalités de sécurité cruciales. .

Ne pas désactiver webSecurity dans les applications de production.

Pourquoi ?

Désactiver webSecurity désactivera la politique de même origine et définira la propriété allowRunningInsecureContent à true. En d'autres termes, il permet l'exécution de code non sécurisé à partir de différents domaines.

Comment ?

main.js (Main Process)
// Incorrect
const mainWindow = new BrowserWindow({
webPreferences: {
webSecurity: false
}
})
main.js (Main Process)
// Correct
const mainWindow = new BrowserWindow()
index.html (Renderer Process)
<!-- Incorrect -->
<webview disablewebsecurity src="page.html"></webview>

<!-- Correct -->
<webview src="page.html"></webview>

7. Define a Content Security Policy

Une politique de sécurité de contenu (CSP) est une couche supplémentaire de protection contre des attaques cross-site-scripting et des attaques d'injection de données. Nous recommandons qu'ils soient activés par n'importe quel site Web que vous chargez dans Electron.

Pourquoi ?

CSP permet au serveur servant le contenu de restreindre et de contrôler les ressources Electron peut charger pour cette page web. https://example.com devrait être autorisé à charger des scripts depuis les origines que vous avez définies alors que les scripts de https://evil.attacker.com ne devraient pas être autorisés à s'exécuter. Définir un CSP est un moyen facile d'améliorer la sécurité de votre application.

Comment ?

Le CSP suivant permettra à Electron d'exécuter des scripts depuis le site web actuel et depuis apis.example.com.

// Incorrect
Content-Security-Policy: '*'

// Correct
Content-Security-Policy: script-src 'self' https://apis.example.com

CSP HTTP headers

Electron respecte le Content-Security-Policy en-tête HTTP qui peut être défini en utilisant le gestionnaire webRequest.onHeadersReceived d'Electron :

main.js (Main Process)
const { session } = require('electron')

session.defaultSession.webRequest.onHeadersReceived((details, callback) => {
callback({
responseHeaders: {
...details.responseHeaders,
'Content-Security-Policy': ['default-src \'none\'']
}
})
})

CSP meta tag

CSP's preferred delivery mechanism is an HTTP header. However, it is not possible to use this method when loading a resource using the file:// protocol. It can be useful in some cases to set a policy on a page directly in the markup using a <meta> tag:

index.html (Renderer Process)
<meta http-equiv="Content-Security-Policy" content="default-src 'none'">

8. Ne pas activer allowRunningInsecureContent

info

This recommendation is Electron's default.

Par défaut, Electron n'autorisera pas les sites Web chargés sur HTTPS à charger et exécuter des scripts, CSS ou plugins à partir de sources non sécurisées (HTTP). Définir la propriété allowRunningInsecureContent à true désactive cette protection.

Chargement du HTML initial d'un site sur HTTPS et tentative de chargement de ressources ultérieures via HTTP est aussi connu sous le nom de "contenu mixte".

Pourquoi ?

Le chargement du contenu sur HTTPS assure l'authenticité et l'intégrité des ressources chargées tout en chiffrant le trafic lui-même. Consultez la section sur l' affichage du contenu sécurisé uniquement pour plus de détails.

Comment ?

main.js (Main Process)
// Incorrect
const mainWindow = new BrowserWindow({
webPreferences: {
allowRunningInsecureContent: true
}
})
main.js (Main Process)
// Correct
const mainWindow = new BrowserWindow({})

9. Ne pas activer les fonctionnalités expérimentales

info

This recommendation is Electron's default.

Les utilisateurs avancés d'Electron peuvent activer les fonctionnalités expérimentales de Chromium en utilisant la propriété fonctionnalités expérimentales.

Pourquoi ?

Experimental features are, as the name suggests, experimental and have not been enabled for all Chromium users. Furthermore, their impact on Electron as a whole has likely not been tested.

Il est parfois légitime de les implémenter, mais à moins que vous sachiez vraiment ce que vous faites, vous ne devriez pas autoriser ces fonctionnalités.

Comment ?

main.js (Main Process)
// Incorrect
const mainWindow = new BrowserWindow({
webPreferences: {
experimentalFeatures: true
}
})
main.js (Main Process)
// Correct
const mainWindow = new BrowserWindow({})

10. Ne pas utiliser enableBlinkFeatures

info

This recommendation is Electron's default.

Blink est le nom du moteur de rendu derrière Chromium. Comme pour experimentalFeatures, la propriété enableBlinkFeatures permet aux développeurs d'activer les fonctionnalités qui ont été désactivées par défaut.

Pourquoi ?

De manière générale, il y a probablement de bonnes raisons si une fonctionnalité n'était pas activée par défaut. Il existe des cas d'utilisation légitime pour l'activation de fonctionnalités spécifiques. En tant que développeur , vous devriez savoir exactement pourquoi vous avez besoin d'activer une fonctionnalité, quelles sont les ramifications et comment elles ont un impact sur la sécurité de votre application. En aucune circonstance ne devrait vous permettre d'activer des fonctionnalités de manière spéculative.

Comment ?

main.js (Main Process)
// Mauvais
const mainWindow = new BrowserWindow({
webPreferences: {
enableBlinkFeatures: 'ExecCommandInJavaScript'
}
})
main.js (Main Process)
// Correct
const mainWindow = new BrowserWindow()

11. Do not use allowpopups for WebViews

info

This recommendation is Electron's default.

Si vous utilisez <webview>, vous aurez peut-être besoin des pages et des scripts chargés dans votre balise <webview> pour ouvrir de nouvelles fenêtres. L'attribut allowpopups leur permet de créer un nouveau BrowserWindows en utilisant la méthode window.open(). Les balises <webview> ne sont pas autorisées à créer de nouvelles fenêtres .

Pourquoi ?

Si vous n'avez pas besoin de popups, il vaut mieux ne pas autoriser la création de nouveaux BrowserWindows par défaut. Cela suit le principe d'accès minimum requis : ne laissez pas un site web créer de nouvelles fenêtres popups à moins que vous sachiez qu'il a besoin de cette fonctionnalité.

Comment ?

index.html (Renderer Process)
<!-- Incorrect -->
<webview allowpopups src="page.html"></webview>

<!-- Correct -->
<webview src="page.html"></webview>

12. Verify WebView options before creation

Un WebView créé dans un processus de rendu qui n'a pas d'intégration Node.js activé ne sera pas en mesure d'activer l'intégration elle-même. Cependant, un WebView créera toujours un processus de rendu indépendant avec ses propres webPreferences.

C'est une bonne idée de contrôler la création de nouvelles balises <webview><1></0> depuis le processus principal et de vérifier que leurs préférences web ne désactivent pas les fonctions de sécurité .

Pourquoi ?

Depuis que <webview> vivent dans le DOM, ils peuvent être créés par un script exécuté sur votre site web même si l'intégration de Node.js est désactivée.

Electron permet aux développeurs de désactiver diverses fonctionnalités de sécurité qui contrôlent un processus de rendu. Dans la plupart des cas, les développeurs n'ont pas besoin de désactiver ces fonctionnalités - et vous ne devriez donc pas autoriser différentes configurations pour les balises <webview><1></0> nouvellement créées.

Comment ?

Avant qu'un tag <webview></0> ne soit attaché, Electron lancera l'événement <2>will-attach-webview</2> sur l'hébergement <2>webContents</2>. Utilisez l'événement pour empêcher la création de <code>webViews avec des options potentiellement non sécurisées.

main.js (Main Process)
app.on('web-contents-created', (event, contents) => {
contents.on('will-attach-webview', (event, webPreferences, params) => {
// Strip away preload scripts if unused or verify their location is legitimate
delete webPreferences.preload
delete webPreferences.preloadURL

// Disable Node.js integration
webPreferences.nodeIntegration = false

// Verify URL being loaded
if (!params.src.startsWith('https://example.com/')) {
event.preventDefault()
}
})
})

Again, this list merely minimizes the risk, but does not remove it. If your goal is to display a website, a browser will be a more secure option.

13. Désactiver ou limiter la navigation

Si votre application n'a pas besoin de naviguer ou a seulement besoin de naviguer vers des pages connues, c'est une bonne idée de limiter la navigation directement à cette portée connue, interdire tout autre type de navigation.

Pourquoi ?

La navigation est un vecteur d'attaque courant. Si un attaquant peut convaincre votre application de naviguer loin de sa page actuelle, ils peuvent éventuellement forcer votre application à ouvrir sites web sur Internet. Même si vos webContents sont configurés pour être plus sécurisé (comme avoir nodeIntegration désactivé ou contextIsolation activé), pour que votre application ouvre un site web aléatoire rendra le travail d'exploiter votre application beaucoup plus facile.

Un modèle d'attaque courant est que l'attaquant convainc les utilisateurs de votre application d'interagir avec l'application de manière à ce qu'il navigue sur l'une des pages de l'attaquant. Cela se fait généralement par le biais de liens, de plugins, ou d'autres contenus générés par l'utilisateur.

Comment ?

Si votre application n'a pas besoin de navigation, vous pouvez appeler event.preventDefault() dans un gestionnaire navigate. Si vous savez vers quelles pages votre application peut naviguer, vérifiez l'URL dans le gestionnaire d'événements et laissez seulement la navigation se produire si elle correspond aux URL que vous attendez.

Nous vous recommandons d'utiliser l'analyseur de Node pour les URL. Des comparaisons simples de chaînes de caractères peuvent parfois être dupliquées - un test startsWith('https://example.com') laisserait pas https://example.com.attacker.com à travers.

main.js (Main Process)
const URL = require('url').URL

app.on('web-contents-created', (event, contents) => {
contenu. n('will-navigate', (event, navigationUrl) => {
const parsedUrl = new URL(navigationUrl)

if (parsedUrl. rigin !== 'https://example.com') {
event.preventDefault()
}
})
})

14. Désactiver ou limiter la création de nouvelles fenêtres

Si vous avez un ensemble connu de fenêtres, il est bon de limiter la création de fenêtres supplémentaires dans votre application.

Pourquoi ?

Tout comme la navigation, la création de nouveaux webContents est un vecteur d'attaque commun . Les attaquants tentent de convaincre votre application de créer de nouvelles fenêtres, cadres, ou d'autres processus de rendu avec plus de privilèges qu'avant; ou avec des pages ouvertes qu'ils ne pouvaient pas ouvrir avant.

Si vous n'avez pas besoin de créer des fenêtres en plus de celles que vous savez que vous aurez besoin de créer, la désactivation de la création vous permet d'acheter gratuitement un peu de sécurité supplémentaire. C'est généralement le cas pour les applications qui ouvrent une BrowserWindow et n'ont pas besoin d'ouvrir un nombre arbitraire de fenêtres supplémentaires à l'exécution.

Comment ?

webContents will delegate to its window open handler before creating new windows. The handler will receive, amongst other parameters, the url the window was requested to open and the options used to create it. We recommend that you register a handler to monitor the creation of windows, and deny any unexpected window creation.

main.js (Main Process)
const { shell } = require('electron')

app.on('web-contents-created', (event, contents) => {
contents.setWindowOpenHandler(({ url }) => {
// In this example, we'll ask the operating system
// to open this event's url in the default browser.
//
// See the following item for considerations regarding what
// URLs should be allowed through to shell.openExternal.
if (isSafeForExternalOpen(url)) {
setImmediate(() => {
shell.openExternal(url)
})
}

return { action: 'deny' }
})
})

15. Ne pas utiliser shell.openExternal avec un contenu non fiable

The shell module's openExternal API allows opening a given protocol URI with the desktop's native utilities. On macOS, for instance, this function is similar to the open terminal command utility and will open the specific application based on the URI and filetype association.

Pourquoi ?

L'utilisation incorrecte de openExternal peut être utilisée pour compromettre l'hôte de l'utilisateur. Lorsque openExternal est utilisé avec du contenu non fiable, il peut être exploité pour exécuter des commandes arbitraires.

Comment ?

main.js (Main Process)
// Mauvais
const { shell } = require('electron')
shell.openExternal(USER_CONTROLLED_DATA_HERE)
main.js (Main Process)
// Bon
const { shell } = require('electron')
shell.openExternal('https://example.com/index.html')

16. Utiliser une version actuelle d'Electron

Vous devriez toujours vous efforcer d'utiliser la dernière version disponible d'Electron. Chaque fois qu'une nouvelle version majeure est publiée, vous devriez essayer de mettre à jour votre application le plus rapidement possible.

Pourquoi ?

Une application construite avec une ancienne version d'Electron, de Chromium ou de Node.js est une cible plus facile qu'une application qui utilise des versions plus récentes de ces composants. De manière générale, les problèmes de sécurité et les exploitation de failles pour les anciennes versions de Chromium et de Node.js sont plus fréquentes.

Chromium et Node.js représentent des prouesses impressionnantes d'ingénierie produites par des milliers de développeurs talentueux. Compte tenu de leur popularité, leur sécurité est soigneusement testée et analysée par des chercheurs en sécurité tout aussi compétents. Beaucoup de ces chercheurs révèlent des vulnérabilités de manière responsable, ce qui signifie généralement que les chercheurs donnent de leur temps à Chromium et Node.js pour résoudre les problèmes avant de les publier. Votre application sera plus sécurisée si elle exécute une version récente d'Electron (et donc Chromium et Node.js) dont les problèmes de sécurité potentiels ne sont pas aussi connus.

Comment ?

Migrate your app one major version at a time, while referring to Electron's Breaking Changes document to see if any code needs to be updated.