Pourquoi le fragment # d'une URL n'apparaît pas dans les journaux serveur

Quand l'exploitation colle un mot de passe temporaire dans un chat, ou que l'assistance transfère une URL d'admin avec un token, la peur n'est souvent pas « l'autre personne le voit », mais « chaque saut intermédiaire peut garder une copie complète du lien ». Beaucoup en déduisent : dès qu'un secret apparaît dans la barre d'adresse, les journaux serveur en ont forcément une copie.

Une adresse complète se découpe en trois. Le protocole et l'hôte décident à qui le navigateur parle ; le chemin et les paramètres de requête après le point d'interrogation décident quelle ressource, et ces deux blocs apparaissent dans la ligne de requête HTTP. Les caractères après le dièse s'appellent fragment. Ils servaient d'abord à faire défiler le navigateur jusqu'à une ancre ; plus tard, les scripts côté client lisent aussi ce texte sur l'appareil via location.hash. Le serveur ne le reçoit pas, et ne devrait pas s'en servir pour le routage ou l'authentification.

Placer la clé après # n'invente pas un nouvel algorithme de chiffrement. Cela utilise une frontière d'envoi que les navigateurs respectent depuis longtemps : un même lien peut porter « un identifiant pour le serveur » et « une clé réservée à l'onglet actuel ». UsePwd Burn-Link s'appuie sur cette frontière. Pages de création et de lecture : ouvrez et utilisez, sans inscription de part et d'autre. Le serveur ne conserve que le texte chiffré ; texte en clair et clé ne partent pas dans le corps de requête par défaut.

C'est ainsi que fonctionne la norme URL depuis longtemps. Ce n'est pas une convention privée d'un site, ni « le serveur a promis de ne pas regarder ». Dans le tableau, « le serveur peut-il le voir » signifie : après terminaison TLS, l'origine ou un reverse proxy que vous contrôlez peut-il lire ce champ dans cette requête HTTP. Cela ne couvre ni un appareil compromis, ni une extension capable de lire la page, ni une capture d'écran enregistrée ailleurs.

À la création, l'onglet actuel utilise Web Crypto pour générer une clé aléatoire, chiffre le texte avec AES-256-GCM, puis remet le texte chiffré au serveur. L'identifiant renvoyé va dans ?id= ; la clé n'est ajoutée qu'après #.

La page de lecture est publique pour le destinataire. Quand il ouvre s.html?id={id}#{key}, le navigateur récupère d'abord le texte chiffré ou l'état auprès du serveur avec id, puis déchiffre avec la clé du fragment conservée localement. Une fois le nombre de lectures fixé à la création atteint, le serveur supprime le texte chiffré et le lien ne se lit plus. Le destinataire n'a pas non plus à s'inscrire. La page de lecture est un contexte temporaire de texte chiffré, pas une entrée d'index du site ; pour comprendre le produit, revenez à la page de création ou aux étapes de vérification de cet article.

Placer la clé dans le fragment règle la couche « journaux serveur et ligne de requête ». Cela ne règle pas « à qui vous avez envoyé le lien complet ». Chats, e-mails et systèmes de tickets conservent l'adresse entière que vous collez. Quiconque a le lien complet a à la fois l'identifiant et la clé. Burn-Link limite la durée de vie du texte chiffré côté serveur et le nombre de lectures, pas le fait que le destinataire capture ou transfère.

En quoi cela diffère d'un schéma en paramètres de requête

Certains liens à usage unique mettent les données de déchiffrement dans ?k=. C'est simple, mais chaque ouverture écrit la clé sur la ligne de requête : CDN, WAF et journaux d'accès de l'origine peuvent en garder une copie. Le schéma fragment ajoute un dièse, et en échange, même un hébergeur qui enregistre l'URL complète n'a pas la moitié qui déverrouille le texte chiffré. Le coût : vous devez rappeler au destinataire de copier le lien entier, pas seulement la partie avant le point d'interrogation ; sans ce qui suit #, la page de lecture peut récupérer le texte chiffré et ne peut pas le déverrouiller sur l'appareil.

C'est aussi pourquoi cet article ne présente pas Burn-Link comme un « gestionnaire de mots de passe » ni comme un coffre-fort récupérable. UsePwd n'a ni compte ni coffre, et ne peut pas retrouver un secret par utilisateur. Lien perdu, fragment tronqué ou lectures épuisées : le serveur ne peut pas restaurer le texte en clair pour vous. L'identité est expliquée dans À propos.

Si le secret n'a besoin que d'un nombre limité de lectures et que les deux parties peuvent ouvrir un navigateur, utilisez Burn-Link : le texte en clair est chiffré sur l'appareil, l'identifiant va dans ?id=, la clé après #, ouvrez et utilisez. Après création, comparez une fois dans le panneau Network : le corps POST est du texte chiffré, l'URL du GET n'a pas de fragment. Si vous avez besoin d'une conservation durable, d'une synchronisation multi-appareils ou d'une récupération, c'est hors de ce site : utilisez un gestionnaire de mots de passe dédié, et ne prenez pas UsePwd pour un système de comptes.

Si le secret ne doit entrer dans aucune page tierce, ne créez pas de lien : dites-le en personne, utilisez un support hors ligne, ou restez dans un canal de bout en bout que vous avez déjà. Le schéma fragment réduit « les clés dans les journaux serveur », pas « toutes les personnes qui voient un écran ». Distinguer ces deux couches évite de lire un article sur le fonctionnement des URL comme une garantie produit.

La force du mot de passe lui-même est une autre question. Générez un secret aléatoire de 6 à 128 caractères dans le générateur de mot de passe ; pour voir la force sur l'appareil et comparer à la liste publique de mots de passe faibles divulgués livrée avec la page, utilisez le contrôle de mot de passe. Ce n'est pas une recherche de fuites à l'échelle du web ; le secret testé n'est pas envoyé. Avant d'envoyer un lien ou le corps d'un ticket, utilisez le nettoyage de confidentialité pour retirer les paramètres de suivi ou faire du masquage. Ces pages, comme cet article : ouvrez et utilisez. À droite de la barre supérieure, seul le sélecteur de langue.