Retour au blog
ConfidentialitéTechnologie

Les liens éphémères sont-ils vraiment sûrs ? Analyse crypto 2026 de 4 méthodes

Publié le9 min read
Partager

Mise au point : « éphémère » n'est pas synonyme de « sécurisé »

Les liens burn-after-read (auto-destructibles après lecture) se répandent partout — pour transmettre des mots de passe, partager des photos sensibles, etc. Beaucoup les considèrent comme la définition même de la sécurité. Or, ce que vous ignorez peut-être : l'implémentation varie énormément d'un service à l'autre, et certaines ne garantissent en rien que vos données soient réellement détruites.

On décortique ici les trois grands modèles d'implémentation, leur solidité cryptographique, et leurs failles. De la CNIL à l'ANSSI, on a les outils pour évaluer ça proprement.

Trois modèles d'implémentation

Modèle 1 : suppression serveur pure (Token-Based)

Le modèle le plus répandu, aussi le plus naïf :

  1. L'utilisateur upload son contenu, le serveur stocke les données brutes et génère un token unique (UUID ou chaîne aléatoire)
  2. Le serveur renvoie un lien contenant le token (https://example.com/view/abc123)
  3. Premier visiteur : le serveur sert le contenu et marque le token comme consommé
  4. Visiteurs suivants : message « expiré »

Analyse sécurité :

Problème fondamental : le serveur détient les données en clair. Avant la « destruction », les acteurs suivants peuvent accéder à l'original :

  • Administrateurs serveur
  • DBA
  • Attaquant ayant pris le contrôle
  • Système de sauvegarde (les données « supprimées » peuvent traîner dans les backups)
  • Réquisition judiciaire ou administrative

Pour tout dire, la « suppression » en informatique moderne = marquage comme réécrivable. Les données restent physiquement présentes jusqu'à réécriture effective. Le TRIM sur SSD et les résidus magnétiques sur HDD sont des vecteurs de récupération documentés.

Modèle 2 : chiffrement client (Zero-Knowledge)

Le modèle le plus robuste. Représentants : PrivNote, Firefox Send (arrêté).

  1. L'utilisateur tape son contenu dans le navigateur
  2. Le navigateur génère une clé AES-256 aléatoire
  3. Chiffrement côté navigateur avec cette clé
  4. Upload du texte chiffré vers le serveur
  5. Le serveur stocke le chiffré, mais ne connaît pas la clé
  6. La clé est attachée au fragment d'URL (la partie après #)

Ex : https://example.com/view/abc123#clef-de-chiffrement

Design cryptographique clé : le fragment (après #) n'est jamais envoyé au serveur. Le serveur ne voit que le chiffré, ignore la clé, ne peut pas déchiffrer. C'est la Zero-Knowledge Architecture.

Côté destinataire :

  1. Navigateur récupère le chiffré depuis le serveur
  2. Extrait la clé du fragment URL
  3. Déchiffre localement
  4. Serveur supprime le chiffré

Analyse sécurité :

Même si le serveur est compromis, l'attaquant ne récupère que du chiffré inutilisable. Mais il reste des vecteurs :

  • Extensions de navigateur : une extension malveillante peut lire l'URL complète (fragment compris)
  • Historique navigateur : l'URL avec la clé peut être enregistrée localement
  • Fuite via Referrer : certains navigateurs anciens fuitaient le fragment dans Referrer (corrigé depuis)
  • Attaque chaîne d'approvisionnement JS : si le code JS de chiffrement est modifié, la clé peut être exfiltrée vers un attaquant

Modèle 3 : hybride

Combine contrôle serveur et chiffrement client :

  1. Chiffrement client (comme modèle 2)
  2. Restrictions serveur (token usage unique + mot de passe d'accès + expiration)
  3. Double authentification (mot de passe avant d'accéder au chiffré)
  4. Serveur supprime après consultation + journal d'audit (sans le contenu)

Meilleur équilibre sécurité / ergonomie.

Modèle de menace : ce contre quoi ça ne protège pas

Quelle que soit l'implémentation, les liens éphémères ne bloquent pas :

Captures d'écran et enregistrement d'écran

Fatalité ultime. Dès que le contenu est affiché, rien n'empêche une capture, une photo, ou un enregistrement vidéo. Certains services tentent de bloquer le clic droit ou les raccourcis — mesure purement cosmétique, contournable techniquement, inefficace face à un utilisateur averti.

Cache CDN et proxies

Si le contenu passe par un CDN, les nœuds edge peuvent garder une copie cachée. Même après suppression côté origine, le cache CDN conserve selon son TTL. Piège classique.

Bonne pratique : Cache-Control: no-store, no-cache, must-revalidate + CDN-Cache-Control: no-store.

Cache navigateur

Le navigateur peut stocker le contenu déchiffré sur disque local. Les images surtout — le cache image est souvent indépendant du contrôle de cache de page.

Surveillance réseau (man-in-the-middle)

En token pur (modèle 1) sur HTTP non chiffré, n'importe quel intermédiaire (FAI, pare-feu d'entreprise, hotspot Wi-Fi malveillant) lit le contenu en clair.

Même en HTTPS, les dispositifs SSL Inspection en entreprise déchiffrent et journalisent le trafic. Le chiffrement client (modèle 2) résiste : même si HTTPS est cassé, l'attaquant ne voit que du chiffré.

Logs serveur

Même si le contenu est supprimé, les logs d'accès peuvent garder URL, IP, timestamp, User-Agent. En modèle token, ces logs permettent de reconstruire « qui a accédé à quoi, quand, depuis où ».

Comparatif des services populaires

Selon la doc publique et l'analyse du code open source (mars 2026) :

Service Mode chiffrement Open source Stockage clé Serveur lit en clair Mot de passe Fichier max
PrivNote AES client Non Fragment URL Non (zero-knowledge) Non Texte
1ty.me Serveur Non Serveur Oui Optionnel Texte
Snappass (Pinterest) AES serveur Oui URL path Oui (clé passe par serveur) Optionnel Texte
hat.sh XChaCha20 client Oui Fragment URL Non (zero-knowledge) Non Fichier
OnionShare Client + Tor Oui Local Non Optionnel Fichier
Yopass OpenPGP client Oui Fragment URL Non (zero-knowledge) Non Texte + fichier
Lufi (YunoHost FR) Client Oui Fragment URL Non Optionnel Fichier

Honnêtement, l'open source est un indicateur majeur de confiance. Un service fermé peut claimer du chiffrement client sans qu'on puisse vérifier. Un service open permet à la communauté technique (ANSSI, associations comme La Quadrature du Net, chercheurs académiques) d'auditer.

Usage responsable : quand et comment ?

Scénarios adaptés

  • Transmission d'un mot de passe ou d'un token d'accès unique
  • Partage d'une info sensible à durée de vie courte
  • Communication qu'on ne veut pas voir traîner dans un historique de chat

Scénarios inadaptés

  • Informations confidentielles stratégiques (utiliser la messagerie chiffrée bout-en-bout type Signal, Olvid)
  • Contenu nécessitant une non-répudiation juridique (une fois détruit, impossible à produire en justice)
  • Secrets d'État (transmission hors ligne uniquement)

Recommandations pratiques

  1. Privilégier le chiffrement client — le serveur ne doit pas pouvoir lire
  2. Privilégier l'open source — auditabilité des affirmations de sécurité
  3. Ajouter un mot de passe — intercepté sans le mot de passe = inexploitable
  4. Canaux séparés pour le lien et le mot de passe — lien par email, mot de passe par Signal par exemple
  5. Éviter le réseau d'entreprise pour du très sensible — SSL Inspection omniprésent

La protection par mot de passe de lpic.cc

Dans le cadre du partage d'images, lpic.cc propose une protection par mot de passe : à l'upload, vous définissez un mot de passe, seules les personnes qui le connaissent peuvent consulter.

Honnêtement, il faut poser le cadre : la protection par mot de passe de lpic.cc relève du contrôle d'accès serveur (modèle 1), pas du chiffrement zero-knowledge client (modèle 2). Concrètement :

  • Le serveur détient les données image brutes
  • La fonction relève du contrôle d'accès, pas du chiffrement bout-en-bout
  • Adapté aux besoins quotidiens « éviter que n'importe qui tombe sur le lien »
  • Pas adapté aux scénarios nécessitant une garantie cryptographique forte

Pour le quotidien — éviter qu'une image circule au-delà de vos destinataires — c'est pratique et efficace. Pour du niveau militaire ou médical, passez par des outils end-to-end dédiés.

Cadre légal français

Quelques mots sur le contexte français, utile pour les RSSI et DPO :

  • Loi Informatique et Libertés + RGPD : la protection par mot de passe n'équivaut pas à une mesure technique de chiffrement au sens de l'art. 32 RGPD. Pour une donnée sensible (au sens art. 9), le chiffrement bout-en-bout est quasi obligatoire.
  • ANSSI publie un guide « Recommandations pour la sécurisation d'un site web ». Section 3 couvre le chiffrement de données sensibles partagées.
  • CNIL recommande explicitement le chiffrement de bout-en-bout pour le partage de données personnelles, et considère les services type PrivNote ou Yopass comme acceptables si le canal de transmission du lien est sécurisé.

FAQ

Q1 : Après consultation, les données sont vraiment irrécupérables ?

Ça dépend du modèle. Mode serveur pur : les données peuvent subsister dans les backups, le cache CDN, ou des blocs disque non réécrits. Mode chiffrement client : même si le chiffré n'est pas totalement effacé, la destruction de la clé (URL disparue) rend le chiffré irrécupérable cryptographiquement. Mais ce qui est déjà affiché à l'écran du destinataire, ça, on ne peut pas le rappeler.

Q2 : Le mode navigation privée améliore-t-il la sécurité ?

En partie. Pas d'historique, pas de cookies, pas de cache — donc l'URL avec la clé ne traîne pas sur la machine. Mais ça ne protège pas contre la surveillance réseau (FAI, firewall entreprise) ni contre les captures d'écran.

Q3 : Les compteurs d'auto-destruction sont-ils utiles ?

Effet sécuritaire faible. C'est juste du JavaScript qui efface le contenu après X secondes. Tout le monde peut capturer avant, ou ouvrir les DevTools et stopper le timer. La vraie valeur est psychologique — rappeler au destinataire que le contenu est sensible.

Q4 : Un lien éphémère empêche-t-il le transfert ?

Non. Si le destinataire transmet le lien avant de l'ouvrir, quelqu'un d'autre peut l'utiliser à sa place. La protection par mot de passe aide (il faut transmettre les deux), mais rien n'empêche une capture d'écran post-lecture.

Q5 : Sur le réseau de mon entreprise française, transmettre un mot de passe via lien éphémère, c'est sûr ?

Mieux que du clair, oui, mais attention. Beaucoup d'entreprises (surtout grandes et réglementées — banques, assurances, santé) déploient du SSL Inspection. L'IT peut voir le trafic HTTPS. Avec un service à chiffrement client, même si TLS est cassé, l'IT ne voit que du chiffré. Recommandation : Yopass ou hat.sh auto-hébergés, ou Olvid pour les échanges internes très sensibles.

Références

#burn after read#lien éphémère#cryptographie#sécurité données#confidentialité
K

Rédigé par

Kevin Wu

Consultant en sécurité

Spécialiste de la confidentialité et de la sécurité des données — pour vous aider à éviter les pièges cachés du partage d'images.