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 XSLT. Nous prévoyons de supprimer la compatibilité à partir de la version 158 (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. Pour connaître les dernières informations, consultez également l'entrée Chrome Platform Status.
Qu'est-ce qui est supprimé ?
Deux API du navigateur implémentent XSLT, et toutes deux sont en cours de suppression :
- XSLTProcessor (par exemple,
new XSLTProcessor()). - L'instruction de traitement XSLT (par exemple,
<?xml-stylesheet type="text/xsl" ... ?>).
Chronologie pour Chrome
Chrome prévoit de procéder comme suit :
- Chrome 142 (28 octobre 2025) : ajout de messages d'avertissement anticipé à 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 145 (2 décembre 2025 Canary) : les versions Canary, Dev et bêta commencent à désactiver XSLT par défaut, à titre d'avertissement anticipé.
- Chrome 146 (10 mars 2026) : mise en ligne de la règle d'entreprise à des fins de test. Cela permet aux entreprises de tester la désactivation de XSLT de manière anticipée, et de continuer à utiliser les fonctionnalités après la date de suppression.
- Chrome 152 (25 août 2026) : mise en ligne de l'essai Origin Trial (OT) à des fins de test. Ils permettent aux sites de continuer à utiliser des fonctionnalités après leur date de suppression.
- Chrome 154 (22 septembre 2026) : les versions Canary, Dev et bêta de WebView commencent à désactiver XSLT par défaut, à titre d'avertissement anticipé.
- Chrome 158 (17 novembre 2026) : XSLT ne fonctionne plus dans les versions stables pour tous les utilisateurs, à l'exception de ceux qui participent à l'essai Origin Trial ou qui utilisent la règle d'entreprise.
- Chrome 176 (17 août 2027) : l'essai Origin Trial et la règle Enterprise ne fonctionnent plus. XSLT est désactivé pour tous les utilisateurs.
Qu'est-ce que XSLT ?
XSLT (Extensible Stylesheet Language Transformations) est un langage utilisé pour transformer des documents XML, généralement dans d'autres formats tels que HTML. Elle utilise un fichier de feuille de style XSLT pour définir les règles de cette conversion, ainsi qu'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, formater 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 accepter 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 traite dans ce code HTML pour que le navigateur l'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 langage XSLT a été recommandé par le World Wide Web Consortium (W3C) le 16 novembre 1999 en tant que langage permettant de transformer des documents XML dans d'autres formats, le plus souvent HTML, pour les afficher dans des navigateurs Web. Avant la recommandation officielle 1.0, Microsoft a pris l'initiative de proposer une implémentation propriétaire basée sur un projet de travail du W3C dans Internet Explorer 5.0, sorti 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 majeurs, dont Safari, Opera et, plus tard, Chrome, ont également intégré des processeurs XSLT 1.0 natifs, faisant des transformations XML vers HTML côté client une technologie Web viable au début des années 2000.
Le langage XSLT 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. Cependant, la compatibilité des navigateurs a stagné. Aujourd'hui, tous les principaux moteurs de navigateur Web ne fournissent une compatibilité native que pour la version XSLT 1.0 d'origine de 1999. Cette stagnation, associée à l'essor de l'utilisation de JSON comme format de transmission, et des bibliothèques et frameworks JavaScript (comme jQuery, React et Vue.js) qui offrent une manipulation du DOM et une création de modèles plus flexibles et puissantes, a entraîné une baisse significative de l'utilisation de XSLT côté client. Son rôle dans le navigateur Web a été largement supplanté 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 codebases C/C++ complexes et vieillissants. Ce type de code est connu pour être particulièrement exposé à des failles de sécurité liées à la mémoire telles que les dépassements de tampon, qui peuvent entraîner l'exécution de code arbitraire. Par exemple, des audits de sécurité et des outils de suivi des bugs ont identifié à plusieurs reprises des failles de gravité élevée dans ces analyseurs (par exemple, CVE-2025-7425 et CVE-2022-22834, tous 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 contenus Web non fiables. En effet, XSLT est à l'origine de plusieurs failles de sécurité récentes très médiatisées qui continuent de mettre en danger les utilisateurs de navigateurs. Les risques de sécurité liés au maintien de cette fonctionnalité obsolète et fragile l'emportent largement sur son utilité limitée aujourd'hui.
De plus, l'objectif initial de XSLT côté client (transformer des données en code 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 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. Les frameworks tels que React, Vue et Svelte gèrent ensuite l'affichage de ces données de manière efficace et sécurisée. Cette chaîne d'outils moderne est développée de manière active, 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, seuls environ 0,02 % des chargements de pages Web utilisent actuellement XSLT, 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 sont également compatibles avec la suppression de XSLT de la plate-forme Web : WebKit, Gecko.
Pour ces raisons, l'abandon et la suppression de XSLT réduisent la surface d'attaque du navigateur pour tous les utilisateurs, simplifient la plate-forme Web et permettent de concentrer les ressources d'ingénierie sur la sécurisation des technologies qui alimentent réellement le Web moderne, sans perte de capacité pratique 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 dans libxml2, qui est utilisé dans Chromium pour l'analyse, la sérialisation et le test de la conformité du XML. Pour résoudre les futurs problèmes de sécurité liés à l'analyse XML dans Chromium, nous prévoyons de supprimer progressivement 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 format XML du navigateur. Seul le format XSLT est concerné par cette suppression. Nous voulons nous assurer que le remplacement de libxml2 est entièrement transparent pour les développeurs Web.
XML + CSS n'est pas supprimé.
Il est important de distinguer l'abandon de XSLT (<?xml-stylesheet type="text/xsl" ... ?>) de l'instruction de traitement <?xml-stylesheet ... ?> elle-même, qui reste compatible lorsqu'elle est utilisée avec CSS. Vous pouvez toujours utiliser l'instruction de traitement avec type="text/css" pour appliquer des règles de mise en page et de conception standards à vos données brutes, comme vous le feriez avec du code HTML. Exemple :
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="styles.css"?>
<root>
<item>Content here</item>
</root>
Comment procéder ?
Il existe plusieurs autres méthodes de migration.
JSON
Pour les sites entièrement basés sur XML et XSL, il n'existe pas de solution universelle pour effectuer la transition. Les options de migration incluent le déplacement du pipeline de traitement XSLT vers le côté serveur et l'envoi du code HTML affiché au client, ou la migration des points de terminaison de l'API XML côté serveur vers JSON, et l'affichage côté client à l'aide de JavaScript pour transformer JSON en DOM HTML et CSS.
XSLT côté client en JavaScript
Il existe quelques bibliothèques XSLT côté client (basées sur JavaScript), mais la plus importante est de loin celle produite par Saxonica (consultez la documentation complète sur Saxonica). L'implémentation va bien au-delà de l'implémentation de XSLT 1.0 dans les navigateurs Web, en implémentant la compatibilité totale avec la dernière norme v3.0, et éventuellement la norme v4.0 en cours de développement.
Polyfill
Il existe un polyfill qui tente de permettre au code existant, qui dépend des implémentations de XSLT 1.0 par les 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 polyfillé 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 permettant de 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...
Vous pouvez ajouter une ligne 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 applique 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é.
En particulier, lorsque XSLT est désactivé, Chrome affiche désormais une bannière d'avertissement qui renvoie directement vers une page de recherche d'extensions, pour aider les utilisateurs à trouver une extension :
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 chacune d'entre elles, afin de recommander des solutions aux développeurs qui publient des ressources XML utilisant XSLT aujourd'hui.
Flux RSS et Atom
Dans de nombreux flux RSS ou Atom existants, XSLT est utilisé pour rendre les flux XML bruts lisibles par l'humain lorsqu'ils sont affiché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 formatée qu'il peut lire, plutôt que le code XML brut lui-même.
Deux options sont possibles pour ce cas d'utilisation. La méthode HTML "standard" consiste à ajouter <link rel="alternate" type="application/rss+xml"> à un site (HTML), plutôt que d'ajouter un <a
href="something.xml"> explicite (visible par l'utilisateur) sur lequel les utilisateurs pourraient cliquer accidentellement. Cette solution permet aux lecteurs RSS de trouver le flux si un utilisateur colle simplement l'URL du site Web, mais elle permet également aux utilisateurs humains de voir le contenu HTML standard sans être déroutés par un lien vers une ressource XML. Cela suit également le paradigme Web normal selon lequel le code HTML est destiné aux humains et le code XML aux machines. Bien sûr, cela ne résout pas le cas où un utilisateur "possède " un lien RSS provenant d'un endroit 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 offre une autre solution. 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"></script>, qui conservera le comportement existant de la transformation basée sur XSLT en HTML.
Cela ne devrait pas empêcher le lecteur RSS de continuer à 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 les utilisateurs du réseau local. Certains de ces appareils génèrent un flux de données XML unique qui utilise XSLT pour le transformer en un format HTML lisible par l'humain. Cela permet d'afficher l'API directement 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 à l'application, la forme de la solution peut varier. Pour les applications où le code source de l'appareil intégré peut être mis à jour, l'une des options décrites précédemment (JSON, Polyfill) peut fonctionner. En particulier, 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 au balisage sémantique, qui fonctionne comme un langage de création de modèles différé distinct de l'écosystème JavaScript.
Il existe deux solutions à ce problème plus général. Pour un site existant conçu 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 obtenu au client, plutôt que le code XML brut. La solution à plus long terme pour ces propriétés consiste à migrer vers un framework JavaScript ou JSON plus moderne.
Si vous rencontrez un problème spécifique dans Chrome lié à l'abandon de XSLT, signalez un bug ici.
Comment détecter l'utilisation de XSLT
En général, les fonctionnalités obsolètes telles que XSLT peuvent être détectées dans votre codebase de plusieurs manières. Cette section en présente deux.
API Reporting
L'API Reporting est un mécanisme de reporting générique permettant aux applications Web de générer des rapports sur diverses fonctionnalités et conditions de la plate-forme, y compris l'abandon de fonctionnalités. Pour le configurer afin qu'il signale l'abandon de XSLT, vous pouvez utiliser un extrait de code comme celui-ci :
new ReportingObserver((reports, observer) => {
reports.forEach((report) => {
if (report.body.id === "XSLT") {
// XSLT usage was detected - report it back here.
}
});
}, {types: ["deprecation"],buffered: true}).observe();
Voir ce code en action sur CodePen
Rapport sur les anciennes technologies d'entreprise
Les administrateurs d'une entreprise peuvent utiliser le rapport sur les anciennes technologies pour collecter automatiquement l'utilisation des fonctionnalités obsolètes et les signaler de manière conviviale. Pour en savoir plus sur l'activation de cette fonctionnalité, consultez cet article de l'assistance Google.