Sign X PDF · Guides
Comment vérifier si un site PDF téléverse votre fichier
Préparez un PDF de test sans caractère sensible, avec un nom de fichier et une marque textuelle uniques, puis observez le panneau Network lorsque vous l’ouvrez, le modifiez et l’exportez. Examinez Fetch/XHR, le corps des requêtes, Beacon, les WebSockets et l’activité des service workers. Une vérification propre permet seulement une conclusion limitée au navigateur et au parcours testés ; elle ne prouve pas ce qu’un appareil compromis ou une extension malveillante pourrait faire.
Ce guide propose une méthode pratique de vérification ; il ne constitue ni une certification de sécurité ni un avis juridique. Utilisez un fichier de test non confidentiel et définissez votre modèle de menace avant de vous appuyer sur un résultat.
Périmètre de la vérification : le code source du dépôt public et les composants open source ont été examinés le 8 août 2026. Le code publié est consultable, mais cette référence ne constitue pas une certification de sécurité indépendante. Les fichiers utilisés pour les tests du navigateur sont restés sur l’appareil de test et n’ont pas été téléversés vers les serveurs applicatifs de Sign X PDF. Il s’agit d’un élément de preuve limité, et non d’une garantie contre un appareil compromis, des extensions malveillantes, des services du système d’exploitation ou de futures modifications du code.
1. Créez un fichier de test identifiable
Ne commencez pas avec un document confidentiel. Créez un petit PDF contenant une marque unique, par exemple PDF-UPLOAD-CHECK-20260808-ALPHA, et donnez-lui un nom comme private-check-20260808-alpha.pdf. Cette marque aide à repérer les octets du document lorsque DevTools affiche le corps d’une requête.
Choisissez un fichier dont l’exposition ne pose pas de problème pendant le test. Le but est d’observer le chemin des requêtes, pas de risquer un vrai document client pour démontrer une propriété de confidentialité.
- Associez un nom de fichier unique à une marque textuelle unique.
- Gardez le fichier assez petit pour répéter et inspecter le test.
- Notez le navigateur, l’URL, l’opération et l’heure du test.
2. Observez le panneau Network avant de choisir le PDF
Ouvrez les outils de développement, sélectionnez Network, activez Preserve log et effacez les requêtes existantes. Commencez avec le filtre Fetch/XHR, puis répétez avec All, WS et les autres filtres utiles. Chargez la page et attendez la fin des requêtes normales pour le HTML, le JavaScript, les polices, les images et WebAssembly avant de sélectionner le fichier de test.
Les requêtes de ressources sont normales sur un site web. La question est de savoir si les octets du PDF sélectionné sont envoyés à un endpoint de téléversement, de conversion ou de stockage.
- Cherchez les requêtes POST ou PUT qui commencent après la sélection du fichier.
- Inspectez le payload, les champs form-data et multipart lorsque DevTools les affiche.
- Examinez les URL des requêtes, pas seulement le code d’état de la réponse.
- Répétez la vérification lors de l’export : certaines applications attendent ce moment pour envoyer le fichier.
3. Vérifiez plus que Fetch et XHR
Un filtre limité à Fetch/XHR peut masquer d’autres voies de communication. Vérifiez les appels Beacon, les messages WebSocket et l’activité des service workers lorsque le produit les utilise. Un service worker peut relayer une requête même si le code de la page ne lance pas directement un appel fetch.
L’absence d’une requête visible est un élément de preuve pour la session et le parcours observés. Elle ne prouve pas qu’aucun autre programme de l’appareil ne peut lire le fichier.
- Beacon : vérifiez les appels lors de l’enregistrement, de la navigation ou de la fermeture de la page.
- WebSockets : inspectez les messages à la recherche de la marque ou du nom du fichier.
- Service workers : vérifiez les enregistrements et l’activité réseau qu’ils peuvent relayer.
- Recherchez le nom et la marque uniques dans les détails visibles des requêtes.
4. Répétez l’opération et comparez la trace
Faites passer le même fichier par chaque opération pertinente : signer, fusionner, compresser, réorganiser et supprimer des pages. Répétez le test avec une deuxième marque. Des traces cohérentes sont plus utiles qu’un seul chargement propre, notamment lorsqu’une application charge son code à la demande.
C’est le principe utilisé par le test de confidentialité automatisé de Sign X PDF : installer des hooks réseau avant l’opération et détecter les motifs suspects de téléversement de document. La méthode publique montre ce qui est vérifié au lieu de demander de croire à un slogan.
- Testez l’ouverture comme l’exportation.
- Testez chaque opération importante pour votre modèle de confidentialité.
- Ne conservez un fichier HAR ou une capture que s’il est expurgé de toute donnée sensible.
Ce que cette vérification ne peut pas prouver
L’inspection réseau du navigateur n’audite ni un système d’exploitation compromis, ni un logiciel malveillant, ni une extension dangereuse, ni une autre application ayant accès au fichier, ni un déploiement futur. Elle ne suffit pas non plus à établir une conformité juridique ou la politique de conservation d’un fournisseur lorsque le comportement côté serveur est extérieur à la trace du navigateur.
Considérez le résultat comme une observation limitée et reproductible. Pour un parcours à haut risque, examinez aussi le code source, la politique de confidentialité, les conditions de conservation et le modèle de menace du fournisseur.
Comment nous l’avons vérifié
Méthode publique de vérification de la confidentialité
Result: Le test public installe des hooks pour les requêtes, Beacon, WebSockets et service workers avant d’exécuter cinq opérations PDF.
Scope: Signer, fusionner, compresser, réorganiser et supprimer des pages.
Limits: Il ne prouve pas le comportement d’autres applications, d’extensions malveillantes, de logiciels malveillants ou de futurs déploiements.
Source: https://www.signxpdf.com/en/verification/
Inspection Network du navigateur
Result: Les noms de fichiers et marques uniques fournissent des signaux répétables pour examiner les URL et corps de requêtes.
Scope: Méthode d’enquête manuelle décrite dans ce guide.
Limits: La visibilité dépend du navigateur et du comportement des service workers ; l’absence d’une requête ne constitue pas une garantie universelle.
Source: https://developer.chrome.com/docs/devtools/network/
FAQ
Un panneau Network sans anomalie prouve-t-il qu’un site PDF est privé ?
Non. Il étaye une conclusion sur la session et le parcours testés. Les logiciels malveillants, les extensions, le système d’exploitation, la conservation côté serveur et les changements futurs ne sont pas couverts.
Pourquoi utiliser un nom de fichier et une marque uniques ?
Ils permettent de repérer les octets du document dans les URL, les payloads, les données multipart ou les messages WebSocket sans utiliser un document confidentiel.
Sign X PDF effectue-t-il ce type de vérification ?
Oui. Son test public exécute les parcours de signature, fusion, compression, réorganisation et suppression de pages, puis surveille les requêtes, Beacon, WebSockets et service workers dans le périmètre indiqué.