A metà dicembre 2026 Microsoft Edge 159 disattiverà per impostazione predefinita il supporto nativo a XSLT nel browser, con Chrome che si muove in parallelo. Per la maggior parte dei siti moderni il cambiamento passerà inosservato, ma per chi gestisce infrastrutture Windows Server con RD Web Access il rischio è concreto: l’interfaccia di accesso remoto dipende ancora da XSLT per il rendering, e senza interventi potrebbe smettere di caricarsi dall’oggi al domani. Vediamo cosa cambia, perché Microsoft lo sta facendo e quali contromisure adottare prima della scadenza.

Perché XSLT viene eliminato dai browser

XSLT (eXtensible Stylesheet Language Transformations) è lo standard, nato a cavallo degli anni 2000, che permette di trasformare documenti XML in HTML, testo o altri formati XML direttamente lato client, tramite l’API JavaScript XSLTProcessor o una processing instruction XML che referenzia un foglio di stile .xsl. Nei browser basati su Chromium (e quindi anche in Edge) l’elaborazione XSLT è gestita da libxslt, una libreria nativa scritta in C che non riceve aggiornamenti sostanziali da anni.

Il problema è proprio questo: libxslt elabora contenuti XML potenzialmente non attendibili con un motore nativo datato, ampliando la superficie d’attacco a fronte di un utilizzo ormai marginale nel web moderno, dove le trasformazioni XML→HTML si fanno quasi sempre lato server o con librerie JavaScript. Microsoft e Google hanno quindi deciso, in coordinamento, di rimuovere il motore nativo e lasciare che siano gli sviluppatori a migrare verso alternative più sicure.

Le date da segnare in calendario

Il rollout è scaglionato in due fasi distinte, comunicate da Microsoft tramite il Message Center (riferimento MC1509789):

• Edge 159 (metà dicembre 2026): XSLT nativo disattivato per impostazione predefinita, worldwide, inclusi gli ambienti GCC, GCC High e DoD. Resta disponibile una policy temporanea per riattivarlo.
• Edge 176 (estate 2027): rimozione completa della policy temporanea e del motore XSLT. Da questo momento non ci sarà più alcun modo di riabilitarlo lato browser.

Sono coinvolti l’oggetto XSLTProcessor e le processing instruction XML che puntano a fogli di stile XSLT; quelle che referenziano CSS non sono interessate. Un avviso precedente (MC1491832) aveva già segnalato, per metà novembre 2026, rischi di rendering failure legati a XSLT su RD Web Access: le tempistiche comunicate da Microsoft in annunci diversi non sono sempre perfettamente allineate, quindi conviene considerare dicembre 2026 come finestra di sicurezza entro cui completare la verifica, senza aspettare l’ultimo giorno.

Il caso concreto: RD Web Access su Windows Server

Il portale RD Web Access (Accesso Web ai Desktop remoti), componente dei Servizi Desktop remoto su Windows Server, utilizza ancora XSLT per il rendering lato client delle pagine. Quando il browser disattiva XSLT, gli utenti che tentano di accedere al portale possono trovarsi di fronte a una pagina bianca, un errore di rendering o un comportamento anomalo nell’elenco di RemoteApp e desktop pubblicati. Microsoft ha pubblicato una nota di supporto dedicata (KB5130994, “RD Web Access fails to load when XSLT is disabled in Microsoft Edge or Google Chrome”) proprio per questo scenario.

È un impatto che riguarda una fetta minoritaria ma non trascurabile di organizzazioni: molte aziende italiane usano ancora RD Web Access per il lavoro remoto o per pubblicare applicazioni legacy, specialmente dove Azure Virtual Desktop o soluzioni VDI più moderne non sono state ancora adottate.

Come verificare se la tua organizzazione è a rischio

Prima di intervenire, conviene fare un inventario delle applicazioni interne che potrebbero dipendere da XSLT. Microsoft suggerisce di usare Lighthouse, integrato negli strumenti di sviluppo di Edge:

1. Apri l’applicazione da verificare in una versione aggiornata di Edge ed esegui l’accesso, se richiesto.
2. Premi F12 (o Ctrl+Shift+I) per aprire i DevTools, quindi seleziona il pannello Lighthouse (in “More tools” se non visibile).
3. Imposta Mode su Navigation e Category su Best Practices.
4. Per le applicazioni autenticate, disattiva l’opzione “Clear storage” nelle impostazioni di Lighthouse, così da non perdere la sessione.
5. Avvia “Analyze page load” e cerca nel report voci relative a XSLT, deprecated API o XSLTProcessor, controllando in particolare le sezioni “Uses deprecated APIs” e gli avvisi nel pannello Issues dei DevTools.
6. Ripeti il test per ogni pagina e flusso applicativo rilevante, non solo per la home page.

