Outils côté client et confidentialité des données : où va réellement votre pâte

Des années à faire le support des plugins WordPress m'ont appris une mauvaise habitude. Un client vous envoie un blob sérialisé en panne, vous devez le lire à présent(traduction), donc vous le collez dans le premier désérialiseur en ligne que Google vous donne J'ai fait ça pendant longtemps sans y penser - jusqu'au jour où j'ai regardé ce que I&#39 ; venait de coller C'était un client&#39 ; s wp_options Exporter. Il contenait leur mot de passe SMTP, une clé API Mailchimp et une clé de licence. Tout cela venait d'être posté sur un serveur dont je ne savais rien, dirigé par quelqu'un que je ne pouvais pas nommer, dans un pays que je ne pouvais pas deviner.

Rien de mauvais ne s'est produit, à ce que je sache. Cela&#39 ; est la partie troublante - je n'ai aucun moyen de le savoir. Là&#39 ; n'est pas une notification pour &quot ; votre pâte a été enregistrée.&quot ; Les données se trouvaient soit dans quelqu'un&#39 ; soit dans les journaux d'accès, soit dans le numéro 39 ; t, et I&#39 ; ne découvrira jamais lequel.

Cet incident explique en grande partie pourquoi Toolz.dev fonctionne comme il le fait. Chacun des 50 outils du site traite votre entrée dans votre navigateur. Pas &quot ; nous promettons de le supprimer après traitement&quot ; - il n'est jamais transmis en premier lieu. Ce guide explique la différence entre ces deux architectures, pourquoi cela compte plus pour les développeurs que pour presque tout le monde, et comment vérifier un outil&#39 ; s'affirme en 30 secondes environ. Et, puisque j'ai finalement collé ce blob client dans un endroit sûr, le PHP non-sérial Cela a remplacé ma mauvaise habitude.

tl;dr : Les outils côté serveur transmettent votre entrée à quelqu'un d'autre et à la machine n°39 ; s, où elle peut être enregistrée, conservée, violée ou partagée - et vous pouvez le vérifier n°39 ; t. Les outils côté client vous expédient le code et traitent le tout localement ; la vérification prend une vérification de l'onglet DevTools Network Pour tout ce qui contient des informations d'identification - JWT, JWTs, wp-config valeurs, chaînes de connexion, réponses API - utilisez des outils côté client comme le Formateur JSON, Décodeur JWT, Formateur SQL, et Validateur de YAML. Tout sur Toolz.dev s'exécute dans le navigateur.

Que se passe-t-il réellement lorsque vous collez dans un outil en ligne ?

Il existe exactement deux architectures, et chaque outil en ligne utilise l'une d'entre elles.

côté serveur : Votre entrée se déplace de votre navigateur vers le serveur de l'outil, y est traitée et le résultat remonte. Cinq étapes, et vos données existent sur l'infrastructure de quelqu'un d'autre au cours de trois d'entre elles.

Your browser → network → their server → network → your browser
   (input)     (transit)  (processing,    (transit)   (result)
                           logging?,
                           retention?)

Côté client : votre navigateur télécharge l'outil&#39 ; s JavaScript une fois, et puis tout - entrée, traitement, sortie - se passe dans un onglet sur votre machine La seule chose qui ait jamais traversé le réseau était le code.

Their server → your browser
   (code)       (input + processing + result, all local)

La distinction semble académique jusqu'à ce que vous listiez ce qui peut arriver aux données sur un serveur que vous faites & #39 ; t contrôle Il peut atterrir dans les journaux d'accès et les journaux d'application Il peut être capturé par des trackers d'erreurs comme Sentry, qui snapshot demande le contexte quand quelque chose lance Il peut être conservé dans les sauvegardes longtemps après l'opérateur &quot ; deleted&quot ; il peut être lu par n'importe quel employé avec un accès au journal Il peut être balayé dans une brèche Et avec plusieurs &quot ; outil libre&quot ; opérateurs, il peut être le produit réel - moné par l'à travers des analyses ou vendu comme données de formation.

Aucun de ces éléments ne nécessite de malveillance. Les configurations de journalisation par défaut en font la plupart. L'opérateur de ce Unserializer que j'ai utilisé n'a probablement jamais regardé le mot de passe SMTP de mon client. Mais "probablement" n'est pas une posture de sécurité.

Pourquoi est-ce plus important pour les développeurs que pour n'importe qui d'autre ?

A cause de ce que nous collés. Un utilisateur moyen colle un paragraphe de texte dans un compteur de mots. Un développeur colle :

