Sécurité

Le moteur : Chromium, V8, Skia

Au cours de 2026, des dizaines de failles de sécurité mémoire ont été corrigées dans Chrome, dont six zero-days exploités dans la nature. Ce code n'est pas le nôtre et nous ne pouvons pas le corriger ; la seule défense ici consiste à maintenir le moteur à jour.

D'où une règle sans détour : Girginos Browser n'est pas publié sur une version d'Electron arrivée en fin de vie. Electron ne prend en charge que ses trois dernières versions majeures, et la version épinglée est vérifiée avant chaque publication. Nous utilisons actuellement Electron 44.2.0 avec Chromium 152.0.7977.76.

Le shell : le code que nous avons écrit

Voici les décisions d'architecture côté shell :

• Chaque onglet est une WebContentsView distincte. Le contenu des pages s'exécute avec sandbox: true, contextIsolation: true et nodeIntegration: false, et ne reçoit aucun script de préchargement.
• La fenêtre de l'interface s'exécute elle aussi en bac à sable et partage une session avec les onglets ; ainsi, les requêtes propres à l'interface passent également par le bloqueur et portent les en-têtes DNT.
• Les canaux IPC ne sont acceptés que depuis le cadre principal de la fenêtre de l'interface. Les écritures de réglages passent par une validation de clé et de type.
• Les téléchargements sont désignés par un identifiant ; un chemin de fichier brut venant de l'interface n'est jamais ouvert.
• La navigation déclenchée par la page se limite à http(s) et view-source:http(s). file: et chrome: ne s'ouvrent que si l'utilisateur les saisit lui-même dans la barre d'adresse.
• Le passage à une application externe se limite à une liste étroite de schémas : mailto:, tel:, sms:, magnet:, ftp(s):, webcal:. Une seule boîte de confirmation peut être ouverte à la fois.
• Les origines opaques — celles dont l'origine est null, comme data: et about: — sont toujours refusées lors des demandes d'autorisation.
• La correction orthographique est désactivée, parce que Chromium télécharge ses fichiers de dictionnaire depuis un serveur Google.
• Les données sont écrites de façon atomique, via un fichier temporaire puis un renommage.

Vecteurs d'attaque et parades

La chaîne de mise à jour signée

Le modèle de menace suppose que le serveur de mise à jour peut déjà être compromis. La séquence se déroule ainsi :

1. Le manifeste signé et le fichier de signature qui l'accompagne sont récupérés.
2. La signature est vérifiée sur les octets bruts du manifeste avec la clé publique Ed25519 intégrée à l'application. Si elle ne passe pas, pas un seul champ n'est lu.
3. Des verrous de version s'appliquent : les retours à une version antérieure sont refusés ; un manifeste dont la date d'expiration est dépassée est refusé — cela protège d'un attaquant qui servirait indéfiniment un vieux manifeste pour geler les mises à jour ; une version intermédiaire est imposée là où c'est nécessaire ; et l'adresse de téléchargement doit être en https.
4. La version et l'empreinte du paquet trouvées par le téléchargeur doivent correspondre exactement à celles du manifeste signé.
5. Une fois le téléchargement terminé, l'empreinte sha512 du paquet est comparée à l'empreinte signée en temps constant.
6. L'installation ne démarre qu'une fois que l'utilisateur l'a approuvée.

Si une seule étape échoue, aucune mise à jour n'a lieu. La clé privée n'est jamais conservée sur le serveur ; même si celui-ci était pris, un attaquant ne pourrait pas produire de manifeste valide.

Tests

118 tests unitaires, 73 régressions sur les vecteurs d'attaque et 46 tests de vérification des mises à jour sont exécutés sur le code, et le contrat IPC et DOM entre l'interface et le processus principal est testé à part. À côté de cela, des scripts de vérification de bout en bout tournent avant et après chaque publication, sur les fichiers réellement produits et sur le serveur en ligne.