FAQ performance et sécurité : lent, saccadé et données non fiables

L'essentiel : diagnostiquez d'abord par symptôme — parsing, rendu ou mémoire — puis suivez l'ordre de correction : réduire le volume de données, arrêter le clonage profond, déplacer le parsing dans un Worker avec défilement virtuel, et diffuser tout ce qui dépasse 50 Mo. Pour les entrées non fiables, limitez taille et profondeur d'imbrication avant de filtrer __proto__, constructor et prototype.

« JSON est lent » est inexact neuf fois sur dix ; ce qui est réellement lent est généralement le rendu, le clonage profond ou le mauvais ordre des opérations.

1. Pourquoi c'est lent

Le parsing d'un grand fichier JSON est lent. Comment l'optimiser ?

Localisez d'abord le goulot, parlez d'optimisation ensuite. Les étapes diffèrent de plusieurs ordres de grandeur :

L'ordre d'optimisation devrait donc être :

1. Réduire le volume de données : faites paginer l'API, retournez seulement les champs nécessaires, et activez gzip/brotli ;
2. Éviter le clonage profond : voir la section suivante ; c'est le coût caché le plus courant ;
3. Rendu paresseux : dans la vue arborescente ne rendez que les niveaux développés au lieu de générer des dizaines de milliers de nœuds DOM d'un coup ;
4. Flux : ne parsez pas tout d'un coup quand les données dépassent 10 Mo.

Si le goulot est réellement JSON.parse, cela signifie que les données font déjà des dizaines de Mo ou plus, et le bon geste est un parseur en flux :

复制import { parser } from 'stream-json';
import { streamArray } from 'stream-json/streamers/StreamArray';

// Handle array elements one by one; memory usage is independent of the total size
const pipeline = fs.createReadStream('big.json')
  .pipe(parser())
  .pipe(streamArray());

pipeline.on('data', ({ value }) => {
  processItem(value);
});

Un JSON de dizaines de Mo plante le navigateur dès l'ouverture. Que faire ?

Confirmez d'abord s'il « plante » ou « fige ». Les deux exigent un traitement complètement différent :

• Fige : l'onglet affiche « Page non réactive » et peut se rétablir après des dizaines de secondes. La cause est des tâches longues saturant le thread principal ;
• Plante : l'onglet devient « Aw, Snap », généralement un épuisement de mémoire (OOM).

Dans les deux cas, ne le traitez pas sur le thread principal. Déplacez le parsing dans un Web Worker :

复制// worker.js
self.onmessage = (event) => {
  const parsed = JSON.parse(event.data);
  self.postMessage(parsed);
};

Un Worker résout « l'interface ne fige pas », pas le plafond de mémoire. Un onglet de navigateur a généralement 1 à 4 Go disponibles ; un JSON de 200 Mo parsé en objets peut occuper 1 Go ou plus (chaque paire clé-valeur porte des surcoûts d'objet), et avec le rendu par-dessus, il atteint facilement la limite.

La vraie solution est de ne jamais tout charger :

JSON.parse(JSON.stringify(obj)) est-il un clonage profond ?

C'est un clonage profond, mais il « change silencieusement les données » à plusieurs endroits, donc il ne convient pas comme outil de clonage général.

复制const source = {
  date: new Date(),
  fn: () => {},
  undef: undefined,
  nan: NaN,
  map: new Map(),
  nested: { a: 1 },
};
JSON.parse(JSON.stringify(source));
// {
//   date: "2026-10-30T03:00:00.000Z",  // Date becomes a string
//   nan: null,                          // NaN becomes null
//   nested: { a: 1 }                    // only this level is correct
// }
// fn and undef disappear, map becomes {}

La liste des problèmes :

Les navigateurs modernes ont structuredClone, qui prend en charge Date, Map, Set et les références circulaires mais pas les fonctions :

复制const copy = structuredClone(source);

S'il ne s'agit que d'une fusion de configuration superficielle, l'opérateur spread est l'option la moins coûteuse : { ...config, timeout: 3000 }.

