Pourquoi faut-il abandonner JSON ?

Le partage, c’est bien quand c’est utile :

Beaucoup d’applications web, utilisant les technologies AJAX, utilisent également le format JSON pour des raisons que nous verrons plus loin. Ce format apporte aussi des problèmes parfois importants. Il existe donc un certain nombre de cas où il sera plus intelligent de se tourner vers d’autres formats. Nous verrons les alternatives au JSON en fin d’article.

Les dangers de JSON

  • Sécurité des données confidentielles (same origin policy)
  • Erreurs silencieuses (<= données dynamiques)
  • Usage des données dans d’autre programmes

Sécurité : Fuite d’informations. Pour empêcher à un site d’utiliser le navigateur d’un utilisateur afin de récupérer des données sur un serveur tierce – par exemple, lire « voler » ses e-mails via son webmail – les navigateurs ont implémentés une Same-Origin Policy (politique de même provenance).

Cette restriction empêchera, par exemple, un script de hacker.tld à lancer une requête avec XMLHttpRequest (requête AJAX) sur un autre domaine tel que donnees-critiques.com. Tout serait parfait si il n’existait pas un risque inhérent à JSON. Reprenons notre exemple.

Imaginons maintenant que donnees-critiques.com renvoient certaines données avec ce format. Le script tournant sur hacker.tld pourrait inclure une balise <script src= »http://donnees-critiques.com/json?get=profil » type= »text/javascript »></script> en ayant préalablement remplacer les objets Array et Hash par des objets personnalisés. Sur certains navigateurs, l’évaluation du document JSON va alors utiliser ces nouveaux objets et, par conséquent, permettre au pirate de récupérer les données sensibles.

Première limite : pas de données sensibles ou privées sous le format JSON.

Erreurs silencieuses. Lors de la réception d’un document JSON, celui-ci est passé dans la méthode eval(). En cas d’erreur lors du traitement, aucune erreur ne sera retournée. Le script risque simplement de crasher sans raison apparente. Cela peut être très ennuyant et causé par une simple erreur de syntaxe.

Pour cette raison, il est plus sûr d’éviter de générer dynamiquement des réponses dans ce format, d’autant plus qu’une erreur de filtrage des données lors de la génération du document pourrait directement amené à une faille DOM-Based XSS (injection XSS du DOM). Encore une fois, la sécurité s’en verrait dangereusement atteinte.

Deuxième limite : les données dynamiques dans les réponses JSON.

Portabilité des données. Enfin, JSON est un format propre à JavaScript. Même s’il peut être utilisé dans d’autres langages, il reste fort attacher à la syntaxe de JavaScript et les avantages de son utilisation ne se font réellement ressentir qu’avec ce dernier. Pour pouvoir utiliser les données dans d’autres logiciels, il sera alors préférable d’utiliser un langage tel que XML, le roi de la portabilité.

Troisième limite : la portabilité.

Les avantages de JSON

Ce format présente néanmoins des avantages non-négligeable. Il existe donc de nombreux cas où son usage sera beaucoup plus pratique et efficace que les alternatives présentées ci-après, tout en étant pas concerné par les dangers cités plus haut.

  • Performance
  • Facilité
  • Contournement de la Same-Origin Policy (pour dialoguer avec d’autres serveurs)

Performance. Le traitement d’un document JSON, comparativement à celui d’une réponse en XML par exemple, se fera très rapidement. En effet, ce format est directement traité par l’interpréteur JavaScript, pas besoin de code supplémentaire pour parser les données.

De plus, les fichiers seront souvent plus légers grâce à la syntaxe épurée de ce format. Les temps de téléchargement s’en verront donc réduits. Rien à voir en effet avec un document XML.

Facilité. Cette syntaxe épurée facilitera également la rédaction et accélérera le temps de développement de l’application web. Gare aux erreurs néanmoins, voir le point sur les erreurs silencieuse dans les dangers de JSON.

Contourner la Same-Origin Policy. Quand on veut partager des données avec d’autres sites, il peut être plus simple de permettre à l’application côté client de directement récupérer ces données (quand aucun traitement ne devra être réalisé par l’application côté serveur auquel cas on fait passer le document via le serveur). Pourtant, le concept de SOP ne le permet normalement pas. Le danger évoqué plus haut devient alors une opportunité. On va quand même en profiter d’une manière plus simple qu’en surchargeant des objets JS en utilisant un dérivé de JSON, le format JSONP. (sujet d’un prochain billet sur ce blog)

Alternatives

  • Javascript
  • HTML
  • XML
  • Données brutes

NB: Si les données sont déjà disponibles dans un certain format utilisable avec JavaScript, pourquoi ne pas en profiter ? On peut ainsi accélérer le développement de l’application, diminuer le risque de bug pendant le traitement et améliorer les performances côté serveur.

JavaScript. En envoyant directement le code à exécuter au navigateur, c’est la méthode la plus souple pour modifier le contenu de la page dans les applications AJAX. Cette souplesse est obtenue au détriment complet de la portabilité, JS n’étant pas un format de données.

HTML. S’il s’agit simplement de modifier une partie de la page, pourquoi ne pas renvoyer directement le code HTML de la partie à changer. En plus d’être facile à mettre en oeuvre côté client, cette technique permet de réduire le travail. En effet, si le principe d’amélioration progressive (ou de dégradation élégante) est respecté, ces parties de document en HTML ont déjà été rédigés. Si vous utilisez un framework MVC ou même des templates avec des insertions, ces parties de vue peuvent même etre séparées dans des fichiers différents pour encore plus de facilité.

XML. Champion de la portabilité, c’est un format qui est pourtant lourd et parfois lent à traiter. C’est pourtant le meilleur choix en terme de sécurité et de portabilité.

Données brutes. Si l’information renvoyée est assez simple, elle peut bien évidemment être directement renvoyée sans être contenue dans un document plus complexe. C’est le cas d’une chaîne de caractères ou d’un nombre notamment.

En conclusion, l’usage des différents formats dans une application web doit être bien réfléchi pour trouver un juste milieu entre rapidité de développement, sécurité et portabilité des données pour l’ajout de fonctionnalités dans le futur éventuellement.

Le partage, c’est bien quand c’est utile :