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, vous le collez donc dans le premier que Google vous donne. Je l'ai fait pendant longtemps sans y penser - jusqu'au jour où j'ai regardé ce que je viens de coller. c'était un client 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 mal ne s'est produit, pour autant que je sache. C'est la partie troublante - je n'ai aucun moyen de le savoir. Il n'y a aucune notification pour "votre pâte a été enregistrée. Les données étaient soit dans les journaux d'accès de quelqu'un, soit elles ne l'ont pas fait, et je ne découvrirai jamais lequel.
Cet incident est une grande partie de la raison pour laquelle Toolz.dev fonctionne comme il le fait. Chacun des 50 outils du site traite votre entrée dans votre navigateur. Non "Nous vous promettons de le supprimer après le traitement" - 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 n'importe qui d'autre, et comment vérifier vous-même les revendications d'un outil en 30 secondes. Et, comme 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 à la machine de quelqu'un d'autre, où elles peuvent être enregistrées, conservées, violées ou partagées - et vous ne pouvez en vérifier aucune. Les outils côté client vous envoient le code et traitent tout localement. La vérification nécessite une vérification de l'onglet du réseau DevTools. Pour tout ce qui contient des informations d'identification — JWT,
wp-configValeurs, chaînes de connexion, réponses de l'API : utilisez des outils côté client tels que 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 une fois l'outil JavaScript de l'outil, puis tout, entrée, traitement, sortie, se produit dans un onglet de 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 énumériez ce qui peut arriver aux données sur un serveur que vous ne contrôlez pas. Il peut atterrir dans les journaux d'accès et les journaux d'application. Il peut être capturé par des traqueurs d'erreurs tels que Sentry, qui demandent un snapshot contexte lorsque quelque chose est lancé. Il peut être conservé dans les sauvegardes longtemps après que l'opérateur "supprimé" Il peut être lu par n'importe quel employé ayant accès au journal. Il peut être balayé dans une brèche. Et avec plusieurs "outils gratuits" d'outils, il peut s'agir du produit réel - monétisé par l'analyse 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. Vous déboguez une intégration, vous copiez l'intégralité de la réponse - en-têtes inclus - et formatez-la pour la lire. celui Authorization: Bearer ... L'en-tête vient d'aller partout où vit le formateur. GitGuardian's État des secrets s'étaler Les recherches ont révélé environ 12,8 millions de secrets exposés au public GitHub. Personne ne publie des nombres équivalents pour les outils en ligne, car contrairement à GitHub, les opérateurs d'outils ne sont pas scannables publiquement. Ce n'est pas rassurant, cela signifie que la surface de fuite est invisible.
JWT. Un jeton Web JSON est codé en base64URL, non chiffré — 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 sont disponibles. J'ai validé les fichiers YAML contenant tous les secrets de mon application Laravel. C'est un collage que vous souhaitez passer par un côté client Validateur de YAML, pas un message de formulaire.
Données WordPress sérialisées. Ma chute personnelle, selon l'introduction. WordPress stocke les options et les métadonnées sous forme de chaînes de PHP, et les déboguer signifie les désamorcer — 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.
- Ouvrez la page de l'outil.
- Ouvrir les outils de développement (F12) → réseau Tab. Vérifiez "Préserver le journal."
- Coller certaines données de test reconnaissables —
MY-SECRET-TEST-12345fonctionne - et exécutez l'outil. - 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 demande se déclenche lorsque vous appuyez sur le bouton Convertir/Format/Processus, filtrez les requêtes et inspectez les charges utiles de votre chaîne de test. Vous l'avez trouvé ? côté serveur. Terminé - cela a pris une demi-minute, et vous en savez maintenant plus sur cet outil que sa politique de confidentialité ne vous le 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 réseau Check vous-même ; l'entrée n'apparaît jamais dans aucune requête. Deuxièmement, le côté client a une réelle limitation : votre navigateur fait le travail, donc un transcode vidéo de 4 Go n'est pas disponible dans un onglet. Pour la catégorie d'outils de formateur/convertisseur/encodeur, cependant, JavaScript moderne est plus que suffisamment rapide, généralement plus rapide que le côté serveur, car il n'y a pas du tout de transfert aller-retour.
Côté serveur ou côté client : la comparaison directe
| Outils côté serveur | Outils côté client | |
|---|---|---|
| Où le traitement se produit | Serveur d'opérateur | Votre navigateur |
| Données transmises ? | Oui, à chaque fois | Non, seul le code de l'outil est téléchargé |
| Peut être enregistré/gardé par l'opérateur | Oui, souvent par défaut | Non, l'opérateur ne le reçoit jamais |
| Exposé dans une violation de l'outil | Oui, si retenu | non |
| vérifiable par vous | Non, vous faites confiance à la politique | Oui — Onglet Réseau DevTools, ~30 secondes |
| Accord de transformateur du RGPD nécessaire | Oui, si données personnelles (art. 28) | Aucun traitement par un tiers ne se produit |
| Fonctionne hors ligne après chargement | non | Souvent oui |
| Vitesse pour les tâches de développement typiques | Télécharger + File d'attente + Télécharger | Instantané — Pas de réseau aller-retour |
| Calcul lourd (vidéo, fichiers énormes) | mieux adapté | Limité par votre appareil |
Que dit le RGPD à ce sujet ?
Je suis un développeur, pas un avocat, alors traitez cela comme un contexte d'ingénierie plutôt que comme un conseil juridique - mais le plan est important pour quiconque gère les données des utilisateurs européens.
en dessous Règlement (UE) 2016/679 (RGPD), si vous prenez des données personnelles - l'exportation d'un client, une réponse API avec des enregistrements d'utilisateurs - et que vous les faites passer par un serveur tiers, ce tiers traite des données personnelles en votre nom. L'article 28 dit que cela nécessite un accord de traitement des données. Demandez-vous combien de formateurs en ligne gratuits proposent un DPA. Je n'en ai jamais vu.
Les outils côté client évitent 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 vers le papier. La minimisation des données (article 5(1)c) est satisfaite de la manière la plus littérale possible, la quantité de vos données collectée par le fournisseur 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 de 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 le 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 vraiment besoin d'un outil côté serveur - une conversion lourde sans alternative locale - désinfectez d'abord. Échangez les clés réelles 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 l'histoire, en partie les incitations. En 2010, les navigateurs n'étaient pas à la hauteur des tâches, un traitement intensif 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 indissociables des API natives, et les API de navigateur (file, canevas, crypto Web) couvrent les E/S.
Les incitations sont le problème le plus sceptre. Le traitement côté serveur permet à un opérateur de voir l'utilisation en détail, de respecter les limites avec précision, de conserver 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 ne peut pas monétiser vos données, ce qui explique précisément pourquoi certains opérateurs ne veulent pas de l'architecture, même si elle est techniquement simple.
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 le journal de "Préserver", collez les données de test reconnaissables dans l'outil et traitez-les. Si aucune requête ne contenant votre chaîne de test ne se déclenche, l'outil est côté client. Sur Chrome, vous pouvez également passer à DevTools sur "hors ligne" 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, elles sont plus rapides - il n'y a pas de téléchargement, pas de file d'attente, pas de téléchargement. Le traitement d'un fichier JSON de 2 Mo localement est quasi-instantané, tandis qu'un aller-retour serveur ajoute de la latence à chaque étape. L'exception est le calcul lourd (grands transcodages vidéo, fichiers à l'échelle gigaoctet), où un puissant serveur bat un onglet de navigateur.
Toolz.dev collecte-t-il quelque chose ?
Le nombre d'analyses de pages et d'utilisation anonyme par outil (utilisé pour les limites de tarifs) - mais jamais le contenu que vous traitez. Les fichiers d'entrée, de sortie et de téléchargement restent dans votre navigateur. Ceci est vérifiable avec l'onglet Réseau plutôt que quelque chose que vous devez prendre en charge.
Coller un JWT dans un décodeur en ligne est-il vraiment risqué ?
Oui, plus que la plupart des développeurs ne le supposent. Selon la RFC 7519, les charges utiles JWT sont encodées, non chiffrées. Toute personne détenant le jeton peut lire les réclamations, et si le jeton n'a pas expiré, il peut être utilisable comme identifiant en direct. Le collage d'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 les sites que vous visitez, et non les types que vous tapez dans un outil côté client. Il n'y a aucune demande d'observation pour votre entrée. Endpoint Monitoring installé sur l'appareil lui-même (capture d'écran, keyloggers) 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 de terminaison.
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 de votre navigateur et l'exécutez-le. Les outils côté serveur expédient vos données à une machine que vous ne contrôlez pas et exécutez-la là-bas. Fonctionnellement, la sortie peut être identique - la différence est entièrement de savoir qui finit par conserver votre entrée. Avec un outil côté serveur, vos données existent, mais brièvement, sur le disque de quelqu'un d'autre, dans leurs journaux et dans leurs sauvegardes.
Les formateurs et les embellisseurs JSON en ligne sont-ils sûrs à utiliser ?
Cela dépend de la mise en œuvre, pas de la catégorie. Le formatage JSON est banal à 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 du réseau le règle en dix secondes. Soyez plus prudent que d'habitude ici, car les développeurs JSON collés dans des formateurs sont des réponses API disproportionnées contenant des jetons, des adresses e-mail et des ID internes.
