D’abord la conclusion : ce que vous pouvez vérifier sur place, c’est si cette requête HTTP a envoyé du texte en clair, un mot de passe ou une clé de fragment comme donnée métier. Cela ne prouve pas qu’une extension n’a pas lu le presse-papiers, ni que la version suivante se comportera de la même façon. Les étapes ci-dessous sont reproductibles — pas une nouvelle série d’adjectifs.
Répondre à l’intention de recherche en une phrase
Le chiffrement local dans le navigateur, c’est chiffrer et déchiffrer dans l’onglet que vous regardez : le script appelle la Web Crypto API du navigateur, termine des algorithmes de type AES-GCM sur cet appareil, et le texte en clair et les clés ne quittent pas le navigateur comme corps HTTP, par défaut. La vérification n’est pas une phrase marketing : ouvrez DevTools Network, cherchez un canari, puis retestez hors ligne si besoin.
Cet article s’adresse aux développeurs, à l’exploitation, et à quiconque veut regarder avant de remettre un fichier ou un mot de passe à un « outil en ligne ». Il ne remplace pas le mode d’emploi du coffre de chiffrement, et ne répète pas la définition produit de l’accueil. Ce qu’il faut emporter : un contrôle réutilisable sur n’importe quel site.
Les slogans ne se prouvent pas ; le trafic, lui, s’observe
Beaucoup de pages affichent calcul local, zéro envoi, bout en bout. Ces mots peuvent figurer sur un outil qui termine vraiment le travail sur cet appareil, ou sur une page qui POSTe d’abord le texte d’origine pour qu’un serveur le chiffre. La phrase n’a pas de somme de contrôle.
Ce que vous pouvez voir sur place : la méthode, l’adresse, la chaîne de requête et le corps envoyés par cet onglet. Le panneau Network de Chrome les liste. Si le nom du fichier que vous venez de choisir, le mot de passe que vous venez de saisir, ou un texte d’essai que vous seul connaissez apparaît à ces endroits, le « chiffrement local » n’a pas tenu pour cette opération.
L’inverse est tout aussi étroit : l’absence de texte en clair dans le panneau signifie seulement que les requêtes observées n’ont pas emporté ces champs. Cela ne dit pas que la mémoire n’en contenait pas, ni qu’une extension n’a pas lu le champ de saisie. Transformer le marketing en une observation reproductible suffit déjà : vous pouvez dire à un collègue « j’ai cherché le canari ; la ligne de requête et le corps sont propres », plutôt que de relayer une phrase du site.
N’utilisez pas une vraie clé, un numéro de pièce d’identité ou un tableur non masqué pour l’essai. Préparez un petit fichier jetable, et un mot de passe long à usage unique. Vous vérifiez le trafic — pas besoin d’exposer à nouveau des données privées.
Ce que « local » désigne concrètement
« Local dans le navigateur » ne veut pas dire « ce nom de domaine a l’air sûr ». Cela signifie que le travail cryptographique a lieu dans l’environnement de script du document courant. Pour AES-256-GCM, le chemin correct habituel est crypto.subtle.encrypt : dérivation de clé, chiffrement et étiquette d’authentification passent tous par l’interface du navigateur. MDN indique que SubtleCrypto.encrypt n’est disponible que dans un contexte sécurisé — en production, c’est HTTPS. Sur une page HTTP ordinaire, crypto.subtle est souvent undefined.
AES-GCM n’a pas été choisi pour le nom. C’est un chiffrement authentifié avec contrôle d’intégrité : si le texte chiffré a été modifié, ou si la mauvaise clé est utilisée, le déchiffrement échoue au lieu de produire un « texte en clair qui ressemble à du bruit ». Dans les paramètres, l’IV fait souvent 12 octets (96 bits), conformément à la recommandation NIST SP 800-38D pour GCM. Chaque chiffrement doit utiliser un nouvel IV aléatoire, pour que le même texte en clair donne un texte chiffré différent.
Le cas fichier se décrit par des gestes concrets : vous choisissez un fichier local, le script le lit par blocs en mémoire, chiffre chaque bloc, puis déclenche le téléchargement du texte chiffré. Le .lock ou .enc téléchargé est un fichier produit sur cet appareil, pas un accusé du serveur. Si la limite d’un fichier est écrite à 5 GB, cela décrit la capacité de traitement en flux dans le navigateur ; cela ne veut pas dire qu’un hôte distant a reçu 5 GB de texte en clair.
Il faut aussi séparer « envoi métier » et « requêtes que la page émet de toute façon ». Un site d’outils prêt à l’emploi charge encore des styles, des scripts et des polices, et peut envoyer des statistiques de visite sans le contenu. Ces requêtes ne prouvent pas que « le fichier a été envoyé ». En revanche, si la query ou le corps d’une statistique contient le mot de passe que vous venez de saisir, un mot de passe à tester ou le texte avant masquage, c’est une autre affaire.
FastPwd formule cette frontière en une phrase que vous pouvez vérifier : le texte en clair et les clés de la génération de mots de passe, de l’audit de mot de passe, du nettoyage de confidentialité et du chiffrement/déchiffrement de fichiers restent dans le navigateur par défaut ; Burn-Link n’autorise que le texte chiffré à sortir, et la clé de déchiffrement se place dans le fragment # de l’URL. Le coffre de chiffrement découpe par blocs de 1 MB et dérive une clé AES-256 à partir du mot de passe avec PBKDF2 (100000 itérations, SHA-256), puis écrit .lock / .enc. Tous les outils sont prêts à l’emploi — aucun compte, aucun coffre de mots de passe. Une promesse n’est encore qu’une promesse. Ci-dessous, Network en fait une liste de contrôles.
Faire un contrôle canari dans Network
Préparez d’abord un marqueur qui n’apparaîtra pas dans un vrai travail. Le nom de fichier peut être canary-fp-20260825.bin, le mot de passe une longue phrase aléatoire, et le corps une ligne qui n’existe que pour cet essai. Le canari sert à la recherche : collez-le dans le filtre Network ; une occurrence est un échec.
Ouvrez DevTools, passez à Network, cochez Preserve log, et commencez le filtre sur All — ne laissez pas seulement XHR. Une requête annulée ou en 4xx peut déjà avoir emporté du texte en clair. Enchaînez ensuite une opération complète : choisir un fichier, saisir le mot de passe, cliquer sur chiffrer ou générer. Ne fermez pas le panneau à la fin.
- Collez la chaîne canari dans le filtre. Un hit en rouge : arrêtez-vous et lisez cette requête — ne vous rabattez pas sur « ça a l’air local ».
- S’il n’y a aucune occurrence, ouvrez les Fetch / XHR une par une et comparez la ligne de requête, la chaîne de requête et le corps. Styles, polices et scripts peuvent être ignorés.
- Filtrez à part les chemins analytics, puis ouvrez query et body. Le titre de page et le chemin peuvent apparaître ; le mot de passe que vous venez de saisir, un mot de passe à tester, le texte avant masquage et le contenu du fichier ne doivent pas y figurer.
Lire la ligne de requête
Le chemin dans l’URL complète et la query après le point d’interrogation méritent une lecture caractère par caractère. Un champ de localisation comme id peut apparaître ; un nom de fichier, un mot de passe, un mot de passe à tester ou la clé après # ne le doivent pas. Comparez toute la barre d’adresse avec la ligne de requête : si la partie après # est entrée dans la ligne de requête, l’implémentation a traité le fragment comme une query, ou un script l’a lue puis écrite dans une requête.
Lire le corps de la requête
Le payload POST / PUT est le deuxième endroit. Si le chiffrement de fichier prétend se terminer en local, le corps ne doit contenir ni les octets du fichier d’origine, ni le mot de passe. Burn-Link peut inclure un champ de texte chiffré — c’est une donnée sortante attendue ; vérifiez qu’elle ne ressemble pas au texte que vous venez de saisir. Si une page d’audit de mot de passe POSTe le mot de passe, que le but soit écrit « recherche de fuite » ou « calcul de force », il a déjà quitté cet appareil.
Regarder analytics à part
Les statistiques de visite sont souvent oubliées. Une API principale propre avec un rapport qui emporte tout le champ de saisie, et cette opération n’a toujours pas « laissé le texte en clair dans le navigateur ». En filtrant les chemins analytics, ne supposez pas que « le script d’analyse est inoffensif » — c’est une autre requête sortante, à contrôler comme une API métier. Les statistiques FastPwd passent par le tracker du site, et localhost n’envoie rien par défaut ; même ainsi, cherchez le canari et confirmez que le rapport ne contient ni mot de passe ni contenu de fichier.
Cochez Preserve log. Si la page navigue ou se recharge après le chiffrement et que la case n’est pas cochée, la première requête qui emportait du texte en clair peut déjà avoir disparu — et vous obtenez un faux « le panneau est vide ».
Retester hors ligne : les ressources statiques ne sont pas un envoi métier
Le second contrôle coûte peu. Laissez la page se charger entièrement, puis activez Offline dans Network — ou coupez le réseau système — et chiffrez ce petit fichier jetable. Si le téléchargement du .lock se termine quand même, ce chiffrement/déchiffrement n’a pas eu besoin d’une API en direct. C’est un signal fort pour « chiffrement local dans le navigateur », mais pas le seul.
Les faux échecs sont fréquents aussi : une police ou un script analytics qui passe au rouge sous Offline n’est pas un échec de chiffrement. Regardez s’il apparaît un nouveau POST métier après le clic sur chiffrer, et si le fichier résultat est déjà dans les téléchargements. Les faux succès existent aussi : un script peut mettre le texte en clair en file d’attente et l’envoyer après la reconnexion. Donc réussissez le test hors ligne, puis cherchez à nouveau le canari une fois en ligne.
Le point d’interrogation entre dans HTTP ; le dièse, par défaut, non
Une URL a deux parties souvent mélangées. La query après le point d’interrogation entre dans la ligne de requête HTTP ; serveurs, reverse proxies et journaux d’accès peuvent tous la voir. Le fragment après # reste par défaut dans le navigateur, pour que le script de la page courante le lise. La cible de la requête HTTP ne contient pas le fragment — c’est la convention de RFC 9110 sur les cibles de requête, et la raison pour laquelle URL.hash n’existe que côté navigateur.
Donc, si un lien de texte chiffré à usage unique place la clé dans #, lorsque le destinataire ouvre s.html?id={id}#{key}, le serveur n’est conçu pour voir que id, pas la clé. Ce n’est pas un protocole cryptographique supplémentaire — c’est le comportement par défaut du navigateur pour le fragment. Il a des limites : collez l’adresse complète dans un ticket, un chat de groupe ou une carte d’aperçu qui jette le hash, et la clé passe de « n’entre pas dans HTTP » à « apparaît sur l’écran et dans les journaux de quelqu’un d’autre ».
Le contrôle est tout aussi concret : créez un texte d’essai inoffensif dans Burn-Link et voyez si le corps de la requête de création ne contient que du texte chiffré ; sur la page de lecture, voyez si la requête du document et les API suivantes ne contiennent que id dans l’URL. Le contenu après # dans la barre d’adresse ne doit pas apparaître dans ces requêtes. La page de lecture est publique pour le destinataire — aucun compte.
| Où regarder | Entre dans HTTP ? | Ce qui compte comme réussi |
|---|---|---|
| Slogan de la page | Sans objet | Pas une preuve — utile seulement en contraste |
| Ligne de requête / query | Oui | Ni canari, ni mot de passe, ni clé de fragment |
| POST body | Oui | Pas de texte en clair ; Burn-Link n’autorise que le texte chiffré |
Fragment # de l’URL |
Non, par défaut | Dans la barre d’adresse, pas dans la ligne de requête |
| Statistiques de visite | Selon l’implémentation | Pas de texte en clair du champ de saisie |
| Chiffrer après Offline | Pas de nouvelle requête métier | Le texte chiffré se télécharge encore ; rechercher le canari une fois en ligne |
Ce que vous pouvez prouver — et ce que vous ne pouvez pas
La conclusion que ce contrôle soutient est étroite. L’écrire clairement la rend plus utile.
Cela peut soutenir : dans ce navigateur, cette version et cette opération, le texte en clair, le mot de passe et la clé de fragment n’ont pas quitté l’onglet comme donnée HTTP métier observée ni comme texte en clair analytics.
Cela ne peut pas soutenir : qu’aucun autre onglet ou extension ne lit le presse-papiers ; que le dossier Téléchargements sur le disque est sûr ; que le destinataire ne fera pas de capture d’écran du texte chiffré ; que l’audit de mot de passe a couvert un corpus de fuites sur tout le web. Si le contrôle ne fait que de l’entropie locale plus une liste Top publique de mots de passe faibles, il peut répondre « cela ressemble-t-il à un mot de passe faible courant », pas « il n’est jamais apparu dans une fuite ». Ce n’est pas une recherche Have I Been Pwned sur tout le web.
Ne le prenez pas non plus pour un test d’intrusion. Vous n’avez pas inspecté les WebSocket, le cache Service Worker, ni inversé un script minifié. L’objectif est de pouvoir expliquer à un collègue : j’ai ouvert Network, cherché un canari, et la ligne de requête et le corps sont propres. C’est plus proche d’une discussion d’ingénierie que de relayer « le site dit que rien n’est envoyé ».
Questions fréquentes
Si le chiffrement fonctionne encore hors ligne, cela prouve-t-il que rien n’a été envoyé ?
Cela prouve seulement que ce chiffrement/déchiffrement n’a pas eu besoin d’une API en direct. Les scripts déjà en cache sur la page peuvent encore envoyer plus tard, une fois reconnecté. Donc réussissez le test hors ligne, puis cherchez à nouveau Network avec le même canari une fois en ligne. Les deux étapes doivent passer pour que la conclusion tienne.
Si le panneau Network est vide, cette action était-elle sûre ?
Non. Un filtre laissé sur Img seulement, Preserve log décoché, ou une requête effacée lors d’une navigation peuvent tous produire un vide trompeur. Passez le filtre sur All, cherchez le canari, et ouvrez les rapports analytics à part. Un panneau vide est une observation ratée, pas une preuve de sécurité.
Si Burn-Link dépose le texte chiffré sur le serveur, est-ce encore du chiffrement local ?
Cela compte comme « le texte en clair se termine en local, puis le texte chiffré sort ». Le serveur ne devrait voir que le texte chiffré et un id de localisation ; la clé de déchiffrement se place après le dièse du lien et n’entre pas dans HTTP par défaut. Créer et lire ne demandent aucun compte. Ce qu’il faut vérifier : que le corps n’est pas du texte en clair, et que la ligne de requête ne contient pas la clé après #.
L’audit de mot de passe envoie-t-il le mot de passe à une base de fuites sur tout le web ?
L’audit de mot de passe FastPwd calcule la force sur cet appareil et compare à une liste publique intégrée de mots de passe faibles. Le mot de passe à tester n’est pas envoyé. Il repère les mots de passe faibles courants, mais ne peut pas prouver « jamais vu sur le web », et ce n’est pas une recherche à la manière de Have I Been Pwned. Cherchez le mot de passe comme canari dans Network pour vérifier cette affirmation.
Appliquer les mêmes étapes à un outil prêt à l’emploi
Si vous voulez vous exercer sur une page dont la frontière de calcul est écrite clairement, commencez par le coffre de chiffrement FastPwd. Ouvrez et utilisez-le, sans inscription. Choisissez un petit fichier sans vraie donnée privée, utilisez un canari comme mot de passe, chiffrez, et téléchargez un .lock. Surveillez Network en même temps : vous devriez voir des ressources statiques et éventuellement des statistiques de visite, pas le fichier d’origine ni le mot de passe comme champs métier. L’algorithme est AES-256-GCM, calculé dans Web Crypto ; un fichier unique ne dépasse pas 5 GB.
Burn-Link convient pour le second exercice : créez un texte d’essai inoffensif et confirmez que les données sortantes sont du texte chiffré ; la page de lecture est publique pour le destinataire, et la forme du lien est s.html?id={id}#{key}. Le nettoyage de confidentialité convient pour « le texte d’origine entre-t-il dans analytics » — les liens et le texte à masquer restent dans le navigateur, comme le décrit le produit ; c’est encore à vous de juger si le résultat nettoyé suffit.
Ces exercices ne visent pas à prouver qu’un site est « absolument sûr ». Ils visent à vous rendre familière la même série de contrôles. Sur n’importe quelle page qui prétend un chiffrement local, les étapes restent les mêmes : canari, Preserve log, ligne de requête, corps, analytics — et Offline si besoin.
Retenez trois choses pour le prochain contrôle. Premièrement, regardez le trafic, pas les slogans. Deuxièmement, le texte chiffré sortant est acceptable ; les clés et le texte en clair ne le sont pas. Troisièmement, après un changement de navigateur, de version ou de fonction, refaites la recherche canari. Seule une observation reproductible mérite d’entrer dans vos propres notes de sécurité.