Réponses API avec jetons Live. You&#39 ; re débogage d'une intégration, vous copiez l'intégralité de la réponse - en-têtes inclus - et la formatez pour la lire Cela Authorization: Bearer ... L'en-tête vient d'aller partout où vit le formateur. GitGuardian's État des secrets s'étaler une recherche a révélé environ 12,8 millions de secrets exposés dans les engagements publics de GitHub rien qu'en 2023 Personne ne publie de numéros équivalents pour les outils en ligne, car contrairement à GitHub, les opérateurs d'outils et n°39 ; les journaux sont et n°39 ; c'est pas rassurant - cela signifie que la surface de fuite est invisible.

JWT. Un JSON Web Token est codé en base64url, non crypté RFC 7519 est explicite à ce sujet. La charge utile de chaque jeton que vous collez dans un décodeur côté serveur transmet l'identifiant, le courrier électronique, les rôles et l'expiration de l'utilisateur. Si le jeton est toujours valide, vous avez potentiellement remis un identifiant de session de travail. décodez-les localement avec le Décodeur JWT à la place.

SQL contenant des données réelles. La requête que vous formatez a un WHERE email = '[email protected]' Clause dedans, et les noms de tables esquissent l'ensemble de votre schéma. le Formateur SQL Conserve cela dans votre onglet.

Fichiers de configuration. wp-config.php valeurs, .env Contenu, manifestes Kubernetes, database.yml- la configuration est l'endroit où les informations d'identification vivent. I&#39 ; j'ai validé les fichiers YAML contenant tous les secrets de mon application Laravel. C'est ça et n°39 ; c'est une pâte que vous voulez passer par le côté client Validateur de YAML, pas un message de formulaire.

Données WordPress sérialisées. Ma chute personnelle, selon l'intro. WordPress stocke les options et les métadonnées sous forme de chaînes sérialisées PHP, et les déboguer signifie les désérialiser - le PHP non-sérial Le fait sans les données de votre client qui quittent votre machine.

Une pâte négligente de l'une de ces catégories est un incident de sécurité que personne ne détectera, signalera ou nettoiera jamais.

Comment vérifiez-vous qu'un outil est en fait côté client ?

C'est la partie que j'aime le plus dans l'architecture côté client : Vous n'avez pas à faire confiance à la politique de confidentialité de qui que ce soit. La réclamation est vérifiable mécaniquement.

1. Ouvrez la page de l'outil.
2. Ouvrir les outils de développement (F12) → réseau Tab. Vérifiez "Préserver le journal."
3. Collez dans certaines données de test reconnaissables - MY-SECRET-TEST-12345 fonctionne - et exécutez l'outil.
4. Regardez la liste des demandes.

Si l'outil est côté client, vous verrez le chargement de la page initiale et les actifs statiques, puis nullité lorsque vous traitez Si une requête se déclenche lorsque vous appuyez sur le bouton convertir/format/processus, filtrez les requêtes et inspectez les charges utiles pour votre chaîne de test Trouvé ? côté serveur. Fait - cela a pris une demi-minute, et vous en savez maintenant plus sur cet outil que sa politique de confidentialité ne vous en dirait jamais.

Deux notes d'honnêteté sur Toolz.dev, car cela va dans les deux sens. Premièrement, le site charge l'analyse des comptes de pages et suit le suivi celui un outil a été utilisé - pour les limites d'utilisation - mais jamais quoi vous y mettez Exécutez le contrôle du Réseau vous-même ; l'entrée n'apparaît jamais dans aucune requête Deuxièmement, côté client a une réelle limitation : votre navigateur fait le travail, donc un transcode vidéo de 4 Go est & #39 ; cela se passe dans un onglet Pour la catégorie d'outils formateur/convertisseur/encodeur, cependant, le JavaScript moderne est plus que assez rapide - généralement plus rapide que côté serveur, car il n'y a pas de téléchargement aller-retour du tout.

Côté serveur ou côté client : la comparaison directe

Que dit le RGPD à ce sujet ?

I&#39 ; Je suis un développeur et non un avocat, alors traitez-le comme un contexte d'ingénierie plutôt que comme un conseil juridique - mais le plan compte pour quiconque gère les données des utilisateurs de l'UE.

en dessous Règlement (UE) 2016/679 (RGPD), si vous prenez des données personnelles - un client&#39 ; s support export, une réponse API avec des enregistrements utilisateur - et le pousser à travers un serveur tiers&#39 ; s, ce tiers traite des données personnelles en votre nom L'article 28 dit que nécessite un accord de traitement des données Demandez-vous combien de formateurs en ligne gratuits offrent un DPA Je n'en ai jamais vu.

