Applications Electron : secrets et logique métier exposés dans l'ASAR

Une application Electron range son code dans un fichier app.asar : une concaténation de fichiers avec un index, sans chiffrement. Le 20 octobre 2026, Connor Turland a cartographié celle de Slack 4.52.171 avec REA en 52 secondes. Si vous éditez une application Electron, ce qui est dans votre archive est lisible par vos clients, vos concurrents et leurs agents.

Ce que contient une archive ASAR

Le format ASAR sert au packaging : il regroupe les fichiers JavaScript, HTML, CSS et les ressources de l'application en une archive que le runtime Electron lit sans extraction. Il n'a jamais eu vocation à protéger le contenu. Le README de REA range Electron parmi les cibles qui se lisent sans moteur de décompilation : modules, imports, source maps, routes, canaux IPC et add-ons natifs, sans lancer l'application¹.

Sur Slack, Turland a obtenu 529 fichiers JavaScript, 1 904 modules, 45 canaux IPC et 8 add-ons natifs, consignés dans un JSON de 158 Mo². Le test d'Ishank Choudhary sur une application de 100 Mo montre que les comptages structurels (fenêtres, API exposées au renderer, gestionnaires IPC) concordent avec un grep sur le source³. Le détail des tests est dans ce que REA révèle d'une application Electron.

Ce qui se retrouve exposé

Faites l'inventaire sur votre propre build. Les éléments qui posent problème reviennent d'un projet à l'autre : clés d'API de services tiers, identifiants de télémétrie avec droits d'écriture, URL d'environnements internes oubliées, drapeaux de fonctionnalités qui révèlent la feuille de route, règles de validation ou de calcul que le serveur ne refait pas. Tout cela se lit dans l'archive, minifié ou non.

Une clé présente dans l'archive d'une version publiée doit être tenue pour compromise, même si vous la retirez de la version suivante : les anciennes versions restent installées et téléchargeables. La seule réponse est la révocation.

Ce qu'il faut déplacer côté serveur

Aucun secret durable dans le client. Le client s'authentifie, le serveur lui remet un jeton court, limité en portée et révocable, et c'est le serveur qui appelle les services tiers avec la vraie clé. Les règles qui ont une valeur économique ou de sécurité (droits, quotas, tarification, licences) se vérifient côté serveur à chaque requête ; le client peut les répéter pour l'ergonomie, sans que le système en dépende.

Ajoutez une étape à votre chaîne de build : un scan de l'archive produite à la recherche de motifs de secrets, qui bloque la publication en cas de trouvaille. C'est moins coûteux qu'une révocation en urgence après publication.

Ce que l'intégrité protège, et ce qu'elle ne protège pas

Electron propose des fuses, des interrupteurs gravés dans le binaire au moment du packaging. L'un active la validation de l'intégrité de l'archive embarquée (EnableEmbeddedAsarIntegrityValidation), un autre impose de ne charger le code que depuis app.asar (OnlyLoadAppFromAsar). REA lit l'état de ces fuses dans le binaire sans lancer l'application ni modifier ses octets⁴. Activez-les : ils rendent plus difficile la modification de votre application sur le poste d'un utilisateur.

Ils ne protègent pas la lecture. Une archive dont l'intégrité est vérifiée reste lisible octet par octet. Le test de Turland le rappelle à sa manière : huit binaires natifs ne correspondaient pas à leur empreinte déclarée, ce que REA a attribué à une re-signature par l'outil de packaging. La première exécution s'est arrêtée sur ces écarts ; l'auteur a relancé avec --integrity-policy record-and-continue, et l'analyse a abouti en 52 secondes au second passage². L'obfuscation n'y change pas grand-chose non plus (voir obfuscation et protection du code face aux agents).

Auditer sa propre archive

Pour votre propre application, l'analyse statique suffit : elle lit les fichiers et ne lance rien. Passez votre build de production à l'outil, lisez la liste des canaux IPC et des appels réseau, cherchez les chaînes qui ressemblent à des clés, et comparez avec ce que vous pensiez livrer. Pour un binaire tiers d'origine inconnue, la règle change : REA n'est pas un sandbox, et l'analyse se fait en environnement isolé (confiner l'analyse). Le guide pour éditeurs élargit la démarche aux autres types d'applications.

Questions fréquentes

L'archive ASAR est-elle chiffrée ?

Non. C'est un format de packaging, lisible par tout outil qui connaît son index.

Un secret dans l'ASAR est-il protégé par la minification ?

Non. Une chaîne reste une chaîne. Révoquez-la et déplacez l'appel côté serveur.

Les fuses Electron suffisent-ils ?

Ils compliquent la modification de l'application installée. Ils ne changent rien à sa lisibilité.

Passer à l'audit

L'offre AI Cyber analyse vos applications à partir de leur code et de leurs builds, et livre la liste des éléments à retirer du client avec les correctifs. Vue d'ensemble dans le hub rétro-ingénierie par agents et sécurité.

Sources

1. morluto/rea, README (tableau « What you can analyze »), github.com/morluto/rea, consulté le 21 octobre 2026.
2. Connor Turland, What is REA (Reverse Engineer Anything)? I ran it on Slack to find out, atcyrus.com, 20 octobre 2026.
3. Ishank Choudhary, I Tested REA, GitHub's Viral Reverse Engineering Tool, on a Real Electron App, hackernoon.com, 14 octobre 2026.
4. morluto/rea, Electron fuse state (docs/electron-fuses.md), github.com, consulté le 21 octobre 2026.