Comment vérifier que vos fichiers ne sont pas envoyés
Tous ces sites se disent confidentiels. Comment le vérifier concrètement ?
Partez de la bonne hypothèse
Une promesse de confidentialité sur une page commerciale n'est pas une preuve. Un cadenas, un badge ou une phrase dans une politique de confidentialité non plus : tout cela décrit une intention, alors que ce que vous voulez connaître, c'est un comportement. Heureusement, le comportement s'observe : tous les navigateurs embarquent des outils qui montrent exactement ce qu'une page envoie, et il n'est pas nécessaire d'être développeur pour les lire.
Faites ces vérifications sur ce site. Faites-les sur le site que vous utilisiez avant. L'objectif n'est pas de faire confiance à une autre promesse ; c'est de ne plus avoir besoin d'en croire aucune.
Vérification 1 : observez le panneau réseau
- Ouvrez les outils de développement. Sur la plupart des navigateurs de bureau, c'est F12, ou Ctrl+Maj+I, ou Cmd+Option+I.
- Sélectionnez l'onglet Réseau et assurez-vous que l'enregistrement est actif.
- Rechargez la page, puis videz la liste pour partir d'un journal vide.
- Choisissez votre fichier et lancez l'opération.
- Triez par taille, ou repérez dans la colonne Méthode les requêtes POST et PUT.
Ce que vous cherchez, c'est une requête dont la charge utile est de l'ordre de la taille de votre fichier, et toute requête, quelle qu'elle soit, vers un hôte qui n'est pas le site où vous vous trouvez. Un outil local affichera les requêtes correspondant à son propre code — scripts, feuilles de style, modules WebAssembly, éventuellement un fichier de modèle — puis plus rien pendant l'exécution du travail. Un service qui téléverse affichera, au moment où vous appuyez sur le bouton, une requête transportant plusieurs mégaoctets.
Vérification 2 : coupez le réseau
C'est la vérification la plus forte, et elle ne demande aucune compétence particulière. Chargez la page normalement, utilisez l'outil une fois pour que le moteur dont il a besoin soit mis en cache, puis déconnectez-vous : activez le mode avion, coupez le Wi-Fi ou utilisez le commutateur hors ligne des outils de développement. Traitez maintenant un fichier.
Si l'opération aboutit, le traitement n'a pu avoir lieu nulle part ailleurs que sur votre machine. Il n'y a plus d'ambiguïté à discuter. S'il échoue ou reste bloqué, c'est qu'un élément de la chaîne avait besoin d'un serveur — ce qui peut être légitime, par exemple un fichier de modèle pas encore mis en cache — mais vous savez désormais qu'il faut demander lequel.
Vérification 3 : lisez la politique de sécurité du contenu
Une politique de sécurité du contenu est un en-tête envoyé par le site et appliqué par le navigateur. Sa directive connect-src énumère les destinations auxquelles la page a le droit d'ouvrir une connexion. Si connect-src se limite à l'origine du site lui-même, le navigateur bloquera de lui-même toute tentative d'envoi ailleurs, quoi que tente le code de la page.
Pour la lire, ouvrez l'onglet Réseau, cliquez sur la requête du document — en général la première ligne — et cherchez l'en-tête de réponse Content-Security-Policy. Une politique contenant connect-src 'self' sans aucun hôte externe est une contrainte réelle, appliquée par le navigateur, pas une promesse.
Ce que prouve chaque vérification
| Vérification | Ce qu'elle prouve | Ce qu'elle ne couvre pas |
|---|---|---|
| Panneau réseau | Ce que cette page a envoyé pendant cette session | Un autre chemin d'exécution, une version ultérieure du site, ou une requête émise après que vous avez cessé de regarder |
| Test hors ligne | Le traitement lui-même s'exécute localement | Le fait qu'un envoi soit mis en attente et transmis dès la reconnexion |
| Politique de sécurité du contenu | Les destinations auxquelles le navigateur autorise une connexion | Tout ce que la politique autorise, y compris l'origine du site elle-même |
| Lecture du code source | Ce que contient le code livré | L'effort ; et il faut recommencer à chaque évolution du site |
Ensemble, elles sont solides. Prise isolément, chacune laisse une brèche, et quiconque vous affirme qu'une seule vérification règle la question simplifie à l'excès.
Les signes qu'un outil n'est pas local
- Une barre de progression dont la vitesse n'a aucun rapport avec votre appareil : régulière et identique sur un portable rapide comme sur un vieux téléphone.
- Un résultat livré sous forme de lien vers une URL de téléchargement sur leur domaine, plutôt que comme un fichier que votre navigateur détient déjà.
- Un message annonçant que les fichiers sont supprimés de leurs serveurs au bout de quelques heures. Cette phrase est un aveu que les fichiers y étaient.
- Une file d'attente ou une limite de débit. Votre propre processeur n'a pas de file d'attente partagée avec d'autres personnes.
- L'outil ne fonctionne réseau coupé que pour le premier petit fichier, puis s'arrête.
Les limites de la vérification
Une vérification vous renseigne sur la version du site que vous avez testée, le jour où vous l'avez testée. Un site peut changer demain. C'est pourquoi les vérifications qui comptent le plus sont les vérifications structurelles : une politique de sécurité du contenu restrictive et un test hors ligne concluant sont des propriétés de la façon dont l'application est construite, pas des promesses portant sur une version donnée.
Deux choses restent hors d'atteinte de toutes les vérifications de cette liste. Une extension de navigateur peut lire le contenu de n'importe quelle page, y compris le fichier que vous y avez chargé, et aucun site ne peut l'empêcher. Votre système d'exploitation voit tous les fichiers que vous ouvrez. Si un document est sensible au point que cela compte, traitez-le avec un logiciel hors ligne sur une machine que vous contrôlez, et considérez tout site web — celui-ci compris — comme le mauvais outil pour ce travail.
Outils pour cette tâche
Sources
- W3C — Content Security Policy Level 3
- MDN — Content-Security-Policy connect-src
- Chrome DevTools — inspect network activity
- MDN — Firefox Network Monitor