Pubblicato il 29 ottobre 2025
Chrome intende ritirare e rimuovere XSLT dal browser. Questo documento spiega come eseguire la migrazione del codice prima della rimozione alla fine del 2026.
Chromium ha ritirato ufficialmente XSLT, inclusa l' XSLTProcessor e l'istruzione di elaborazione XSLT. Intendiamo rimuovere il supporto dalla versione 158 (17 novembre 2026). Anche i progetti Firefox e WebKit hanno indicato di voler rimuovere XSLT dai rispettivi motori di browser. Questo documento fornisce alcuni cenni storici e un po' di contesto, spiega perché stiamo rimuovendo XSLT per rendere Chrome più sicuro e fornisce un percorso per la migrazione prima che queste funzionalità vengano rimosse dal browser. Per gli ultimi aggiornamenti, consulta anche la voce Stato della piattaforma Chrome.
Che cosa verrà rimosso?
Nel browser sono presenti due API che implementano XSLT ed entrambe verranno rimosse:
- La
XSLTProcessor
XSLTProcessor (ad esempio,
new XSLTProcessor()). - L'istruzione di elaborazione XSLT (ad esempio,
<?xml-stylesheet type="text/xsl" ... ?>).
Cronologia per Chrome
Chrome ha il seguente piano:
- Chrome 142 (28 ottobre 2025): sono stati aggiunti messaggi di avviso anticipato alla console di Chrome.
- 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 145 (2 dicembre 2025 Canary): le release Canary, Dev e Beta iniziano a disattivare XSLT per impostazione predefinita, come avviso anticipato.
- Chrome 146 (10 marzo 2026): la policy aziendale (EP) diventa attiva per i test. In questo modo, le aziende possono testare la disattivazione anticipata di XSLT e continuare a utilizzare le funzionalità dopo la data di rimozione.
- Chrome 152 (25 agosto 2026): La prova dell'origine (OT) diventa attiva per i test. In questo modo, i siti possono continuare a utilizzare le funzionalità dopo la data di rimozione.
- Chrome 158 (17 novembre 2026): XSLT smetterà di funzionare nelle release stabili per tutti gli utenti, ad eccezione dei partecipanti alla prova dell'origine e alla policy aziendale.
- Chrome 176 (17 agosto 2027): la prova dell'origine e la policy aziendale smetteranno di funzionare. XSLT è disattivato per tutti gli utenti.
Che cos'è XSLT?
XSLT, o Extensible Stylesheet Language Transformations, è un linguaggio utilizzato per trasformare i documenti XML, in genere in altri formati come HTML. Utilizza un file di foglio 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 del 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 trasformarli 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.
Cronologia di XSLT
Il 16 novembre 1999, il World Wide Web Consortium (W3C) ha consigliato XSLT 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 l'iniziativa di distribuire un'implementazione proprietaria basata su una bozza di lavoro W3C in Internet Explorer 5.0, rilasciato nel marzo 1999. Seguendo lo standard ufficiale, Mozilla ha implementato il supporto nativo di XSLT 1.0 in Netscape 6 alla fine del 2000. Anche altri browser principali, tra cui Safari, Opera e successivamente Chrome, hanno incorporato processori XSLT 1.0 nativi, rendendo le trasformazioni XML-HTML lato client una tecnologia web praticabile all'inizio degli anni 2000.
Il linguaggio XSLT ha continuato a evolversi, con il rilascio di XSLT 2.0 nel 2007 e XSLT 3.0 nel 2017, che hanno introdotto funzionalità potenti come le espressioni regolari, i tipi di dati migliorati e la possibilità di elaborare JSON. Tuttavia, il supporto dei browser è rimasto invariato. Oggi, tutti i principali motori di browser web forniscono solo il supporto nativo per l'XSLT 1.0 originale del 1999. Questa mancanza di progressi, unita all'aumento dell'utilizzo di JSON come formato di trasmissione e di librerie e framework JavaScript (come jQuery, React e Vue.js) che offrono una manipolazione e un'applicazione di 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 ampiamente sostituito da queste tecnologie basate su JavaScript.
Perché è necessario rimuovere XSLT?
La continua inclusione 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 datate. 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 bug tracker hanno ripetutamente identificato vulnerabilità di gravità elevata in questi parser (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 vengono sottoposte a una manutenzione e un controllo di sicurezza decisamente inferiori 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 recenti exploit di sicurezza di alto profilo che continuano a mettere a rischio gli utenti dei browser. I rischi per la sicurezza derivanti dalla manutenzione di questa funzionalità precedente e fragile superano di gran lunga la sua utilità moderna limitata.
Inoltre, lo scopo originale di XSLT lato client, ovvero la trasformazione dei dati in HTML visualizzabile, è stato sostituito da API JavaScript più sicure, più ergonomiche e con una manutenzione migliore. 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. I framework come React, Vue e Svelte gestiscono quindi il rendering di questi dati in modo efficiente e sicuro. Questa toolchain moderna è in fase di sviluppo attivo, beneficia dell'enorme investimento in sicurezza nei motori JavaScript ed è quella utilizzata oggi da quasi tutti gli sviluppatori web. Infatti, oggi solo lo 0,02% circa dei caricamenti di pagine web utilizza effettivamente 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 motori di browser principali 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 progettazione sulla protezione delle tecnologie che alimentano effettivamente il web moderno, senza alcuna perdita pratica di funzionalità per gli sviluppatori.
Migliorare la sicurezza dell'analisi XML
Analogamente ai gravi problemi di sicurezza in libxslt, gravi problemi di sicurezza sono stati recentemente segnalati in libxml2, che viene utilizzato in Chromium per l'analisi, la serializzazione e il test della validità di XML. Per risolvere i 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 stiamo prendendo in considerazione solo la rimozione di XSLT. Intendiamo garantire che la sostituzione di libxml2 sia completamente trasparente per gli sviluppatori web.
XML + CSS non verrà rimosso
È importante distinguere il ritiro di XSLT
(<?xml-stylesheet type="text/xsl" ... ?>) dall'
<?xml-stylesheet ... ?>istruzione di elaborazione stessa, che rimane supportata
se utilizzata con CSS. Puoi comunque utilizzare l'istruzione di elaborazione con
type="text/css" per applicare regole di layout e design standard ai dati non elaborati,
proprio come puoi fare con HTML. Ad esempio:
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="styles.css"?>
<root>
<item>Content here</item>
</root>
Come eseguire la migrazione
Esistono alcuni percorsi alternativi per la migrazione.
JSON
Per i siti completamente basati su XML e XSL, non esiste un modo univoco per eseguire la transizione. Le opzioni di migrazione includono lo spostamento della pipeline di elaborazione XSLT sul 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 è quella 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 v3.0 standard, e infine 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 le 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 si fa 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 <script> elemento 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 e che applicherà lo stesso polyfill XSLT a tutte le pagine XML non elaborate che contengono istruzioni di elaborazione XSLT o chiamate a XSLTProcessor. Questa estensione può essere utilizzata per le applicazioni in cui l'XML o l'XSLT di origine non possono essere modificati, per mantenere la funzionalità.
In particolare, quando XSLT è disattivato, 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 ciascuno di essi, per consigliare i 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 dagli utenti 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 lettore RSS, riceve una risposta HTML formattata che può leggere, anziché l'XML non elaborato.
Esistono due percorsi da seguire per questo caso d'uso. Il modo HTML "standard" per fare
questo è 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 accidentalmente. 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 contenuti HTML normali senza confondersi con un link a una risorsa XML. Questo segue anche il normale paradigma web secondo cui HTML è per gli esseri umani e XML è per le macchine. Naturalmente, questo non risolve il caso in cui un utente "ha" un link RSS da qualche parte e lo incolla nel browser web (anziché nel lettore RSS).
Quando non è desiderata, la soluzione polyfill offre un altro percorso. Come accennato
in precedenza, il feed XML RSS/Atom può essere aumentato con una riga, <script
src="xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script>,
che manterrà il comportamento esistente della trasformazione basata su XSLT in HTML.
Questo non dovrebbe influire sulla capacità del lettore RSS di continuare ad analizzare l'XML, poiché
il <script> è un elemento secondario diretto dell'elemento root.
Output API per dispositivi incorporati
Alcuni dispositivi incorporati commerciali misurano o generano dati XML per il consumo 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 la necessità di codice aggiuntivo sul dispositivo o nel browser.
Poiché si tratta di un caso d'uso molto specifico dell'applicazione, la forma della soluzione potrebbe variare. Per le applicazioni in cui è possibile aggiornare il codice sorgente del dispositivo incorporato, è possibile utilizzare una 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.
Applicazione di modelli lazy per i siti web
A volte gli sviluppatori web utilizzano XSLT lato client per applicare il markup di presentazione al markup semantico, fungendo da linguaggio di applicazione di modelli 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. In alternativa, puoi eseguire la trasformazione XSLT sul lato server e inviare l'HTML risultante al 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.
Se riscontri un problema specifico in Chrome relativo a questo ritiro di XSLT, segnala un bug qui.
Come rilevare l'utilizzo di XSLT
In genere, le funzionalità ritirate come XSLT possono essere rilevate nel codebase in diversi modi. Questa sezione ne descrive due.
L'API Reporting
L'API Reporting è un meccanismo di reporting generico per le applicazioni web che consente di generare report su varie funzionalità e condizioni della piattaforma, inclusi i ritiri di funzionalità. Per configurarla in modo da generare report sul ritiro di XSLT, puoi utilizzare uno snippet di codice simile al seguente:
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();
Vedi questo codice in azione su CodePen.
Il report sulla tecnologia precedente aziendale
Per gli amministratori di un'azienda, il report sulla tecnologia precedente può essere utilizzato per raccogliere automaticamente l'utilizzo delle funzionalità ritirate e segnalarle in modo intuitivo. Per ulteriori informazioni su come attivare questa funzionalità, consulta questo articolo del Centro assistenza Google.