Si vous collez un lien à usage unique dans Slack ou WeChat, l’aperçu le brûle-t-il d’abord

L’exploitation colle un lien à usage unique dans un canal Slack. La carte s’ouvre, le titre porte le nom du site. Dix minutes plus tard, le destinataire ouvre et lit « Ce secret a été détruit ». Les deux côtés sont sûrs de n’avoir jamais vu le texte clair. Ce qui a touché le serveur en premier n’est souvent pas le doigt du collègue, mais le GET que Slack envoie pour un aperçu de lien.

Un texte précédent expliquait pourquoi la clé d’un lien unique va après # : la question était « l’hôte qui garde le texte chiffré voit-il la clé ». Ici, la question est plus étroite : l’aperçu peut-il consommer la lecture avant que quiconque clique. La clé reste après #. Créer et lire s’ouvrent sans compte. Le lien à usage unique de MyPassGen s’utilise tout de suite ; le nombre de lectures part de 1 et plafonne à 10. Ce n’est pas une visite guidée des boutons. On suit ce que vous voyez dans Réseau, dans la barre d’adresse et dans la fenêtre de chat.

L’autre dit détruit, vous n’avez pas cliqué

Un schéma à usage unique courant est : la première récupération emporte le texte chiffré, puis le serveur l’efface. Quand le nombre de lectures vaut 1, cette unique réponse est la dernière copie. Entre « créé » côté expéditeur et « détruit » côté destinataire, beaucoup de visites peuvent atterrir sans qu’une personne ait cliqué : aperçu de canal, scan de messagerie, passerelle d’entreprise qui réécrit l’URL puis la sonde.