Pourquoi l'expansion de la vue arborescente est-elle si saccadée ?

Parce que chaque nœud est un élément DOM, et une fois le nombre de nœuds à des dizaines de milliers le coût de layout du navigateur explose.

Un JSON de 10 Mo peut contenir 50 000 à 100 000 nœuds feuilles. Même si vous ne rendez que la zone visible, construire le DOM une fois prend des centaines de millisecondes à des secondes, et chaque défilement ultérieur déclenche un reflow.

La bonne approche :

1. Défilement virtuel : ne rendez que les quelques dizaines de lignes dans la fenêtre et réutilisez les nœuds DOM au défilement ;
2. Replier par défaut : développez seulement les deux premiers niveaux et rendez les niveaux plus profonds à la demande ;
3. Limiter l'échelle de rendu : au-delà de 10 000 nœuds, affichez « Données trop volumineuses, utilisez la recherche pour les localiser » au lieu de forcer un rendu.

C'est aussi pourquoi l'éditeur de ce site se dégrade gracieusement pour les grands fichiers — non pas parce qu'il ne peut techniquement pas les rendre, mais parce que les rendre serait inutilisable.

2. Pourquoi ça se fait attaquer

Comment fonctionne l'injection __proto__ ?

La pollution de prototype. Un attaquant construit du JSON avec une clé __proto__ ; si votre code le fusionne dans un objet sans filtrage, il écrase Object.prototype et affecte chaque objet du runtime.

复制const payload = JSON.parse('{"__proto__": {"isAdmin": true}}');

// Dangerous code: recursive merge without checking key names
function merge(target, source) {
  for (const key in source) {
    if (typeof source[key] === 'object') {
      target[key] = target[key] || {};
      merge(target[key], source[key]);
    } else {
      target[key] = source[key];
    }
  }
  return target;
}

merge({}, payload);
({}).isAdmin;  // true — every object has been polluted

Le fait clé : JSON.parse lui-même ne pollue pas le prototype ; {"__proto__": ...} se parse en une propriété propre ordinaire. Ce qui est dangereux, c'est la fusion, l'affectation, Object.assign, lodash.merge et opérations similaires après le parsing.

Trois défenses :

1. Filtrer les noms de clés : sauter __proto__, constructor et prototype lors de la fusion ;
2. Utiliser Object.create(null) comme conteneur pour qu'il n'y ait pas de chaîne de prototypes à polluer ;
3. Utiliser une Map pour stocker des paires clé-valeur non fiables.

复制function safeMerge(target, source) {
  for (const key of Object.keys(source)) {
    if (key === '__proto__' || key === 'constructor' || key === 'prototype') {
      continue;
    }
    const value = source[key];
    if (value && typeof value === 'object' && !Array.isArray(value)) {
      target[key] = safeMerge(target[key] ?? {}, value);
    } else {
      target[key] = value;
    }
  }
  return target;
}

Notez aussi que for...in parcourt les propriétés héritées ; Object.keys() est plus sûr.

À quoi faut-il faire attention en parsant du JSON non fiable ?

Procédez dans cet ordre — coût faible, bénéfice élevé :

1. Limiter la taille : rejeter immédiatement tout ce qui dépasse le seuil, sans le charger d'abord en mémoire ;
2. Limiter la profondeur : un JSON imbriqué sur des centaines de niveaux peut faire déborder la pile d'un parseur récursif ;
3. Limiter le nombre de clés : prévient les attaques par collision de hachage et l'amplification mémoire ;
4. Filtrer les clés dangereuses : __proto__, constructor, prototype ;
5. Valider la structure : la passer dans un Schema pour confirmer types et champs obligatoires ;
6. Ne pas faire confiance au Content-Type : le type déclaré et le contenu réel peuvent différer.

Une vérification de profondeur est peu coûteuse ; vous pouvez utiliser un filtre regex grossier avant le parsing, ou parcourir après le parsing :

