Data di pubblicazione: 29 ottobre 2025
Chrome intende ritirare e rimuovere XSLT dal browser. Questo documento descrive come eseguire la migrazione del codice prima della rimozione alla fine del 2026.
Chromium ha ritirato ufficialmente XSLT, tra cui l'API JavaScript XSLTProcessor e l'istruzione di elaborazione XSLT. Prevediamo di rimuovere il supporto dalla versione 158 (17 novembre 2026). Anche i progetti Firefox e WebKit hanno indicato l'intenzione di rimuovere XSLT dai loro motori di browser. Questo documento fornisce alcuni cenni storici e informazioni di 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. Per gli aggiornamenti più recenti, consulta anche la voce di Chrome Platform Status.
Cosa verrà 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 type="text/xsl" ... ?>).
Cronologia per Chrome
Chrome ha il seguente piano:
- Chrome 142 (28 ottobre 2025): aggiunta di messaggi della console di avviso preventivo a 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 tempestivo.
- Chrome 146 (10 marzo 2026): viene avviata la fase di test per la policy aziendale (EP). In questo modo, le aziende possono testare la disattivazione di XSLT in anticipo e continuare a utilizzare le funzionalità dopo la data di rimozione.
- Chrome 152 (25 agosto 2026): viene avviata la fase di test per l'origin trial (OT). In questo modo, i siti possono continuare a utilizzare le funzionalità dopo la data di rimozione.
- Chrome 154 (22 settembre 2026): le release Canary, Dev e Beta di Webview iniziano a disattivare XSLT per impostazione predefinita, come avviso preventivo.
- Chrome 158 (17 novembre 2026): XSLT smetterà di funzionare nelle release stabili per tutti gli utenti, ad eccezione dei partecipanti a Origin Trial e Enterprise Policy.
- Chrome 176 (17 agosto 2027): l'origin trial e la policy aziendale smettono 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 di quel foglio di stile per riorganizzare, formattare e convertire i dati XML non elaborati in una pagina strutturata (spesso HTML) che può essere visualizzata dall'utente.
Ad esempio, un foglio di stile XSLT potrebbe accettare il seguente input XML:
<?xml version=">1<.0"?
?xml-stylesheet type="text/xsl&quo>t<; hr>ef<=">demo.xsl" ?
<page
me>s<sage
> Hello World.
/message
/page
e questo foglio di stile XSL:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Trans>for<m"
xsl:output meth>od=<"html"/
xsl:template m>atch=<&quo>t;/page</>message&q<uot;
body
pMes><sa>ge: x<sl:va>lue<-of select=&q>u<ot;."//p
> /body
/xsl:template
/xsl:stylesheet
e li elabora in questo codice HTML per la visualizzazione 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 la trasformazione di documenti XML in altri formati, più comunemente HTML per la visualizzazione nei browser web. Prima della raccomandazione ufficiale 1.0, Microsoft ha preso l'iniziativa di spedire un'implementazione proprietaria basata su una bozza di lavoro del W3C in Internet Explorer 5.0, rilasciata 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, in seguito, Chrome, hanno incorporato processori XSLT 1.0 nativi, rendendo le trasformazioni XML-HTML lato client una tecnologia web praticabile nei primi anni 2000.
Il linguaggio XSLT stesso 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, tipi di dati migliorati e la possibilità di elaborare JSON. Tuttavia, il supporto dei browser è rimasto invariato. Oggi, tutti i principali motori dei 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 rete e di librerie e framework JavaScript (come jQuery, React e Vue.js) che offrono una manipolazione DOM e un templating 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 tracker dei bug 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. In effetti, XSLT è all'origine di diversi recenti exploit di sicurezza di alto profilo che continuano a mettere a rischio gli utenti dei browser. I rischi per la sicurezza legati al mantenimento di questa funzionalità legacy fragile superano di gran lunga la sua limitata utilità moderna.
Inoltre, lo scopo originale di XSLT lato client, ovvero la trasformazione dei dati in HTML visualizzabile, è stato sostituito da API JavaScript più sicure, ergonomiche e gestite meglio. 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 è in fase di sviluppo attivo, beneficia degli enormi investimenti in sicurezza nei motori JavaScript ed è ciò che praticamente tutti gli sviluppatori web utilizzano oggi. In effetti, 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 principali motori di 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 progettazione 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 relativi a libxml2, che viene utilizzato in Chromium per l'analisi, la serializzazione e il test della correttezza del formato XML. Per risolvere i futuri problemi di sicurezza relativi all'analisi XML in Chromium, prevediamo di eliminare gradualmente l'utilizzo di libxml2 e di 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. Vogliamo assicurarci che la sostituzione di libxml2 sia completamente trasparente per gli sviluppatori web.
XML + CSS non vengono rimossi
È importante distinguere il ritiro di XSLT (<?xml-stylesheet type="text/xsl" ... ?>) dall'istruzione di elaborazione <?xml-stylesheet ... ?> 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 progettazione standard ai dati non elaborati, proprio come puoi fare con l'HTML. Ad esempio:
<?xml version="1.0" encodin>g<="UTF-8"?
?xml-stylesheet type="tex>t</css>&qu<ot; >href="s<tyles>.<css&q>uot;?
root
itemContent 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 unico per effettuare 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 in assoluto è prodotta da Saxonica (consulta la documentazione completa di Saxonica). L'implementazione va ben oltre l'implementazione di 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 di sviluppo.
Polyfill
Esiste un polyfill che tenta di consentire al codice esistente, che dipende dalle implementazioni di 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.mi><n.js&qu>ot<;/scri>pt
script
const xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsltDoc);
const fragment = xsltProcessor.transformToFragment(xmlDoc, d<ocument>);
/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&qu>o<t; h>ref="demo.xsl"?
ROOT
...content...
È possibile aggiungere una riga per richiamare il polyfill e trasformare il documento con il foglio di stile XSLT di riferimento:
<?xml version=">1<.0"?
?xml-stylesheet type="text/xsl&qu>o<t; h>r<ef="demo.xsl"?
ROOT
script src="xslt-polyfill.min.js"><
xml>ns="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
È disponibile anche un'estensione di 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. Questo criterio può essere utilizzato per le applicazioni in cui l'XML o l'XSLT di origine non può essere modificato, 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 trovarne una:
Casi d'uso specifici
Nella discussione sugli standard HTML, sono stati identificati diversi casi d'uso concreti. Questa sezione illustra in dettaglio ciascuna di queste opzioni per consigliare i percorsi da seguire agli 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 involontariamente sul link del feed RSS di un sito, anziché incollare il link 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 HTML "standard" 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 involontariamente. 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. Questo 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" un link RSS da qualche parte e lo incolla nel browser web (anziché nel lettore RSS).
Quando questa soluzione non è quella desiderata, il polyfill offre un'altra strada. Come accennato in precedenza, il feed XML RSS/Atom può essere migliorato 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.
Ciò non dovrebbe influire sulla capacità del lettore RSS di continuare ad analizzare l'XML, poiché <script> è un elemento secondario diretto dell'elemento root.
Output dell'API per i dispositivi incorporati
Alcuni dispositivi commerciali incorporati misurano o generano in altro modo dati XML per l'utilizzo da parte degli utenti sulla rete locale. Alcuni di questi dispositivi generano 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 il codice sorgente del dispositivo incorporato può essere aggiornato, potrebbe 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, poiché consente ai browser client di continuare a leggere i dati esattamente nello stesso modo, senza modificare il dispositivo.
Modelli lazy per i siti web
Gli sviluppatori web a volte utilizzano XSLT lato client per applicare il markup di presentazione al markup semantico, che funge da linguaggio di creazione 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 fornire al client l'HTML risultante, anziché l'XML non elaborato. La soluzione più 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 alcuni modi. Questa sezione ne illustra due.
L'API Reporting
L'API Reporting è un meccanismo di generazione di report generico che le applicazioni web possono utilizzare per generare report su varie funzionalità e condizioni della piattaforma, tra cui il ritiro delle funzionalità. Per configurarlo 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();
Guarda questo codice in azione su CodePen.
Report sulla tecnologia precedente aziendale
Per gli amministratori di un'azienda, il report sulle tecnologie legacy può essere utilizzato per raccogliere automaticamente l'utilizzo delle funzionalità ritirate e segnalarlo in modo semplice. Per saperne di più su come attivare questa funzionalità, consulta questo articolo dell'Assistenza Google.