← Tous les articles
Mis à jour le May 29, 20267 min read

Pourquoi vous ne devriez pas coller du JSON sensible dans des outils en ligne

Les tokens JWT, clés API, PII et exports de base de données sont régulièrement collés dans des formateurs en ligne. Voici ce qui arrive à ces données côté serveur — et pourquoi les outils navigateur sont le choix le plus sûr.

Un développeur tombe sur une erreur de parsing, copie le JSON de la réponse de l'API et le colle dans le premier formateur en ligne qui sort sur Google. Le JSON contient des IDs utilisateurs, des adresses e-mail, des tokens de session ou un fichier de configuration interne. Cela se produit des dizaines de fois par jour dans toutes les équipes d'ingénierie. Cet article explique précisément quels risques cela crée —— et pourquoi un outil natif du navigateur les élimine.

Quel type de données finit dans les outils JSON en ligne

En pratique, les développeurs collent ce qui leur cause un problème immédiat. Ça veut dire :

  • Tokens JWT —— contiennent des claims d'identité utilisateur, des rôles et une expiration. La signature empêche la falsification, mais le payload est du texte en clair encodé en Base64url : quiconque logue ton token peut lire chaque champ.
  • Réponses d'API avec PII —— noms, adresses e-mail, numéros de téléphone, dates de naissance, adresses. Une seule page de résultats de recherche d'une API client peut contenir des centaines d'enregistrements.
  • Fichiers de configuration —— chaînes de connexion à la base de données, clés d'API tierces, paramètres de feature flag, URLs de services internes.
  • Exports de base de données —— des dumps JSON de tables entières, parfois générés pour debugging et collés tels quels.
  • Données métier internes —— règles de tarification, conditions contractuelles, données de produits non sortis qui n'ont pas de classification publique mais restent sensibles.

Aucun de ces éléments ne paraît sensible sur le moment. Le développeur veut comprendre la structure, pas partager des données. Mais l'acte de coller dans un outil en ligne est indiscernable d'un envoi à un tiers.

Ce qui arrive quand tu soumets des données à un outil en ligne

La plupart des formateurs, validateurs et outils de diff en ligne fonctionnent en envoyant ton entrée à un endpoint serveur, en la traitant là-bas, et en renvoyant le résultat. Même les outils qui prétendent être « côté client » envoient parfois les données pour logging, analytics ou suivi d'erreurs. Voici ce qui peut arriver aux données sur ce chemin.

Logging côté serveur

Les serveurs web logguent les bodies de requête par défaut dans beaucoup de frameworks. Un seul POST de ton payload JSON peut finir dans :

  • Les logs applicatifs stockés sur disque ou dans un service de logging (Datadog, Splunk, CloudWatch)
  • Les outils de suivi d'erreurs (Sentry, Bugsnag) —— surtout si le parsing échoue
  • Une ligne en base dans une table « analytics » ou « usage »
  • Des logs d'accès CDN ou load-balancer que l'opérateur de l'outil ne surveille même pas forcément

Les politiques de rétention de logs varient énormément. Certains outils gardent les logs 90 jours, d'autres indéfiniment. Dans tous les cas, l'opérateur —— et toute personne accédant à leurs systèmes —— peut lire ce que tu as soumis.

Analytics tiers

Beaucoup d'outils en ligne incluent du JavaScript tiers pour analytics ou publicité. Ces scripts peuvent observer les requêtes réseau, les soumissions de formulaires et les événements d'entrée. Si un outil envoie tes données à son propre serveur, la couche analytics peut aussi voir la transaction HTTP.

Mise en cache et stockage CDN

Certains outils cachent les résultats indexés sur le contenu d'entrée. Si deux utilisateurs soumettent le même JSON, le second récupère une réponse cachée. L'entrée peut rester en cache pendant des heures ou des jours. Dans des cas pathologiques, des caches mal configurés ont rendu les soumissions utilisateurs publiquement accessibles via une URL prévisible.

Indexation par les moteurs de recherche

Les formateurs qui génèrent un permalink partageable (une URL contenant ou référençant ton JSON formaté) ont historiquement vu leur sortie crawlée par les moteurs de recherche. Chercher une chaîne distinctive d'un fichier de config interne et la trouver sur le domaine d'un formateur JSON est une expérience désagréable.

Exposition réglementaire

Si ton organisation traite des données personnelles sous GDPR, HIPAA, CCPA ou des cadres similaires, coller les données d'un utilisateur dans un outil en ligne tiers peut constituer un transfert de données non autorisé —— même si c'était accidentel et que l'outil est réputé. Le cadre ne distingue pas entre partage intentionnel et choix d'outils négligent. La question qu'il pose est : des données personnelles ont-elles quitté la frontière de traitement autorisée ?

Pour les entités couvertes par HIPAA spécifiquement, envoyer des informations de santé protégées à un service tiers qui n'a pas signé de Business Associate Agreement (BAA) constitue une violation à déclarer, que les données aient été détournées ou non.

En quoi les outils natifs du navigateur fonctionnent différemment

Les navigateurs modernes peuvent exécuter une logique complexe —— parsing, validation, diff, formatage, encoding —— entièrement dans le moteur JavaScript, sans aucune requête réseau. Un outil construit sur ce modèle se comporte comme une application locale qui se trouve être livrée via le web.