Les outils côté client contournent toute la question, non pas par une rédaction juridique intelligente mais par l'architecture : aucune donnée n'atteint le fournisseur, il n'y a donc pas de traitement tiers à effectuer pour la paper minimisation Les données (article 5, paragraphe 1, point c) sont satisfaites de la manière la plus littérale possible - la quantité de vos données que le fournisseur collecte est nulle La même logique aide avec HIPAA (les données de santé n'atteignent jamais un serveur non conforme), les audits SOC 2 (pas de sous-processeur non vérifié dans le chemin des données), et PCI DSS.

Pour être clair : l'utilisation d'outils côté client ne permet pas Votre produit Conforme au RGPD. Il supprime une fuite spécifique et étonnamment courante dans votre flux de travail de développement - celle où un développeur, essayant d'être utile sur un ticket d'assistance, colle des données personnelles dans un site Web aléatoire.

Quelles tâches ne doivent jamais toucher un serveur ?

Mon triage personnel, trié par combien une fuite pourrait faire mal :

Jamais côté serveur - contient ou implique des informations d'identification :

• Formatage des réponses et des charges utiles à l'API : Formateur JSON
• Jetons de décodage : Décodeur JWT, Convertisseur de base64
• Requêtes de formatage : Formateur SQL
• Validation des configurations : Validateur de YAML
• Débogage des données WordPress : PHP non-sérial
• Hachage et comparaison des valeurs : générateur de hasch
• Génération d'informations d'identification : générateur de mots de passe, Générateur UUID

Préférez fortement côté client - propriétaire mais pas secret :

• Differ le code interne ou les contrats : Diff de texte, Diff JSON
• Tester la regex par rapport aux lignes de journal de production : testeur de regex
• Conversion des horodatages à partir des journaux et des jetons : Convertisseur d'horodatage
• Compression des captures d'écran internes : Compresseur d'images

Les enjeux faibles, mais le côté client est encore plus rapide :

• Compte de mots : compteur de mots
• Texte de l'espace réservé : Générateur de Lorem IPSUM
• Couleurs et dégradés : cueillette de couleurs, Générateur de gradient

Il y a une procédure pas à pas plus longue de la boîte à outils complète dans le Guide des outils de productivité des développeurs et le Guide des outils de codage.

Si vous avez réellement besoin d'un outil côté serveur - une conversion importante sans alternative locale - désinfectez d'abord. Échanger de vraies clés pour YOUR_API_KEY, de vrais e-mails pour [email protected]. C'est 60 secondes de recherche et de remplacement qui transforme un incident potentiel en non-événement.

Pourquoi la plupart des outils en ligne sont-ils côté serveur de toute façon ?

En partie historique, en partie incitatifs En 2010, les navigateurs étaient & #39 ; pas à la hauteur - un traitement lourd devait se produire sur un serveur Cette contrainte a disparu : les moteurs JavaScript modernes et WebAssembly gèrent le formatage, la conversion, le hachage et la compression d'images à des vitesses impossibles à distinguer des natives, et les API de navigateur (File, Canvas, Web Crypto) couvrent les E/S.

Les incitations sont le problème le plus collant Le traitement côté serveur permet à un opérateur de voir l'utilisation en détail, d'appliquer les limites avec précision, de garder la logique de traitement propriétaire et - dans le pire des cas - de traiter les données elles-mêmes comme des revenus Un outil qui ne reçoit jamais vos données can&#39 ; t monétiser vos données, c'est précisément pourquoi certains opérateurs don&#39 ; ne veulent pas de l'architecture même si it&#39 ; s maintenant techniquement facile.

Lorsque j'ai construit les outils pour Toolz.dev, le côté client était en fait le plus simple Choix d'ingénierie, pas seulement le plus privé : pas de serveurs de traitement à mettre à l'échelle, pas de téléchargements à Secure, aucune politique de rétention à écrire, et chaque outil fonctionne de manière identique dans l'application Web et dans l'application de bureau, car la logique est un type de script indépendant de la plate-forme. L'histoire de la confidentialité et l'histoire d'ingénierie pointent la même direction. C'est rare quand cela arrive ; remportez la victoire.

Questions fréquentes

Que signifie réellement "traitement côté client" ?

Tout le calcul se produit dans votre navigateur, en Javascript (ou WebAssembly), sur votre appareil. Le seul rôle du serveur est de fournir le code de l'outil lors du chargement de la page. Votre entrée n'apparaît jamais dans une requête réseau, que vous pouvez confirmer dans l'onglet Réseau DevTools.

