Pourquoi les liens de partage publics sont dangereux
Par Simon Themiot - consultant cybersécurité freelance. Publié le 22 mai 2026.
En résumé
- Un lien « toute personne disposant du lien » est un jeton d'accès porteur : quiconque l'obtient reçoit les droits associés, sauf mot de passe ou authentification supplémentaire.
- Les liens peuvent fuir par l'historique, les extensions, la synchronisation, les journaux applicatifs, les captures d'écran, un mauvais destinataire ou une indexation accidentelle. Les fragments
#, eux, ne sont pas envoyés dans les requêtes HTTP ordinaires. - L'alternative : chiffrement E2E avec clé dans le fragment d'URL (non transmis au serveur) + mot de passe + expiration.
Sommaire
1. Comment fonctionne un lien de partage public
Quand vous créez un lien « toute personne disposant du lien », le service génère une URL contenant un jeton aléatoire. Sans option supplémentaire, la possession de ce jeton suffit pour obtenir les droits du lien. Un jeton long et imprévisible résiste bien à la devinette ; le risque principal est sa divulgation.
Il s'agit d'un modèle de lien-capacité, pas simplement de « sécurité par l'obscurité ». Il peut être adapté à un partage ponctuel peu sensible, à condition que le jeton ait assez d'entropie, que sa portée et sa durée soient limitées et que son canal de distribution soit maîtrisé.
2. Les vecteurs de fuite d'un lien
Historique de navigateur
L'URL est enregistree dans l'historique local. Si l'ordinateur est partage (poste en open space, ordinateur familial), n'importe qui peut retrouver le lien. Un malware de type info-stealer exfiltré systématiquement l'historique.
Logs du proxy d'entreprise
Un proxy, un CASB ou un agent installé sur le poste peut journaliser les URL selon sa configuration. Un proxy HTTP ordinaire ne reçoit jamais le fragment après # ; un agent navigateur ou une extension privilégiée peut toutefois voir l'URL complète affichée localement.
Extensions de navigateur
Les extensions Chrome/Firefox avec permission "accéder à tous les sites" voient toutes les URL que vous visitez. Plusieurs extensions populaires ont été prises en flagrant delit d'exfiltration d'historique de navigation vers des serveurs tiers.
Header Referer HTTP
Le header Referer peut révéler tout ou partie de l'URL de la page source selon la Referrer-Policy et le contexte. Les navigateurs n'y incluent pas le fragment. Une politique stricte comme no-referrer réduit ce canal de fuite pour les jetons placés dans le chemin ou la requête.
Copier-coller accidentel
Le lien est collé dans un canal Slack/Teams public au lieu du message privé prévu, ou il est envoyé au mauvais destinataire par email. Une fois divulgué, il peut rester actif tant qu'aucune expiration ou révocation ne l'invalide.
3. Incidents réels
- Mauvais canal : un lien destiné à un message privé est publié dans un canal collectif ou un ticket accessible à davantage de personnes.
- Compte compromis : l'historique de messagerie ou de courrier donne accès à tous les liens encore actifs.
- Journalisation excessive : un jeton placé dans le chemin ou la requête se retrouve dans des journaux applicatifs, outils d'analyse ou captures de diagnostic.
4. Le modèle sécurisé : clé dans le fragment
La spécification des URI définit que la partie "fragment" d'une URL (tout ce qui suit le caractère #) n'est pas envoyée au serveur dans la requête HTTP. Elle est traitée côté client.
PrivCloud exploite ce mécanisme pour ses liens E2E : la clé de déchiffrement est placée dans le fragment et n'est pas transmise dans la requête HTTP. Une compromission du stockage ne livre donc pas le contenu en clair, sous réserve que la clé, le navigateur et le JavaScript servi ne soient pas compromis.
Ce modèle n'élimine pas les fuites du lien complet : historique, extension ou destinataire peuvent encore révéler la clé. Le mot de passe optionnel ajoute une barrière d'accès serveur indépendante ; il doit être robuste et transmis séparément.
Défense en profondeur
- Clé dans le fragment (non transmise au serveur)
- Mot de passe supplémentaire (non présent dans l'URL)
- Expiration automatique (le lien cesse de fonctionner)
- Limite de téléchargements (désactiver le lien après X accès)
5. FAQ
Google Drive propose l'option "restreint" - est-ce suffisant ?
L'option "restreint" (seules les personnes ajoutées) est bien meilleure que "toute personne disposant du lien". Mais elle n'est pas E2E : le modèle ne prive pas Google de la capacité technique d'accéder au contenu. Elle impose aussi que le destinataire ait un compte Google, ce qui n'est pas toujours adapté aux clients, fournisseurs ou candidats.
Peut-on savoir si un lien public a été accédé par un tiers ?
La visibilité dépend du service et de l'offre. Pour un visiteur anonyme, un journal peut indiquer un accès sans fournir une identité fiable. La traçabilité affichée à l'administrateur doit donc être vérifiée avant de retenir un lien public pour des données sensibles.
Les raccourcisseurs d'URL ajoutent-ils un risque supplémentaire ?
Oui. Un raccourcisseur ajoute un intermédiaire qui voit chaque requête et devient une dépendance supplémentaire. Selon la longueur et l'aléa de l'identifiant, une URL courte peut aussi être plus facile à énumérer. N'utilisez pas ce mécanisme pour masquer un lien qui constitue à lui seul un secret d'accès.
À lire aussi
Partagez sans exposer
PrivCloud peut générer des liens E2E dont la clé n'est pas envoyée au serveur lorsque cette option est activée. Ajoutez un mot de passe robuste et une expiration pour réduire encore l'exposition. Aucun compte n'est requis pour le destinataire.
Cet article est fourni à titre informatif et ne constitue pas un conseil juridique. Dernière mise à jour : 14 juillet 2026.