复制function measureDepth(value, depth = 0) {
  if (value === null || typeof value !== 'object') {
    return depth;
  }
  let maxDepth = depth;
  for (const key of Object.keys(value)) {
    maxDepth = Math.max(maxDepth, measureDepth(value[key], depth + 1));
  }
  return maxDepth;
}

Mais ce code est lui-même récursif et peut encore déborder la pile sur des données malicieusement profondes. L'approche sûre est d'imposer la limite pendant le parsing, avec un parseur qui prend en charge une option de profondeur (certaines bibliothèques fournissent un paramètre maxDepth).

Comment un XSS via JSON arrive-t-il ?

JSON lui-même n'est pas du HTML et ne s'exécute pas. Le XSS se produit au point où « une valeur JSON est concaténée dans du HTML ».

Trois chemins courants :

Le troisième est le plus subtil. JSON.stringify n'échappe pas <, donc des données contenant </script><script>alert(1)</script> peuvent fermer la balise script trop tôt :

复制const data = { name: '</script><script>alert(1)</script>' };
// Output: <script>var d = {"name":"</script><script>alert(1)</script>"}</script>

La correction est de convertir les caractères dangereux en échappements Unicode :

复制function safeJsonForHtml(data) {
  return JSON.stringify(data)
    .replace(/</g, '\\u003c')
    .replace(/>/g, '\\u003e')
    .replace(/&/g, '\\u0026')
    .replace(/\u2028/g, '\\u2028')
    .replace(/\u2029/g, '\\u2029');
}

Faut-il limiter la profondeur d'imbrication ?

Oui. C'est l'une des défenses au meilleur rapport coût-bénéfice.

Les conséquences de ne pas la limiter : les fonctions récursives débordent la pile, JSON.parse plante sur certaines implémentations quand la profondeur est trop grande, et la sérialisation fait déborder la pile de la même manière. Un [[[[...]]]] de 1 Ko suffit à faire tomber un parseur non protégé.

Un seuil raisonnable dépend du métier :

Qu'est-ce que le détournement JSON ?

Une vulnérabilité historique : les anciens navigateurs permettaient à un <script src> inter-origine de charger et exécuter du JSON, et les attaquants volaient des données en redéfinissant le constructeur Array ou Object.prototype.__defineSetter__.

Les protections modernes sont assez complètes :

• Les navigateurs n'autorisent plus le détournement de littéraux de tableau avec __defineSetter__ ;
• Un Content-Type: application/json correct empêche l'exécution de script ;
• X-Content-Type-Options: nosniff empêche le MIME sniffing.

Les systèmes anciens portent encore un risque résiduel. Conseil pratique : utilisez un objet au niveau supérieur, pas un tableau nu. Un enveloppant comme {"data": [...]} empêche la réponse d'être une instruction JavaScript valide ({ est traité comme un bloc de code), bloquant le détournement au niveau syntaxique.

Quels sont les risques de journaliser du JSON ?

Trois :

1. Informations sensibles écrites sur disque : numéros de téléphone, numéros d'identité, tokens et mots de passe en clair atterrissent dans le système de journalisation, qui a généralement des permissions plus laxistes et une rétention plus longue ;
2. Injection de journal : une valeur JSON contenant des retours à la ligne et des préfixes de journal forgés divise un enregistrement en plusieurs et pollue la piste d'audit ;
3. Explosion de taille : écrire une réponse entière de 10 Mo dans le journal remplit vite le système de journalisation.

Approche :

复制// Redact and truncate before logging
function safeLog(data) {
  const cloned = structuredClone(data);
  for (const key of ['password', 'token', 'idCard', 'phone']) {
    if (key in cloned) cloned[key] = '***';
  }
  const text = JSON.stringify(cloned);
  return text.length > 2000 ? text.slice(0, 2000) + '...(truncated)' : text;
}

Les systèmes de journalisation structurée (comme pino) échappent eux-mêmes les retours à la ligne, mais la rédaction et la troncature restent votre travail.

3. Aide-mémoire