Comment vérifier si un outil est côté client ?

Ouvrez DevTools (F12) → Onglet réseau, activez &quot ;Préserver le journal,&quot ; collez les données de test reconnaissables dans l'outil, et traitez-les Si aucune requête contenant votre chaîne de test ne s'allume, l'outil est côté client Sur Chrome vous pouvez également basculer DevTools sur &quot ; Offline&quot ; après le chargement de la page - un véritable outil côté client continue de fonctionner.

Les outils côté client sont-ils plus lents que ceux côté serveur ?

Pour les tâches typiques des développeurs, ils & #39 ; sont plus rapides - là & #39 ; n'a pas de téléchargement, pas de file d'attente, pas de téléchargement Le traitement local d'un fichier JSON de 2 Mo est quasi instantané, tandis qu'un aller-retour serveur ajoute de la latence à chaque étape L'exception est le calcul lourd (grands transcodes vidéo, fichiers à l'échelle du gigaoctet), où un serveur puissant bat un onglet de navigateur.

Toolz.dev collecte-t-il quelque chose ?

Analyses de la vue de la page et décomptes anonymes d'utilisation par outil (utilisés pour les limites de débit) - mais jamais le contenu que vous traitez Les fichiers d'entrée, de sortie et téléchargés restent dans votre navigateur Ceci est vérifiable avec la vérification de l'onglet Réseau plutôt que quelque chose que vous devez prendre en foi.

Coller un JWT dans un décodeur en ligne est-il vraiment risqué ?

Oui, plus que ce que la plupart des développeurs supposent Selon la RFC 7519, les charges utiles JWT sont codées, non cryptées - toute personne détenant le jeton peut lire les revendications, et si le jeton a expiré et n°39 ; t, il peut être utilisable comme identifiant en direct. En coller un dans un décodeur côté serveur transmet un jeton de session éventuellement valide à un tiers inconnu Utilisez un décodeur côté client.

L'utilisation d'outils côté client me rend-elle conforme au RGPD ?

Aucun choix d'outil unique ne vous rend conforme. Quels outils côté client suppriment est un risque spécifique : les données personnelles de vos systèmes atteignant un processeur tiers non contrôlé (ce qui nécessiterait un accord de traitement des données à l'article 28 que vous n'avez presque certainement pas avec un site d'outil gratuit). Les obligations de votre propre produit ne sont pas affectées.

Mon employeur peut-il voir ce que je traite dans les outils côté client ?

La surveillance du réseau voit quels sites vous visitez, pas ce que vous tapez dans un outil côté client - là&#39 ; n'est aucune requête portant votre entrée à observer La surveillance des points finaux installée sur l'appareil lui-même (capture d'écran, enregistreurs de frappe) voit tout quelle que soit l'architecture de l'outil, donc la réponse honnête est : pas via le réseau, éventuellement via le point final.

Et s'il n'y avait pas d'alternative côté client pour ma tâche ?

Désinfecter avant de coller : remplacez les informations d'identification par des espaces réservés (YOUR_API_KEY), échangez des données personnelles réelles contre des valeurs factices, supprimez les noms d'hôte et les URL internes. Vérifiez ensuite la politique de confidentialité de l'outil pour la journalisation et le langage de rétention, privilégiez les outils open source que vous pouvez inspecter et traitez "gratuit, fermé, côté serveur" comme la combinaison de risques les plus élevés.

Quelle est la différence entre les outils côté client et côté serveur ?

Les outils côté client expédient le code à votre navigateur et l'y exécutent ; les outils côté serveur expédient vos données à une machine que vous faites don&#39 ; t contrôlez et exécutez-la là Fonctionnellement la sortie peut être identique - la différence est entièrement de savoir qui finit par tenir votre entrée Avec un outil côté serveur vos données existent, même brièvement, sur quelqu'un d'autre&#39 ; s disque, dans leurs journaux, et dans leurs sauvegardes.

Les formateurs et les embellisseurs JSON en ligne sont-ils sûrs à utiliser ?

Cela dépend de l'implémentation, pas de la catégorie Le formatage de JSON est trivial à faire en JavaScript, donc un formateur côté client n'a aucune raison de transmettre quoi que ce soit - et la vérification de l'onglet Réseau le règle en dix secondes Soyez plus prudent que d'habitude ici, car les développeurs JSON collent dans des formateurs sont de manière disproportionnée des réponses API contenant des jetons, des adresses e-mail et des ID internes.