Data di pubblicazione: 29 ottobre 2025
Chrome intende ritirare e rimuovere XSLT dal browser. Questo documento descrive in dettaglio come eseguire la migrazione del codice prima della rimozione alla fine del 2026.
Chromium ha ritirato ufficialmente XSLT, inclusi l'API JavaScript XSLTProcessor e l'istruzione di elaborazione del foglio di stile XML. Prevediamo di rimuovere il supporto a partire dalla versione 155 (17 novembre 2026). I progetti Firefox e WebKit hanno anche indicato l'intenzione di rimuovere XSLT dai motori dei browser. Questo documento fornisce un po' di storia e contesto, spiega come stiamo rimuovendo XSLT per rendere Chrome più sicuro e fornisce un percorso per la migrazione prima che queste funzionalità vengano rimosse dal browser.
Che cosa viene rimosso?
Nel browser sono presenti due API che implementano XSLT ed entrambe verranno rimosse:
- La classe
XSLTProcessor (ad esempio,
new XSLTProcessor()). - L'istruzione di elaborazione XSLT
(ad esempio,
<?xml-stylesheet … ?>).
Tempistiche per Chrome
Chrome ha il seguente piano:
- Chrome 142 (28 ottobre 2025): sono stati aggiunti a Chrome messaggi della console di avviso anticipato.
- Chrome 143 (2 dicembre 2025): ritiro ufficiale dell'API. I messaggi di avviso di ritiro iniziano a essere visualizzati nella console e in Lighthouse.
- Chrome 148 (10 marzo 2026 Canary): le release Canary, Dev e beta iniziano a disattivare XSLT per impostazione predefinita, come avviso anticipato.
- Chrome 152 (25 agosto 2026): la prova dell'origine (OT) e i criteri aziendali (EP) vengono attivati per i test. Questi consentono a siti e aziende di continuare a utilizzare le funzionalità dopo la data di rimozione.
- Chrome 155 (17 novembre 2026): XSLT smette di funzionare nelle release stabili per tutti gli utenti diversi dai partecipanti alla prova dell'origine e ai criteri aziendali.**
- Chrome 164 (17 agosto 2027): interruzione del funzionamento della prova dell'origine e della policy aziendale. XSLT è disattivato per tutti gli utenti.**
Che cos'è XSLT?
XSLT, o Extensible Stylesheet Language Transformations, è un linguaggio utilizzato per trasformare documenti XML, in genere in altri formati come HTML. Utilizza un file di stile XSLT per definire le regole per questa conversione e un file XML contenente i dati utilizzati come input.
Nei browser, quando viene ricevuto un file XML che rimanda a un foglio di stile XSLT, il browser utilizza le regole di questo foglio di stile per riorganizzare, formattare e convertire i dati XML non elaborati in una pagina strutturata (spesso HTML) che può essere visualizzata per l'utente.
Ad esempio, un foglio di stile XSLT potrebbe accettare il seguente input XML:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl" ?>
<page>
<message>
Hello World.
</message>
</page>
e questo foglio di stile 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>
e li elabora in questo codice HTML da visualizzare nel browser: HTML
<body>
<p>Message: Hello World.</p>
</body>
Oltre all'istruzione di elaborazione XSL mostrata nell'esempio precedente, esiste anche l'API JavaScript XSLTProcessor, che può essere utilizzata per elaborare documenti XML locali con fogli di stile XSLT locali.
Storia di XSLT
XSLT è stato consigliato dal World Wide Web Consortium (W3C) il 16 novembre 1999 come linguaggio per trasformare i documenti XML in altri formati, in genere HTML per la visualizzazione nei browser web. Prima della raccomandazione ufficiale 1.0, Microsoft ha preso un'iniziativa anticipata spedendo un'implementazione proprietaria basata su una bozza di lavoro del W3C in Internet Explorer 5.0, rilasciato a marzo 1999. Seguendo lo standard ufficiale, Mozilla ha implementato il supporto XSLT 1.0 nativo in Netscape 6 alla fine del 2000. Anche altri browser principali, tra cui Safari, Opera e Chrome successivo, hanno incorporato processori XSLT 1.0 nativi, rendendo le trasformazioni XML in HTML lato client una tecnologia web valida nei primi anni 2000.
Il linguaggio XSLT ha continuato a evolversi con il rilascio di XSLT 2.0 nel 2007 e di XSLT 3.0 nel 2017, che hanno introdotto potenti funzionalità come le espressioni regolari, i tipi di dati migliorati e la possibilità di elaborare JSON. Il supporto del browser, tuttavia, è rimasto invariato. Oggi, tutti i principali motori dei browser web forniscono solo il supporto nativo per XSLT 1.0 originale del 1999. Questa mancanza di progressi, unita all'aumento dell'utilizzo di JSON come formato di trasferimento e delle librerie e dei framework JavaScript (come jQuery, React e Vue.js) che offrono manipolazione e modelli DOM più flessibili e potenti, ha portato a un calo significativo dell'utilizzo di XSLT lato client. Il suo ruolo all'interno del browser web è stato in gran parte sostituito da queste tecnologie basate su JavaScript.
Perché è necessario rimuovere XSLT?
L'inclusione continua di XSLT 1.0 nei browser web presenta un rischio per la sicurezza significativo e non necessario. Le librerie sottostanti che elaborano queste trasformazioni, come libxslt (utilizzata dai browser Chromium), sono codebase C/C++ complesse e obsolete. Questo tipo di codice è notoriamente soggetto a vulnerabilità di sicurezza della memoria come i buffer overflow, che possono portare all'esecuzione di codice arbitrario. Ad esempio, i controlli di sicurezza e i sistemi di monitoraggio dei bug hanno ripetutamente identificato vulnerabilità di gravità elevata in questi analizzatori (ad es. CVE-2025-7425 e CVE-2022-22834, entrambi in libxslt). Poiché XSLT lato client è ora una funzionalità di nicchia usata raramente, queste librerie ricevono molta meno manutenzione e controllo della sicurezza rispetto ai motori JavaScript di base, ma rappresentano una superficie di attacco diretta e potente per l'elaborazione di contenuti web non attendibili. Infatti, XSLT è la fonte di diversi exploit di sicurezza di alto profilo recenti che continuano a mettere a rischio gli utenti del browser. I rischi per la sicurezza derivanti dal mantenimento di questa funzionalità legacy fragile superano di gran lunga la sua utilità moderna limitata.
Inoltre, lo scopo originale di XSLT lato client, ovvero trasformare i dati in HTML visualizzabile, è stato sostituito da API JavaScript più sicure, ergonomiche e con una migliore manutenzione. Lo sviluppo web moderno si basa su elementi come l'API Fetch per recuperare i dati (in genere JSON) e l'API DOMParser per analizzare in modo sicuro le stringhe XML o HTML in una struttura DOM all'interno della sandbox JavaScript sicura del browser. Framework come React, Vue e Svelte gestiscono quindi il rendering di questi dati in modo efficiente e sicuro. Questa toolchain moderna è sviluppata attivamente, beneficia dell'enorme investimento nella sicurezza dei motori JavaScript ed è quella che viene utilizzata oggi da quasi tutti gli sviluppatori web. Infatti, solo circa lo 0,02% dei caricamenti di pagine web oggi utilizza XSLT, con meno dello 0,001% che utilizza le istruzioni di elaborazione XSLT.
Questa non è un'azione esclusiva di Chrome o Chromium: anche gli altri due principali motori del browser supportano la rimozione di XSLT dalla piattaforma web: WebKit, Gecko.
Per questi motivi, il ritiro e la rimozione di XSLT riducono la superficie di attacco del browser per tutti gli utenti, semplificano la piattaforma web e consentono di concentrare le risorse di ingegneria sulla protezione delle tecnologie che alimentano effettivamente il web moderno, senza alcuna perdita pratica di funzionalità per gli sviluppatori.
Miglioramento della sicurezza dell'analisi XML
Analogamente ai gravi problemi di sicurezza in libxslt, di recente sono stati segnalati gravi problemi di sicurezza in libxml2, che viene utilizzato in Chromium per l'analisi, la serializzazione e il test della correttezza della sintassi XML. Per risolvere futuri problemi di sicurezza con l'analisi XML in Chromium, prevediamo di eliminare gradualmente l'utilizzo di libxml2 e sostituire l'analisi XML con una libreria di analisi XML sicura per la memoria scritta in Rust. È importante sottolineare che non rimuoveremo XML dal browser, ma solo XSLT. Il nostro obiettivo è garantire che la sostituzione di libxml2 sia completamente trasparente per gli sviluppatori web.
Come eseguire la migrazione
Esistono alcuni percorsi alternativi per la migrazione.
JSON
Per i siti creati interamente in XML e XSL non esiste un modo universale per eseguire la transizione. Le opzioni di migrazione includono lo spostamento della pipeline di elaborazione XSLT lato server e l'invio dell'HTML sottoposto a rendering al client oppure la migrazione degli endpoint API XML lato server a JSON e l'esecuzione del rendering lato client utilizzando JavaScript per trasformare JSON in HTML DOM e CSS.
XSLT lato client in JavaScript
Sono disponibili alcune librerie XSLT lato client (basate su JavaScript), ma la più grande è prodotta da Saxonica (consulta la documentazione completa di Saxonica). L'implementazione va ben oltre l'implementazione XSLT 1.0 nei browser web, implementando il supporto completo per l'ultimo standard v3.0 e, infine, per lo standard v4.0 in corso.
Polyfill
Esiste un polyfill che tenta di consentire al codice esistente, che dipende dalle implementazioni XSLT 1.0 dei browser web, di continuare a funzionare, senza utilizzare le funzionalità XSLT native del browser. Il polyfill si trova su GitHub.
Il polyfill contiene una sostituzione funzionale basata su WASM per la classe XSLTProcessor, in modo che il codice JavaScript esistente possa continuare a funzionare così com'è:
<script src="xslt-polyfill.min.js"></script>
<script>
const xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsltDoc);
const fragment = xsltProcessor.transformToFragment(xmlDoc, document);
</script>
Il polyfill fornisce anche una funzione di utilità automatica per sostituire facilmente i documenti XML che utilizzano istruzioni di elaborazione XSLT:
Per un file demo.xml originale come questo:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
...content...
È possibile aggiungere una riga per richiamare il polyfill e trasformare il documento con il foglio di stile XSLT a cui viene fatto riferimento:
<?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...
In questo caso, il nuovo elemento <script> carica il polyfill, che rileva il tipo di documento XML e l'istruzione di elaborazione XSLT e lo carica in modo trasparente, sostituendo il documento.
Estensione
Esiste anche un'estensione Chrome che può essere aggiunta ai browser supportati, che applicherà lo stesso polyfill XSLT a tutte le pagine XML non elaborate che contengono istruzioni di elaborazione XSLT o chiamate a XSLTProcessor. Può essere utilizzato per applicazioni in cui l'XML o l'XSLT di origine non possono essere modificati, per mantenere la funzionalità.
In particolare, quando XSLT è disabilitato, Chrome ora mostra un banner di avviso che rimanda direttamente a una pagina di ricerca delle estensioni, per aiutare gli utenti a trovare un'estensione:
Casi d'uso specifici
Nella discussione sugli standard HTML sono stati identificati diversi casi d'uso concreti. Questa sezione parla in modo specifico di ciascuna di queste opzioni, per consigliare percorsi da seguire per gli sviluppatori che pubblicano risorse XML che utilizzano XSLT oggi.
Feed RSS e Atom
In molti feed RSS o Atom esistenti, XSLT viene utilizzato per rendere i feed XML non elaborati leggibili quando vengono visualizzati direttamente in un browser. Il caso d'uso principale è che quando un utente fa clic accidentalmente sul link del feed RSS di un sito, anziché incollarlo nel proprio lettore RSS, riceve una risposta HTML formattata che può leggere, anziché l'XML non elaborato.
Esistono due percorsi per questo caso d'uso. Il modo "standard" in HTML per farlo è aggiungere <link rel="alternate" type="application/rss+xml"> a un sito (basato su HTML), anziché aggiungere un <a
href="something.xml"> esplicito (visibile all'utente) su cui gli utenti potrebbero fare clic per errore. Questa soluzione consente
ai lettori RSS di trovare il feed se un utente incolla solo l'URL del sito web, ma
consente anche agli utenti umani di visualizzare i normali contenuti HTML senza confondersi
con un link a una risorsa XML. Ciò segue anche il normale paradigma web secondo cui
l'HTML è per gli esseri umani e l'XML è per le macchine. Naturalmente, questo non risolve il
caso in cui un utente "ha" semplicemente un link RSS da qualche parte e lo incolla nel
browser web (anziché nel lettore RSS).
Quando questa soluzione non è desiderata, il polyfill offre un altro percorso. Come accennato
in precedenza, il feed XML RSS/Atom può essere arricchito con una riga, <script
src="xslt-polyfill.min.js"
xmlns="[http://www.w3.org/1999/xhtml](http://www.w3.org/1999/xhtml)"></script>,
che manterrà il comportamento esistente della trasformazione basata su XSLT in HTML.
Ciò non dovrebbe influire sulla capacità del lettore RSS di continuare ad analizzare il codice XML, poiché
<script> è un elemento secondario diretto dell'elemento radice.
Output dell'API per i dispositivi incorporati
Alcuni dispositivi incorporati commerciali misurano o generano in altro modo dati XML per
l'utilizzo da parte degli utenti sulla rete locale. Alcuni di questi dispositivi lo fanno
generando un singolo feed di dati XML che utilizza XSLT per trasformarlo in un
formato HTML leggibile. In questo modo, l'API può essere visualizzata direttamente in un browser senza bisogno di codice aggiuntivo sul dispositivo o nel browser.
Poiché si tratta di un caso d'uso molto specifico per l'applicazione, la forma della soluzione potrebbe variare. Per le applicazioni in cui è possibile aggiornare il codice sorgente del dispositivo incorporato, può funzionare una qualsiasi delle opzioni descritte in precedenza (JSON, Polyfill). In
particolare, tuttavia, molti di questi dispositivi sono difficili o impossibili da aggiornare,
per vari motivi. In questo caso, l'estensione è probabilmente l'opzione migliore, in quanto consente ai browser client di continuare a leggere i dati esattamente nello stesso modo, senza modificare il dispositivo.
Modelli lazy per i siti web
A volte gli sviluppatori web utilizzano XSLT sul lato client per applicare il markup di presentazione al markup semantico, fungendo da linguaggio di templating lazy separato dall'ecosistema JavaScript.
Esistono due soluzioni a questo problema più generale. Per un sito esistente creato in questo modo, la soluzione più semplice è probabilmente quella di aggiungere il polyfill per mantenere la funzionalità esistente. Oppure, esegui la trasformazione XSLT sul lato server e pubblica l'HTML risultante per il client, anziché l'XML non elaborato. La soluzione a lungo termine per queste proprietà sarebbe la migrazione a un framework più moderno basato su JavaScript o JSON.