Publié le 29 octobre 2025
Chrome prévoit d'abandonner et de supprimer XSLT du navigateur. Ce document explique comment migrer votre code avant la suppression fin 2026.
Chromium a officiellement abandonné XSLT, y compris l'API JavaScript XSLTProcessor et l'instruction de traitement des feuilles de style XML. Nous prévoyons de supprimer la compatibilité à partir de la version 155 (17 novembre 2026). Les projets Firefox et WebKit ont également indiqué qu'ils prévoyaient de supprimer XSLT de leurs moteurs de navigateur. Ce document fournit un historique et un contexte, explique comment nous supprimons XSLT pour rendre Chrome plus sûr et indique comment migrer avant que ces fonctionnalités ne soient supprimées du navigateur.
Qu'est-ce qui va être supprimé ?
Deux API du navigateur implémentent XSLT, et les deux sont en cours de suppression :
- La classe XSLTProcessor (par exemple,
new XSLTProcessor()). - L'instruction de traitement XSLT (par exemple,
<?xml-stylesheet … ?>).
Timeline For Chrome
Chrome propose le forfait suivant :
- Chrome 142 (28 octobre 2025) : des messages d'avertissement précoce ont été ajoutés à la console Chrome.
- Chrome 143 (2 décembre 2025) : abandon officiel de l'API. Des messages d'avertissement d'abandon commencent à s'afficher dans la console et dans Lighthouse.
- Chrome 148 (10 mars 2026, Canary) : les versions Canary, en développement et bêta commencent à désactiver XSLT par défaut, à titre d'avertissement précoce.
- Chrome 152 (25 août 2026) : la phase d'évaluation de l'origine et la règle d'entreprise sont mises en ligne pour les tests. Ils permettent aux sites et aux entreprises de continuer à utiliser les fonctionnalités après la date de suppression.
- Chrome 155 (17 novembre 2026) : XSLT ne fonctionnera plus dans les versions stables pour tous les utilisateurs, à l'exception de ceux qui participent à l'Origin Trial et à la règle d'entreprise.**
- Chrome 164 (17 août 2027) : l'essai d'origine et la règle d'entreprise ne fonctionneront plus. XSLT est désactivé pour tous les utilisateurs.**
Qu'est-ce que XSLT ?
XSLT, ou Extensible Stylesheet Language Transformations, est un langage utilisé pour transformer des documents XML, généralement dans d'autres formats tels que HTML. Il utilise un fichier de feuille de style XSLT pour définir les règles de cette conversion et un fichier XML contenant les données utilisées comme entrée.
Dans les navigateurs, lorsqu'un fichier XML est reçu et qu'il est associé à une feuille de style XSLT, le navigateur utilise les règles de cette feuille de style pour réorganiser, mettre en forme et convertir les données XML brutes en une page structurée (souvent HTML) qui peut être affichée pour l'utilisateur.
Par exemple, une feuille de style XSLT peut prendre l'entrée XML suivante :
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl" ?>
<page>
<message>
Hello World.
</message>
</page>
et cette feuille de style XSL :
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="html"/>
<xsl:template match="/page/message">
<body>
<p>Message: <xsl:value-of select="."/></p>
</body>
</xsl:template>
</xsl:stylesheet>
et les traiter dans ce code HTML pour que le navigateur les affiche : HTML
<body>
<p>Message: Hello World.</p>
</body>
En plus de l'instruction de traitement XSL présentée dans l'exemple précédent, il existe également l'API JavaScript XSLTProcessor qui peut être utilisée pour traiter des documents XML locaux avec des feuilles de style XSLT locales.
Historique de XSLT
Le W3C (World Wide Web Consortium) a recommandé XSLT le 16 novembre 1999 comme langage permettant de transformer des documents XML en d'autres formats, le plus souvent HTML pour l'affichage dans les navigateurs Web. Avant la recommandation officielle 1.0, Microsoft a pris l'initiative de fournir une implémentation propriétaire basée sur un brouillon de travail du W3C dans Internet Explorer 5.0, publié en mars 1999. Conformément à la norme officielle, Mozilla a implémenté la compatibilité native avec XSLT 1.0 dans Netscape 6 fin 2000. D'autres navigateurs courants, y compris Safari, Opera et les versions ultérieures de Chrome, ont également intégré des processeurs XSLT 1.0 natifs, ce qui a fait des transformations XML en HTML côté client une technologie Web viable au début des années 2000.
Le langage XSLT lui-même a continué d'évoluer, avec la sortie de XSLT 2.0 en 2007 et de XSLT 3.0 en 2017, qui ont introduit des fonctionnalités puissantes telles que les expressions régulières, des types de données améliorés et la possibilité de traiter le format JSON. Toutefois, la prise en charge des navigateurs a stagné. Aujourd'hui, tous les principaux moteurs de navigateur Web ne sont compatibles en natif qu'avec la version 1.0 d'origine de XSLT, datant de 1999. Ce manque d'évolution, associé à l'utilisation croissante de JSON comme format de transfert et aux bibliothèques et frameworks JavaScript (comme jQuery, React et Vue.js) qui offrent une manipulation et une création de modèles DOM plus flexibles et puissantes, a entraîné une baisse significative de l'utilisation de XSLT côté client. Son rôle au sein du navigateur Web a été largement remplacé par ces technologies basées sur JavaScript.
Pourquoi XSLT doit-il être supprimé ?
L'inclusion continue de XSLT 1.0 dans les navigateurs Web présente un risque de sécurité important et inutile. Les bibliothèques sous-jacentes qui traitent ces transformations, telles que libxslt (utilisée par les navigateurs Chromium), sont des bases de code C/C++ complexes et vieillissantes. Ce type de code est notoirement susceptible de présenter des failles de sécurité de la mémoire, comme des dépassements de mémoire tampon, qui peuvent entraîner l'exécution de code arbitraire. Par exemple, les audits de sécurité et les outils de suivi des bugs ont identifié à plusieurs reprises des failles de sécurité de gravité élevée dans ces analyseurs (par exemple, CVE-2025-7425 et CVE-2022-22834, toutes deux dans libxslt). Étant donné que XSLT côté client est désormais une fonctionnalité de niche rarement utilisée, ces bibliothèques font l'objet de beaucoup moins de maintenance et d'examens de sécurité que les moteurs JavaScript principaux. Pourtant, elles représentent une surface d'attaque directe et puissante pour le traitement de contenu Web non fiable. En effet, XSLT est à l'origine de plusieurs exploits de sécurité très médiatisés qui continuent de mettre en danger les utilisateurs de navigateurs. Les risques de sécurité liés au maintien de cette fonctionnalité ancienne et fragile l'emportent largement sur son utilité moderne limitée.
De plus, l'objectif initial de XSLT côté client (transformer les données en HTML affichable) a été remplacé par des API JavaScript plus sûres, plus ergonomiques et mieux gérées. Le développement Web moderne repose sur des éléments tels que l'API Fetch pour récupérer des données (généralement au format JSON) et l'API DOMParser pour analyser de manière sécurisée les chaînes XML ou HTML dans une structure DOM au sein du bac à sable JavaScript sécurisé du navigateur. Des frameworks tels que React, Vue et Svelte gèrent ensuite le rendu de ces données de manière efficace et sécurisée. Cette chaîne d'outils moderne est en développement actif, bénéficie de l'investissement massif dans la sécurité des moteurs JavaScript et est utilisée par pratiquement tous les développeurs Web aujourd'hui. En effet, seulement 0,02 % des chargements de pages Web utilisent XSLT aujourd'hui, et moins de 0,001 % utilisent des instructions de traitement XSLT.
Il ne s'agit pas d'une action réservée à Chrome ou Chromium : les deux autres principaux moteurs de navigateur prennent également en charge la suppression de XSLT de la plate-forme Web : WebKit, Gecko.
Pour ces raisons, la suppression de XSLT réduit la surface d'attaque du navigateur pour tous les utilisateurs, simplifie la plate-forme Web et permet de concentrer les ressources d'ingénierie sur la sécurisation des technologies qui alimentent réellement le Web moderne, sans perte pratique de capacité pour les développeurs.
Améliorer la sécurité de l'analyse XML
Comme pour les problèmes de sécurité graves dans libxslt, des problèmes de sécurité graves ont récemment été signalés concernant libxml2, qui est utilisé dans Chromium pour l'analyse, la sérialisation et le test de la bonne formation du code XML. Pour résoudre les futurs problèmes de sécurité liés à l'analyse XML dans Chromium, nous prévoyons d'abandonner l'utilisation de libxml2 et de remplacer l'analyse XML par une bibliothèque d'analyse XML sécurisée en mémoire écrite en Rust. Il est important de noter que nous ne supprimerons pas le XML du navigateur. Seul le XSLT est envisagé pour la suppression ici. Nous souhaitons nous assurer que le remplacement de libxml2 est entièrement transparent pour les développeurs Web.
Comment procéder ?
Il existe plusieurs autres méthodes de migration.
JSON
Pour les sites entièrement conçus en XML et XSL, il n'existe pas de méthode universelle pour effectuer la transition. Les options de migration incluent le déplacement du pipeline de traitement XSLT côté serveur et l'envoi du code HTML rendu au client, ou la migration des points de terminaison de l'API XML côté serveur vers JSON et l'exécution du rendu côté client à l'aide de JavaScript pour transformer JSON en DOM HTML et CSS.
XSLT côté client en JavaScript
Il existe plusieurs bibliothèques XSLT côté client (basées sur JavaScript), mais la plus grande est de loin celle produite par Saxonica (consultez la documentation complète de Saxonica). L'implémentation va bien au-delà de l'implémentation XSLT 1.0 dans les navigateurs Web, en implémentant une prise en charge complète de la dernière norme v3.0 et, à terme, de la norme v4.0 en cours de développement.
Rembourrage
Un polyfill tente de permettre au code existant, qui dépend des implémentations XSLT 1.0 des navigateurs Web, de continuer à fonctionner sans utiliser les fonctionnalités XSLT natives du navigateur. Le polyfill est disponible sur GitHub.
Le polyfill contient un remplacement fonctionnel basé sur WASM pour la classe XSLTProcessor. Le code JavaScript existant peut donc continuer à fonctionner tel quel :
<script src="xslt-polyfill.min.js"></script>
<script>
const xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsltDoc);
const fragment = xsltProcessor.transformToFragment(xmlDoc, document);
</script>
Le polyfill fournit également une fonction utilitaire automatique pour remplacer facilement les documents XML qui utilisent des instructions de traitement XSLT :
Pour un fichier demo.xml d'origine comme celui-ci :
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
...content...
Une ligne peut être ajoutée pour appeler le polyfill et transformer le document avec la feuille de style XSLT référencée :
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
<script src="xslt-polyfill.min.js"
xmlns="http://www.w3.org/1999/xhtml"></script>
...content...
Dans ce cas, le nouvel élément <script> charge le polyfill, qui détecte le type de document XML et l'instruction de traitement XSLT, puis le charge de manière transparente, en remplaçant le document.
Extension
Il existe également une extension Chrome qui peut être ajoutée aux navigateurs compatibles. Elle appliquera le même polyfill XSLT à toutes les pages XML brutes contenant des instructions de traitement XSLT ou des appels à XSLTProcessor. Cela peut être utilisé pour les applications où le code XML ou XSLT source ne peut pas être modifié, afin de maintenir la fonctionnalité.
Plus précisément, lorsque XSLT est désactivé, Chrome affiche désormais une bannière d'avertissement qui redirige directement vers une page de recherche d'extensions pour aider les utilisateurs à en trouver une :
Cas d'utilisation spécifiques
Dans la discussion sur les normes HTML, plusieurs cas d'utilisation concrets ont été identifiés. Cette section traite spécifiquement de chacun d'eux, afin de recommander des pistes aux développeurs qui publient aujourd'hui des ressources XML utilisant XSLT.
Flux RSS et Atom
Dans de nombreux flux RSS ou Atom existants, XSLT est utilisé pour rendre les flux XML bruts lisibles par l'homme lorsqu'ils sont consultés directement dans un navigateur. Le principal cas d'utilisation est le suivant : lorsqu'un utilisateur clique accidentellement sur le lien du flux RSS d'un site, au lieu de coller ce lien dans son lecteur RSS, il obtient une réponse HTML mise en forme qu'il peut lire, plutôt que le code XML brut lui-même.
Deux options s'offrent à vous pour ce cas d'utilisation. La méthode HTML "standard" consiste à ajouter <link rel="alternate" type="application/rss+xml"> à un site (basé sur HTML), plutôt que d'ajouter un <a
href="something.xml"> explicite (visible par l'utilisateur) sur lequel les utilisateurs pourraient cliquer par erreur. Cette solution permet aux lecteurs RSS de trouver le flux si un utilisateur colle uniquement l'URL du site Web. Elle permet également aux utilisateurs humains de voir le contenu HTML normal sans être déroutés par un lien vers une ressource XML. Cela suit également le paradigme Web normal selon lequel le HTML est destiné aux humains et le XML aux machines. Bien sûr, cela ne résout pas le problème dans le cas où un utilisateur "possède " simplement un lien RSS provenant d'une source quelconque et le colle dans son navigateur Web (plutôt que dans son lecteur RSS).
Lorsque cette solution n'est pas souhaitée, le polyfill propose une autre voie. Comme indiqué précédemment, le flux XML RSS/Atom peut être complété par une ligne, <script
src="xslt-polyfill.min.js"
xmlns="[http://www.w3.org/1999/xhtml](http://www.w3.org/1999/xhtml)"></script>, qui conservera le comportement existant de la transformation basée sur XSLT en HTML.
Cela ne devrait pas affecter la capacité du lecteur RSS à continuer d'analyser le fichier XML, car <script> est un enfant direct de l'élément racine.
Sortie de l'API pour les appareils intégrés
Certains appareils intégrés commerciaux mesurent ou génèrent des données XML pour que les utilisateurs du réseau local puissent les consulter. Certains appareils génèrent un flux de données XML unique qui utilise XSLT pour le transformer en format HTML lisible par l'homme. Cela permet d'afficher directement l'API dans un navigateur sans avoir besoin de code supplémentaire sur l'appareil ou dans le navigateur.
Comme il s'agit d'un cas d'utilisation très spécifique à une application, la forme de la solution peut varier. Pour les applications où le code source de l'appareil intégré peut être mis à jour, n'importe laquelle des options décrites précédemment (JSON, Polyfill) peut fonctionner. Toutefois, de nombreux appareils de ce type sont difficiles, voire impossibles à mettre à jour, pour diverses raisons. Dans ce cas, l'extension est probablement la meilleure option, car elle permet aux navigateurs clients de continuer à lire les données exactement de la même manière, sans modifier l'appareil.
Modèles différés pour les sites Web
Les développeurs Web utilisent parfois XSLT côté client pour appliquer un balisage de présentation à un balisage sémantique. Il fonctionne comme un langage de création de modèles différée distinct de l'écosystème JavaScript.
Il existe deux solutions à ce problème plus général. Pour un site existant créé de cette manière, la solution la plus simple consiste probablement à ajouter le polyfill pour conserver les fonctionnalités existantes. Vous pouvez également effectuer la transformation XSLT côté serveur et diffuser le code HTML résultant au client, plutôt que le code XML brut. La solution à long terme pour ces propriétés serait de migrer vers un framework JavaScript ou JSON plus moderne.