Résumé

  • Dans son projet YAML-LD 1.0 du 24 septembre 2026, le W3C détaille deux risques de traitement : la multiplication des données par les alias et l’exécution inattendue de code par certains tags.
  • Cette section est non normative. Le RFC 9512 exposait déjà ces risques en 2024 ; le projet du 20 septembre ne les formulait pas encore ainsi.
  • La possibilité de représenter le contenu en JSON-LD et la sûreté du logiciel qui effectue la conversion relèvent de deux décisions distinctes.

Un échange de données peut commencer avec une page YAML-LD de quelques lignes. Le fichier passe une vérification de syntaxe, puis le lecteur accepte ses termes de données liées. Ce contrôle ne dit toujours pas combien d’objets le parseur devra fabriquer. Les alias permettent de réutiliser un nœud ; lors de la construction de la représentation JSON-LD, chaque référence devient une copie. Une entrée légère peut alors devenir une structure coûteuse, même sans cycle.

Le projet du groupe de travail JSON-LD daté du 24 septembre donne à ce problème une visibilité nouvelle. Sa section consacrée à la sécurité, explicitement non normative, renvoie maintenant au RFC 9512. Elle précise que les alias peuvent amplifier un graphe YAML compact et que des tags peuvent provoquer une exécution de code inattendue dans certains parseurs. !!python/object y sert d’exemple. Dans le texte du 20 septembre, la section se limitait essentiellement à un renvoi aux considérations de JSON-LD et au suffixe +yaml.

Il serait trompeur de dater le risque du 24 septembre. Le RFC 9512, publié par l’IETF à titre informatif en février 2024 pour enregistrer le type de média YAML, traitait déjà de l’épuisement des ressources et de l’exécution arbitraire de code. Le changement du W3C est une explicitation au sein de YAML-LD, pas la découverte d’une faille ni la preuve qu’un produit en souffre. Le document demeure un projet de travail susceptible de changer ; sa publication ne vaut pas approbation du W3C ou de ses membres.

La finalité du format est autre. YAML-LD vise à exprimer des données liées sous une forme YAML qui reste représentable en JSON-LD sans perte de sens. Le projet autorise ancres et alias dans la sérialisation mais interdit les cycles dans le graphe de représentation. Les noms d’ancres et la structure des alias ne survivent pas comme information sémantique. Cette liberté d’écriture est utile à l’auteur d’un fichier ; elle n’établit aucune limite de mémoire pour le logiciel qui le lit.

La conformité impose bien des conditions : UTF-8, traitement compatible avec YAML 1.2 ou une version ultérieure, clés de mapping sous forme de chaînes et réussite des suites de tests citées. Le texte rappelle aussi qu’un parseur resté au comportement YAML 1.1 peut interpréter no ou on comme des booléens. Ces prescriptions encadrent le résultat de conversion. Elles ne choisissent pas les constructeurs de tags autorisés dans une bibliothèque donnée, ni un plafond d’expansion des alias à l’entrée d’un service.

Le lieu de la décision de gouvernance se trouve donc chez celui qui déploie le traitement. Il peut enregistrer la version et le mode du parseur, les tags admis, les limites de ressources, la frontière des fichiers non fiables et les essais effectués. Cette fiche serait une proposition d’exploitation de Daniel Kade, non une nouvelle obligation du W3C. Dire qu’un document respecte la sémantique YAML-LD apporte une information utile ; en déduire que toute manière de le parser est sûre reviendrait à confondre le contenu avec son mode d’exécution.

Sources