Quand tu colles du JSON dans un outil natif du navigateur :

  • Le texte va dans une variable JavaScript en mémoire de ton navigateur.
  • Un parser (aussi en JavaScript) le traite dans le même onglet.
  • La sortie est rendue dans le DOM.
  • Aucune requête HTTP n'est faite vers un quelconque serveur avec tes données en payload.

Les données ne quittent jamais ta machine. Elles ne peuvent être logguées, cachées ou indexées car elles n'ont jamais été transmises.

Comment vérifier qu'un outil est vraiment local

Les affirmations comme « nous ne stockons jamais vos données » sont courantes et invérifiables de l'extérieur. La seule vérification fiable est le panneau Network de ton navigateur :

  1. Ouvre les DevTools (F12 ou Cmd+Option+I).
  2. Va dans l'onglet Network et coche Preserve log.
  3. Colle ton JSON dans l'outil et déclenche l'opération (formater, valider, etc.).
  4. Filtre les requêtes par XHR/Fetch. Si une requête sortante porte ton entrée comme payload, l'outil n'est pas côté client.

Un outil réellement local ne montrera aucun POST ni fetch sortant portant tes données. Tu peux voir des requêtes pour des assets statiques (CSS, JS) ou des pings d'analytics, mais aucune ne contiendra ton payload JSON.

// Ce qu'un outil local fait —— pas d'appel réseau :
const result = JSON.parse(userInput);   // s'exécute dans le navigateur
render(result);                         // met à jour le DOM

// Ce qu'un outil côté serveur fait :
const res = await fetch('/api/format', {
  method: 'POST',
  body: JSON.stringify({ input: userInput }),  // tes données quittent la machine
});

Patterns pratiques : BAAs, WebCrypto et helpers de rédaction

Trois patterns ferment la plupart du risque restant :

  • Business Associate Agreements (BAAs) pour le travail proche d'HIPAA —— si ton équipe manipule des informations de santé protégées, tout service tiers qui y touche doit avoir un BAA signé. C'est pour ça que coller du PHI dans un formateur random, même un qui « tourne en local », est autant un problème de documentation qu'un problème technique.
  • WebCrypto côté client —— quand tu as vraiment besoin de hasher, signer, chiffrer ou générer des clés dans le navigateur, l'API standard crypto.subtle le fait sans aller-retour serveur. C'est la bonne primitive pour « déchiffre ce payload pour le regarder » sans envoyer le ciphertext nulle part.
  • Helpers de rédaction —— pour debug, passe le JSON par un petit rédacteur d'abord qui masque les valeurs aux clés connues comme sensibles (password, token, email, ssn) avant de coller n'importe où. Une fonction de vingt lignes vaut mieux que de découvrir des tokens dans le log de requêtes d'un outil d'analytics.

Politiques d'équipe qui valent la peine

La conscience individuelle a ses limites. Une politique légère couvre le manque :

  • Classifie avant de coller. Si le JSON contient des noms, e-mails, IDs, tokens ou clés —— c'est sensible. Utilise un outil local ou un outil interne approuvé.
  • Maintiens une liste d'outils approuvés. Une liste courte d'outils vérifiés local-first est plus facile à suivre qu'une règle générique de « fais attention ».
  • Ne partage jamais d'identifiants de production en debug. Fais tourner tout token ou clé qui a été collé dans un outil en ligne, même si l'outil paraît sûr.
  • Utilise des échantillons nettoyés pour debug. Remplace les valeurs utilisateurs réelles par des données synthétiques avant de coller. Une structure avec "email": "test@example.com" est tout aussi utile pour debug une erreur de parsing que l'adresse réelle.

Foire aux questions

Est-il sûr de coller du JSON sensible dans des outils en ligne ?

Seulement si l'outil traite tout dans ton navigateur. Les formateurs côté serveur peuvent logger, cacher ou indexer ton entrée —— et coller du PII chez un tiers peut en soi violer GDPR ou HIPAA, intention ou pas.

Comment vérifier qu'un outil JSON tourne en local ?

Ouvre DevTools → Network, coche « Preserve log » et lance l'opération. Si aucune requête sortante ne porte ton entrée en payload, l'outil est côté client. Les requêtes pour assets statiques et analytics sont OK ; un POST de ton JSON ne l'est pas.

Que faire si j'ai déjà collé un token dans un outil en ligne ?

Fais-le tourner. Traite tout identifiant ou clé qui a touché un outil tiers comme compromis, même si l'outil paraît réputé. Rappelle-toi qu'un token encodé en Base64 reste du texte en clair.

Comment mon équipe peut-elle éviter ça entièrement ?

Utilisez des outils natifs du navigateur, gardez une liste d'outils approuvés, et déboguez avec des données d'échantillon nettoyées ("email": "test@example.com") plutôt que des enregistrements réels.

Ce que fait fixjson.org

Chaque outil de fixjson.org —— réparation JSON, JSON diff, formateur YAML, JSON Stringify, encodage/décodage Base64 et décodage URL —— tourne entièrement dans ton navigateur. Le parser, le moteur de diff et les formateurs sont tous du JavaScript s'exécutant localement. Tu peux le vérifier dans l'onglet Network : aucune requête POST ne porte ton entrée.

Le site charge les assets statiques (HTML, CSS, JS) une fois depuis un CDN. Ensuite, il fonctionne hors ligne. Aucune entrée n'est envoyée à un serveur. Aucune donnée n'est logguée, stockée ou partagée.