Slack l’écrit dans la documentation produit. Unfurling links in messages indique : quand un utilisateur colle un lien, Slack récupère la page et y attache un aperçu. La page robots officielle nomme le robot qui fait cette récupération Slackbot-LinkExpanding 1.0 (+https://api.slack.com/robots), et précise : il prend le moins possible de la page (HTTP Range) pour extraire les balises oEmbed, Twitter Card et Open Graph. Si ces balises pointent vers une image, une vidéo ou un fichier audio, il récupère aussi ce fichier pour le contrôler. Slack Robots ajoute : les réponses pour une même URL sont mises en cache dans le service pendant environ 30 minutes ; Slack ne respecte pas robots.txt pour cette récupération, parce qu’elle agit pour la personne qui a déjà posté le lien — pas comme un crawler de site entier.

Une carte déjà visible dans le canal ne prouve donc que ceci : une machine qui n’est pas le destinataire a envoyé au moins une requête HTTP vers l’adresse collée. Elle ne prouve pas que le texte clair a été lu. Elle ne prouve pas que le texte chiffré a été compté comme une lecture. Pour savoir s’il est brûlé, il faut voir quelle couche cette requête a touchée.

Quel morceau d’URL l’aperçu envoie vraiment

Le lien complet que vous copiez a cette forme : …/s.html?id={id}#{key}. L’id après le point d’interrogation entre dans la ligne de requête HTTP. La clé après le dièse reste, selon le protocole, côté client. Voir RFC 3986 §3.5 et RFC 9110 §7.1 : l’URI cible exclut le fragment, parce que ce morceau est traité par le client. Un robot d’aperçu envoie un GET HTTP normal. Une ligne de requête licite est GET /fr/s.html?id=…. La clé après le dièse n’atteint pas la machine qui héberge le texte chiffré.

C’est aussi pourquoi un aperçu qui ne prend que le HTML ne peut en général pas déchiffrer. La page de lecture doit d’abord, par script, lire location.hash, puis demander le texte chiffré au serveur, puis le déchiffrer sur cet appareil avec AES-256-GCM. Le crawler d’aperçu n’a pas la clé du fragment — seulement un identifiant. Même s’il stocke tout le HTML de s.html, il n’y a pas de mot de passe dedans. La page de lecture est une landing noindex. Le HTML initial porte un titre générique. Le texte clair n’est écrit dans la page qu’une fois le script terminé.

Ce que le chat stocke est un autre objet. On a collé la chaîne entière, dièse et clé compris. La recherche du canal, la synchro des messages et la même conversation sur un nouveau téléphone rendent encore le justificatif complet. Placer la clé après # la tient hors du GET d’aperçu et hors des journaux serveur habituels. Cela ne la tient pas hors de l’historique de groupe. Pour une remise plus sensible, on peut couper l’identifiant et la clé sur deux canaux — plus bas.

Trois récupérations, une seule compte

RFC 9110 définit GET comme méthode sûre : l’envoyer ne doit pas avoir d’effet de bord destructeur. Récupérer une page seulement pour dessiner une carte ne devrait, selon cette sémantique, pas effacer le texte chiffré. Dans la pratique, un outil à usage unique qui traite « premier GET du document » comme une lecture laisse le robot d’aperçu brûler le secret avant le destinataire. La différence n’est pas le nom de la messagerie. Elle est à quelle requête le compteur est lié.

Classez les récupérations selon ce qu’elles peuvent exécuter. La première sorte prend le HTML initial, lit <title> et Open Graph, et ne lance aucun script de page. La description officielle de Link Expanding chez Slack appartient ici : extraire les métadonnées, puis récupérer les fichiers que ces balises nomment. Apple écrit dans Ensuring Beautiful Rich Links que la génération de rich links n’exécute pas JavaScript ; Open Graph doit donc vivre dans le code source. Les intégrations de canaux Discord naissent souvent de la même façon : Discordbot/2.0 lit le HTML initial, au lieu d’ouvrir un moteur de navigateur complet.

La deuxième sorte exécute le script de page, mais la requête n’a toujours pas de fragment. Les navigateurs headless et certains bac à sable d’entreprise sont ici. Ils peuvent faire tourner le JavaScript de la page de lecture et malgré tout ne pas lire location.hash. Sur ce site, « pas de clé » veut aussi dire « pas de récupération du texte chiffré ». La page reste sur « Lien incomplet ». Le compteur ne doit pas bouger.

La troisième sorte exécute le script et charge l’URL complète — dièse compris — dans un vrai environnement de page. Certains produits de protection de poste qui ouvrent « le lien que vous allez cliquer » dans une WebView locale, ou un aperçu qui charge entièrement la page sur l’appareil de l’expéditeur, peuvent atteindre « récupérer le texte chiffré et compter ». Le protocole n’exclut pas cette classe. Vous ne pouvez la reproduire qu’avec un lien de test sur le même canal.

Slack, WeChat, Teams et la messagerie

Slack est le chemin le plus simple à contrôler. La page robots publie un User-Agent. Avec la même chaîne, vous demandez la page de lecture et voyez si la réponse est du HTML statique, et si le compteur a bougé ensuite. Slack documente aussi le cache global d’environ 30 minutes : la même URL collée en peu de temps dans plusieurs canaux ne retouche pas toujours votre origine. Un titre de site sur la carte veut seulement dire : les métadonnées ou <title> ont été lus. Le titre par défaut de la page de lecture française est « Message autodestructif · MyPassGen ». Votre phrase de test n’y figure pas.

WeChat ne publie pas de page robots comme Slack. Vous ne pouvez donc pas lire les capacités d’un crawler interne comme un contrat. Ce que vous voyez tout de suite : une carte de titre apparaît-elle après le collage ; la page de lecture, après le clic du destinataire, montre-t-elle le clair, « Lien incomplet » ou « détruit ». Les cartes de ce type de messagerie se construisent encore souvent parce qu’un serveur récupère titre et extrait HTML — pas parce que le script de la page de lecture a d’abord tourné sur le téléphone du destinataire. Sans spécification publique, c’est le résultat de votre lien de test qui compte. « Une carte est là » n’est pas « le texte chiffré a été récupéré ».

En France, le troisième chemin est souvent la messagerie professionnelle. Microsoft décrit, sous Liens sûrs (Safe Links), que le courrier entrant peut analyser et réécrire les URL ; un clic est revérifié. Les adresses réécrites portent un préfixe du type safelinks.protection.outlook.com. Le scan à la livraison et le saut au clic peuvent tous deux renvoyer un GET vers la cible. Contrôlez deux endroits : le corps visible est-il déjà emballé, et après le clic la barre d’adresse tient-elle encore le morceau après #. Si la clé tombe pendant la réécriture ou la redirection, la page de lecture doit afficher « Lien incomplet », pas la phrase de test. Si l’URL complète — dièse compris — entre dans un bac à sable qui exécute le script, une lecture peut compter. Ne supposez pas que chaque passerelle « ne regarde que le HTML ». Les liens dans un canal Microsoft Teams peuvent prendre le même chemin ; la politique dépend du locataire. Pour WhatsApp, le principe est le même que pour WeChat : sans page robots publique, c’est le lien de test qui décide, pas la carte.

Quelles requêtes la page de lecture envoie

Quand la page de lecture de MyPassGen s’ouvre, le script fait deux étapes à la suite. D’abord, il interroge le statut pour l’identifiant : la réponse dit encore là, déjà détruit ou expiré, et elle n’augmente pas le compteur. Sans la clé après #, cela s’arrête ici ; la page dit « Lien incomplet ». Avec la clé, suit le GET du texte chiffré. Cette requête augmente read_count. Quand le nombre atteint la limite que vous avez fixée (1 par défaut, 10 au plus), le serveur efface le texte chiffré. L’ouverture suivante est « détruit ». L’expiration suit le TTL choisi à la création : 1 heure, 24 heures, 7 jours — ou seulement selon le nombre, sans TTL.

Un aperçu qui ne fait qu’un GET de s.html?id=…, et un scanner qui ne touche que le statut, ne consomment donc pas cette lecture. Ce qui compte, c’est la requête de texte chiffré émise par « le script de la page de lecture, qui a déjà la clé ». À la création, le navigateur chiffre sur cet appareil avec AES-256-GCM, un IV de 12 octets, texte clair au plus 32 Ko. Le serveur ne garde que le texte chiffré. La clé n’entre pas dans la ligne de requête. Comment contrôler l’algorithme et « le clair n’est pas envoyé » est dans Comment vérifier que le chiffrement dans le navigateur n’envoie pas le texte clair.

La page de lecture n’a pas de bouton « Révéler » à part. Si la clé est là, ouvrir l’onglet récupère le texte chiffré. Cela ne contredit pas « les crawlers d’aperçu ne prennent que le HTML » — ces crawlers n’arrivent en général pas jusqu’à la récupération. La contradiction est dans la troisième classe : l’URL complète atterrit dans un environnement qui exécute le script. Alors cela ressemble à une personne qui ouvre l’onglet, et un lien réglé à 1 est consommé. Le style de la carte ne dit pas la classe. Le statut le dit, comme dans la section suivante.

Ce qui reste après l’aperçu

Le même lien de test, lectures à 1 : après l’aperçu, l’expéditeur et le destinataire ne voient pas les mêmes objets. Le tableau parle de pages que vous pouvez ouvrir — pas de slogans.

Ne mélangez pas la quatrième ligne et la troisième. Si la clé a disparu, le destinataire n’ouvre pas — vous ouvrez encore avec le lien complet d’origine. Alors on n’a pas compté ; l’autre n’a qu’un morceau tronqué. Si la clé est encore là et que la page est déjà détruite, l’aperçu ou le scan a lu en premier. Dans le premier cas, renvoyer le morceau après le dièse suffit. Dans le second, il faut recréer. Il n’existe pas de copie en clair côté serveur, ni d’adresse de support qui récupère un secret déjà brûlé.

Vérifier sur place

Les étapes ci-dessous ne s’appuient sur aucune promesse de marque. Utilisez partout une phrase de test qui n’ouvre aucun vrai compte, par exemple orange-lake-7. Ne vous entraînez pas avec le mot de passe principal, une clé de production, ni un vrai lien à usage unique.

1. Ouvrez Usage unique, saisissez la phrase de test, expiration 24 heures, lectures à 1, générez le lien. Notez l’adresse complète ; la forme doit être s.html?id=…#…. Utilisable tout de suite, sans compte.
2. Copiez seulement le morceau avant le dièse. Depuis un terminal, envoyez une requête avec le User-Agent Slack, par exemple curl -A "Slackbot-LinkExpanding 1.0 (+https://api.slack.com/robots)" "https://mypassgen.com/fr/s.html?id=…". La réponse est le HTML de la page de lecture. Le titre ou le corps ne doit pas contenir la phrase de test. Cela prouve seulement « un document seul ne livre pas le clair », pas le vrai chat.
3. Ouvrez la même adresse — seulement l’id, pas la clé — dans le navigateur. Vous devez voir « Lien incomplet », pas l’original. Dans les outils de développement, onglet Réseau, cochez « Conserver le journal » : requête de statut oui, ensuite pas de GET réussi du texte chiffré.
4. Ouvrez tout de suite le lien complet (avec #) dans un second onglet. La phrase de test doit apparaître. Si l’étape 3 a déjà brûlé, l’implémentation ou un appareil au milieu compte aussi la visite sans clé — arrêtez ici, n’envoyez rien de vivant.
5. Créez un second lien de test, lectures à 1, et collez-le en entier dans un canal Slack que vous contrôlez, dans WeChat « Transfert de fichiers », un groupe de test WhatsApp, ou un canal Teams interne. Attendez la carte (ou l’absence de carte). N’ouvrez pas la page de lecture.
6. Après l’aperçu, ouvrez le même lien complet dans le navigateur de bureau. S’il se déchiffre encore, l’aperçu sur ce canal appartient aux deux premières sortes. S’il est déjà détruit, une récupération de la troisième sorte s’est glissée — ou un de vos appareils a préchargé la page avec la clé. Pour le prochain secret réel, recréez. Ensuite, écrasez le presse-papiers comme dans Après avoir copié un mot de passe, qui peut encore lire le presse-papiers. Ne mettez pas en favori une adresse qui contient encore #.

Pour Outlook ou Exchange, ajoutez une demi-étape : envoyez le lien de test à votre propre boîte professionnelle. Voyez si le corps arrive déjà comme une adresse Liens sûrs, et si après le clic la clé reste dans la barre d’adresse. Clé perdue : identifiant par mail, clé par téléphone. Brûlé : augmentez le nombre de lectures ou changez de canal. MyPassGen ne classe aucune passerelle à votre place. Ce qui compte, ce sont les fenêtres que vous venez d’ouvrir.

Quand le canal construit quand même une carte

La valeur 1 convient quand l’autre a le lien complet, l’ouvre tout de suite, et que le contenu doit ensuite disparaître. Canal, grand groupe, liste de diffusion avec cartes : faites d’abord passer le lien de test par la section précédente. Seulement si l’aperçu ne compte pas, envoyez le secret réel. Si le test a déjà brûlé, un nombre plus haut ne rend pas l’aperçu « sûr » : à 2, il reste une ouverture humaine. Si le scanner exécute à chaque fois le script avec la clé, il peut quand même vider le compteur.

La coupure plus robuste, ce sont deux canaux. Un message seulement s.html?id=… — l’aperçu obtient au plus un identifiant et un titre générique. L’autre — téléphone, en face, ou un second compte de messagerie — seulement le morceau après #. Sans les deux moitiés, pas de texte clair. C’est un usage, pas une découpe par défaut du produit ; la page de création délivre encore un lien complet, parce que la remise à une seule personne est plus simple ainsi.

Le mot de passe lui-même naît sur cet appareil, pas d’abord dans le groupe pour être effacé ensuite. Le générateur de MyPassGen, en mode aléatoire, fait 6–128 caractères, 16 par défaut ; en dessous de 8, un avertissement de faiblesse. Utilisable tout de suite ; le résultat n’est pas envoyé comme donnée métier. Un paquet de certificats ou un export de plus de 32 Ko n’a pas sa place dans le lien unique : passez par Chiffrer : AES-256-GCM en flux dans le navigateur, un fichier jusqu’à 5 Go, sortie .lock / .enc, phrase secrète à part. Le cloud ne stocke que le texte chiffré, voir Avant de déposer un fichier dans le cloud, qui peut lire le texte clair — et par quel canal envoyer la phrase secrète.

Une fois contrôlé « le lien complet se déchiffre-t-il encore après l’aperçu » et « l’historique tient-il encore le justificatif complet », vous pouvez répondre à la question de départ : un aperçu qui ne prend que le HTML ne brûle en général pas le lien à usage unique de ce site. Une récupération qui exécute le script et emporte # le fait. La carte elle-même ne donne pas la réponse. Le statut et la seconde ouverture la donnent.

Questions fréquentes

Le canal Slack montre déjà une carte. Le lien est-il mort ?

Pas forcément. Slack écrit que Link Expanding extrait les métadonnées et prend, via Range, le moins possible de la page. La carte prouve seulement : le HTML de la page de lecture a été récupéré. Rouvrez le lien complet : s’il se déchiffre, la lecture est encore là. S’il est détruit, recréez — ne rechargez pas la même adresse en boucle en espérant un retour.

WeChat n’a pas de page robots publique. Quelle phrase croire ?

Le résultat de ce lien de test. Une carte de titre veut seulement dire : un programme a lu un titre ou un extrait. Avant que le destinataire clique, ouvrez vous-même le lien complet : encore le clair — sur ce canal, l’aperçu n’a pas récupéré le texte chiffré. Déjà détruit — coupez sur deux canaux, ou envoyez en tête-à-tête.

Mettre 2 ou 3 lectures suffit-il contre l’aperçu ?

Cela laisse plus de créneaux « récupérer le texte chiffré ». Cela ne transforme pas l’aperçu en méthode sûre. Si le scanner exécute à chaque fois le script avec la clé, le compteur se vide quand même. D’abord, avec lectures à 1, voyez si l’aperçu appartient aux deux premières sortes. Si vous devez utiliser un canal instable, augmentez ensuite et acceptez qu’une personne de plus puisse ouvrir.

Faut-il un compte pour créer et lire ? Le robot d’aperçu compte-t-il comme lecteur ?

Pas de compte. Créer et lire sont ouverts au visiteur. Si le robot ne prend que le HTML, ce n’est pas une lecture. S’il envoie le GET du texte chiffré, le serveur ne peut pas le distinguer d’une personne — le compteur baisse quand même. La page de lecture est ouverte au destinataire, sans barrière de connexion, et un secret déjà brûlé n’est récupéré par personne.