Sécurité chez Vaulted
Chiffrement zero-knowledge — on ne peut pas lire tes secrets, même si on le voulait.
Conçu et maintenu par Maxim Novak · [email protected]
Ne nous fais pas confiance — vérifie par toi-même
Chaque affirmation de cette page est observable depuis ton propre navigateur. Ouvre les DevTools, lance quatre tests rapides et confirme qu'aucun texte en clair ni aucune clé ne traverse jamais le réseau. Cinq minutes, aucun outil à installer.
Chiffrement AES-256-GCM
Chaque secret est chiffré dans ton navigateur avec AES-256-GCM, conformément à la spécification NIST SP 800-38D — le même standard utilisé par les gouvernements et les institutions financières du monde entier. Le chiffrement a lieu avant que la moindre donnée quitte ton appareil.
La clé ne quitte jamais ton navigateur
La clé de chiffrement est placée dans le fragment d'URL (la partie après #). Conformément au RFC 3986, les fragments d'URL ne sont jamais envoyés au serveur — ils n'existent que dans ton navigateur. Seule une personne disposant du lien complet peut déchiffrer le secret.
Architecture zero-knowledge
Notre serveur ne stocke que le texte chiffré et des métadonnées (nombre de consultations, expiration). On n'a aucun moyen de déchiffrer tes données — on ne voit jamais la clé, et on ne voit jamais le texte en clair. Même une compromission complète du serveur ne livrerait que des blobs chiffrés.
Protection optionnelle par phrase secrète
Pour une sécurité supplémentaire, tu peux définir une phrase secrète lors de la création d'un secret. La phrase secrète encapsule la clé de chiffrement — même si quelqu'un intercepte le lien, il ne peut pas déchiffrer le secret sans elle. Partage la phrase secrète par un autre canal (un appel téléphonique ou un message séparé, par exemple) pour une protection maximale.
Ce que le serveur stocke
Un blob chiffré, le nombre de consultations restantes et un horodatage d'expiration. C'est tout. Pas de journaux d'IP, pas de comptes utilisateurs, aucune analyse du contenu des secrets.
Suppression automatique
Les secrets sont supprimés définitivement lorsque la limite de consultations est atteinte ou que le délai d'expiration est dépassé. Il n'y a pas de corbeille, pas de sauvegarde, aucun moyen de récupérer un secret supprimé.
Ouvert par conception
La logique de chiffrement et de déchiffrement s'exécute entièrement dans ton navigateur via la Web Crypto API. Tu peux inspecter le code source, vérifier l'implémentation cryptographique et confirmer qu'aucun texte en clair ne quitte jamais ton appareil.
Ce contre quoi Vaulted protège
Écoute du réseau
Toutes les données sont chiffrées dans ton navigateur avant leur transmission. Même si le trafic réseau est intercepté, les attaquants ne voient que du texte chiffré AES-256-GCM — la clé de chiffrement ne traverse jamais le réseau.
Compromission du serveur
Vaulted utilise une architecture zero-knowledge. Le serveur ne stocke que le texte chiffré et des métadonnées. Il ne reçoit jamais la clé de chiffrement ni le texte en clair, donc une compromission complète du serveur ne livre rien d'exploitable.
Accès non autorisé
Les secrets sont protégés par des limites de consultations configurables, une expiration automatique (TTL) et une protection optionnelle par phrase secrète. Dès que la limite de consultations est atteinte ou que le TTL expire, le secret est supprimé définitivement.
Persistance des données
Les secrets sont supprimés automatiquement et définitivement du stockage une fois consommés ou expirés. Il n'y a aucune sauvegarde, aucune corbeille, aucun mécanisme de récupération.
Ce contre quoi Vaulted ne protège PAS
Navigateur ou appareil compromis
Si un logiciel malveillant a accès à ton navigateur, il peut lire le contenu déchiffré depuis le DOM après que tu as consulté un secret.
Enregistreurs de frappe
Un enregistreur de frappe sur l'appareil de l'expéditeur ou du destinataire peut capturer une phrase secrète au moment où elle est saisie.
Extensions de navigateur malveillantes
Les extensions ayant accès au DOM peuvent lire le contenu déchiffré d'un secret une fois qu'il est rendu dans le navigateur.
Partage ou capture d'écran par le destinataire
Une fois un secret déchiffré, le destinataire voit le texte en clair. Il n'y a pas de DRM — il peut le copier, le capturer en image ou le partager.
Interception du lien avant consultation
Si l'URL complète (y compris le fragment contenant la clé) est interceptée avant que le destinataire prévu ne l'ouvre, le secret est compromis.
Phrases secrètes faibles
Si une phrase secrète est utilisée et qu'elle est faible, un attaquant ayant accès à la clé encapsulée peut la casser par force brute.
Ce qu'on remettrait sur citation à comparaître
Une question fréquente des équipes sécurité et juridiques : si on y était contraint par une procédure légale, que pourrait réellement remettre Vaulted ? La réponse honnête est « pas grand-chose » — et c'est par conception, pas par politique. On ne peut pas partager ce qu'on n'a jamais reçu.
Ce qu'on conserve pour un secret donné
- Le texte chiffré AES-256-GCM, le compteur de consultations restantes et un horodatage TTL — stockés sous forme de hash Redis dans Upstash.
- Un sel d'encapsulation de clé optionnel si l'expéditeur a choisi une phrase secrète.
- Tout ce qui précède se purge automatiquement à l'expiration du TTL ou une fois le nombre maximal de consultations atteint. Aucune sauvegarde, aucune archive.
Ce qui n'est jamais stocké ni journalisé
- Le contenu en clair.
- La clé de chiffrement — elle ne vit que dans le fragment d'URL (après le
#), que les navigateurs n'envoient pas au serveur conformément au RFC 3986. - Les phrases secrètes (seul un sel non réversible est stocké).
- L'identité, l'e-mail ou l'empreinte d'appareil du destinataire.
- Les corps de requête, les corps de réponse ou les référents.
Ce qui est journalisé, brièvement
- L'IP du demandeur, utilisée uniquement par Upstash Ratelimit (fenêtre glissante) pour appliquer 10 créations/min et 30 consultations/min par IP. Conservée seulement aussi longtemps que la fenêtre de limitation l'exige.
- Les journaux d'exploitation standard de Vercel et Upstash (codes de statut, latences) — non liés au contenu des secrets.
Ce que les forces de l'ordre pourraient obtenir avec une procédure valide
Au mieux : un blob de texte chiffré opaque tant qu'il est encore dans sa fenêtre TTL, plus les métadonnées ci-dessus. Le blob est illisible sans la clé de déchiffrement — que nous n'avons jamais possédée et que nous n'avons aucun moyen de récupérer.
On n'a tout simplement rien d'utile à remettre.
Divulgation responsable
On prend la sécurité au sérieux. Si tu découvres une vulnérabilité, signale-la de façon responsable pour qu'on puisse la corriger avant qu'elle n'affecte les utilisateurs.
Ce qu'un signalement doit contenir
- Une description de la vulnérabilité et de son impact potentiel
- Les étapes pour reproduire le problème
- Tout code de preuve de concept ou capture d'écran
Périmètre
- Dans le périmètre : implémentation du chiffrement, contournement d'authentification, exposition de données, vulnérabilités côté serveur
- Hors périmètre : ingénierie sociale, déni de service, spam
On vise un accusé de réception des signalements sous 48 heures.
Envie de le voir en action ?
Essaie le Encryption Playground — une démo interactive du même chiffrement AES-256-GCM que celui utilisé par Vaulted. Ou lis notre guide visuel du chiffrement de bout en bout.