Per RD Web Access non serve nemmeno il test: se il server è ancora basato sui componenti classici dei Servizi Desktop remoto (non il nuovo client web HTML5), va messo in lista a prescindere.

Le tre strade per mettersi al riparo

1. Riattivare temporaneamente XSLT con la policy XSLTEnabled

È la soluzione tampone più rapida, pensata per guadagnare tempo mentre si pianifica la migrazione vera e propria. La policy XSLTEnabled è disponibile sia per Edge sia, con lo stesso nome, per Chrome.

Da riga di comando elevata (Prompt dei comandi come amministratore), per Edge:

reg add "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v XSLTEnabled /t REG_DWORD /d 1 /f

Per Chrome:

reg add "HKLM\SOFTWARE\Policies\Google\Chrome" /v XSLTEnabled /t REG_DWORD /d 1 /f

In alternativa, tramite Criteri di gruppo (GPO), su un ambiente di dominio:

1. Apri la Console di gestione dei criteri di gruppo e modifica (o crea) il GPO da applicare ai server/client interessati.
2. Vai in Configurazione computer → Modelli amministrativi → Microsoft Edge (il template ADMX è MSEdge.admx, da importare nel repository centrale se non già presente).
3. Apri la voce Control the availability of the XSLT feature, impostala su Enabled e salva.
4. Collega il GPO all’unità organizzativa che contiene i server RD Web Access o i client interessati, poi forza l’aggiornamento con gpupdate /force.

Importante: la policy è temporanea e verrà rimossa con Edge 176 (estate 2027) insieme al motore XSLT, quindi non va considerata una soluzione definitiva ma solo una finestra per completare la migrazione.

2. Migrare al client web HTML5 di Desktop remoto

La soluzione strutturale per RD Web Access è passare al client web moderno, che non dipende da XSLT. È raggiungibile all’indirizzo:

https://<nome_server_rdweb>/RDWeb/webclient/index.html

sostituendo <nome_server_rdweb> con l’FQDN del server. Il client HTML5 richiede però una configurazione preliminare lato server (ruolo RD Web Access aggiornato, certificati validi, eventuale pubblicazione tramite RD Gateway) che va pianificata e testata prima del passaggio in produzione: non è un semplice cambio di URL da comunicare agli utenti.

3. Usare la modalità Internet Explorer di Edge come ripiego

Per scenari in cui non è possibile intervenire rapidamente sul server, Edge offre la modalità di compatibilità Internet Explorer, che Microsoft prevede di mantenere disponibile almeno fino al 2029:

1. Apri Impostazioni → Browser predefinito in Edge.
2. Attiva l’opzione “Consenti il ricaricamento dei siti in modalità Internet Explorer”.
3. Aggiungi l’URL del portale RD Web Access all’elenco “Pagine in modalità Internet Explorer”.

Al primo accesso il browser potrebbe chiedere di abilitare ActiveX, necessario per il single sign-on: un dettaglio da comunicare in anticipo agli utenti per evitare segnalazioni al service desk. È comunque solo un ponte verso una delle due soluzioni precedenti, non una destinazione finale.

Checklist operativa per i sysadmin

Un piano d’azione ragionevole prima di dicembre 2026:

• Censire le applicazioni interne (RD Web Access incluso) che usano XSLT, con il test Lighthouse descritto sopra.
• Applicare da subito, in via precauzionale, la policy XSLTEnabled sui server e client che accedono a RD Web Access, per evitare interruzioni impreviste al rollout di Edge 159.
• Pianificare e testare in un ambiente non di produzione la migrazione al client web HTML5 di RD Web Access.
• Per applicazioni custom con output XSLT lato client, valutare la trasformazione lato server o librerie JavaScript indipendenti dal motore nativo del browser.
• Monitorare i prossimi annunci nel Message Center, perché le date comunicate finora non sono sempre coerenti tra loro.

Conclusione

La rimozione di XSLT dai browser Chromium è un classico esempio di debito tecnico che arriva a scadenza: una tecnologia poco usata ma con una dipendenza nascosta in un componente critico come RD Web Access. Microsoft ha lasciato una finestra ragionevole e una policy di riattivazione temporanea per gestire la transizione senza fretta, ma come spesso accade la scadenza reale arriverà più vicina di quanto sembri: vale la pena verificare oggi, non a dicembre, se la propria infrastruttura è tra quelle a rischio.

Fonte: 4sysops.com, con riferimenti a Microsoft Message Center (MC1509789, MC1491832) e Microsoft Learn.