Publicado em: 29 de outubro de 2025
O Chrome pretende descontinuar e remover o XSLT do navegador. Este documento detalha como migrar seu código antes da remoção no final de 2026.
O Chromium desativou oficialmente o XSLT, incluindo a API JavaScript XSLTProcessor e a instrução de processamento de folha de estilo XML. Vamos remover o suporte da versão 155 (17 de novembro de 2026). Os projetos Firefox e WebKit também indicaram planos de remover o XSLT dos mecanismos de navegador. Este documento fornece um pouco de histórico e contexto, explica como estamos removendo XSLT para tornar o Chrome mais seguro e oferece um caminho para migrar antes que esses recursos sejam removidos do navegador.
O que está sendo removido?
Há duas APIs no navegador que implementam XSLT, e ambas estão sendo removidas:
- A classe
XSLTProcessor (por exemplo,
new XSLTProcessor()). - A instrução de processamento XSLT (por exemplo,
<?xml-stylesheet … ?>).
Linha do tempo para Chrome
O Chrome tem o seguinte plano:
- Chrome 142 (28 de outubro de 2025): mensagens de console de alerta antecipado adicionadas ao Chrome.
- Chrome 143 (2 de dezembro de 2025): descontinuação oficial da API. As mensagens de aviso de descontinuação começam a aparecer no console e no Lighthouse.
- Chrome 148 (10 de março de 2026, Canary): as versões Canary, Dev e Beta começam a desativar o XSLT por padrão como um alerta antecipado.
- Chrome 152 (25 de agosto de 2026): o teste de origem (TO) e a política empresarial (PE) serão lançados para testes. Isso permite que sites e empresas continuem usando recursos após a data de remoção.
- Chrome 155 (17 de novembro de 2026): o XSLT vai parar de funcionar nas versões estáveis para todos os usuários, exceto os participantes do teste de origem e da política empresarial.**
- Chrome 164 (17 de agosto de 2027): o teste de origem e a política empresarial param de funcionar. A XSLT está desativada para todos os usuários.**
O que é XSLT?
XSLT, ou Extensible Stylesheet Language Transformations, é uma linguagem usada para transformar documentos XML, geralmente em outros formatos, como HTML. Ele usa um arquivo de folha de estilo XSLT para definir as regras dessa conversão e um arquivo XML que contém os dados usados como entrada.
Nos navegadores, quando um arquivo XML vinculado a uma folha de estilo XSLT é recebido, o navegador usa as regras dessa folha de estilo para reorganizar, formatar e converter os dados XML brutos em uma página estruturada (geralmente HTML) que pode ser renderizada para o usuário.
Por exemplo, uma folha de estilo XSLT pode usar a seguinte entrada XML:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl" ?>
<page>
<message>
Hello World.
</message>
</page>
e esta folha de estilo 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 processe-os neste HTML para que o navegador mostre: HTML
<body>
<p>Message: Hello World.</p>
</body>
Além da instrução de processamento XSL mostrada no exemplo anterior, também há a API JavaScript XSLTProcessor, que pode ser usada para processar documentos XML locais com folhas de estilo XSLT locais.
Histórico do XSLT
A XSLT foi recomendada pelo World Wide Web Consortium (W3C) em 16 de novembro de 1999 como uma linguagem para transformar documentos XML em outros formatos, mais comumente HTML para exibição em navegadores da Web. Antes da recomendação oficial 1.0, a Microsoft tomou uma iniciativa antecipada ao enviar uma implementação proprietária com base em um rascunho de trabalho do W3C no Internet Explorer 5.0, lançado em março de 1999. Seguindo o padrão oficial, a Mozilla implementou o suporte nativo ao XSLT 1.0 no Netscape 6 no final de 2000. Outros navegadores importantes, incluindo Safari, Opera e versões mais recentes do Chrome, também incorporaram processadores XSLT 1.0 nativos, tornando as transformações de XML para HTML do lado do cliente uma tecnologia da Web viável no início dos anos 2000.
A linguagem XSLT continuou evoluindo com o lançamento do XSLT 2.0 em 2007 e do XSLT 3.0 em 2017, que introduziram recursos avançados como expressões regulares, tipos de dados aprimorados e a capacidade de processar JSON. No entanto, o suporte a navegadores ficou estagnado. Hoje, todos os principais mecanismos de navegadores da Web oferecem apenas suporte nativo para o XSLT 1.0 original de 1999. Essa falta de avanço, aliada ao aumento do uso de JSON como formato de transmissão e bibliotecas e frameworks JavaScript (como jQuery, React e Vue.js) que oferecem manipulação e criação de modelos DOM mais flexíveis e poderosas, levou a um declínio significativo no uso de XSLT do lado do cliente. O papel dele no navegador foi amplamente substituído por essas tecnologias baseadas em JavaScript.
Por que o XSLT precisa ser removido?
A inclusão contínua do XSLT 1.0 em navegadores da Web apresenta um risco de segurança significativo e desnecessário. As bibliotecas subjacentes que processam essas transformações, como libxslt (usada pelos navegadores Chromium), são bases de código C/C++ complexas e antigas. Esse tipo de código é notoriamente suscetível a vulnerabilidades de segurança de memória, como estouros de buffer, que podem levar à execução de código arbitrário. Por exemplo, auditorias de segurança e rastreadores de bugs identificaram repetidamente vulnerabilidades de alta gravidade nesses analisadores (por exemplo, CVE-2025-7425 e CVE-2022-22834, ambos em libxslt). Como o XSLT do lado do cliente agora é um recurso de nicho e raramente usado, essas bibliotecas recebem muito menos manutenção e análise de segurança do que os mecanismos principais do JavaScript. No entanto, elas representam uma superfície de ataque direta e potente para processar conteúdo da Web não confiável. Na verdade, o XSLT é a origem de várias vulnerabilidades de segurança de alto perfil recentes que continuam colocando em risco os usuários de navegadores. Os riscos de segurança de manter essa funcionalidade legada e frágil superam em muito sua utilidade moderna limitada.
Além disso, a finalidade original da XSLT no lado do cliente (transformar dados em HTML renderizável) foi substituída por APIs JavaScript mais seguras, ergonômicas e melhor mantidas. O desenvolvimento da Web moderno depende de coisas como a API Fetch para recuperar dados (normalmente JSON) e a API DOMParser para analisar com segurança strings XML ou HTML em uma estrutura DOM no sandbox seguro do JavaScript do navegador. Frameworks como React, Vue e Svelte gerenciam a renderização desses dados de maneira eficiente e segura. Essa cadeia de ferramentas moderna é desenvolvida ativamente, se beneficia do grande investimento em segurança nos mecanismos JavaScript e é usada por praticamente todos os desenvolvedores da Web hoje em dia. Na verdade, apenas cerca de 0,02% dos carregamentos de páginas da Web hoje usam XSLT, e menos de 0,001% usam instruções de processamento de XSLT.
Essa não é uma ação exclusiva do Chrome ou do Chromium: os outros dois principais mecanismos de navegador também oferecem suporte à remoção do XSLT da plataforma da Web: WebKit e Gecko.
Por esses motivos, a descontinuação e a remoção do XSLT reduzem a superfície de ataque do navegador para todos os usuários, simplificam a plataforma da Web e permitem que os recursos de engenharia se concentrem na proteção das tecnologias que realmente impulsionam a Web moderna, sem perda prática de capacidade para os desenvolvedores.
Melhorar a segurança da análise de XML
Semelhante aos graves problemas de segurança no libxslt, graves problemas de segurança foram relatados recentemente no libxml2, que é usado no Chromium para análise, serialização e teste da integridade do XML. Para resolver futuros problemas de segurança com a análise XML no Chromium, planejamos descontinuar o uso da libxml2 e substituir a análise XML por uma biblioteca de análise XML com segurança de memória escrita em Rust. É importante lembrar que não vamos remover o XML do navegador. Apenas o XSLT está sendo considerado para remoção. Queremos garantir que a substituição da libxml2 seja totalmente transparente para os desenvolvedores da Web.
Como migrar
Há alguns caminhos alternativos para a migração.
JSON
Para sites totalmente criados em XML e XSL, não há uma maneira única de fazer a transição. As opções de migração incluem mover o pipeline de processamento XSLT para o lado do servidor e enviar o HTML renderizado para o cliente ou migrar endpoints da API XML do lado do servidor para JSON e realizar a renderização do lado do cliente usando JavaScript para transformar JSON em HTML DOM e CSS.
XSLT do lado do cliente em JavaScript
Há algumas bibliotecas XSLT do lado do cliente (baseadas em JavaScript) disponíveis, mas a maior de todas é produzida pela Saxonica (consulte a documentação abrangente da Saxonica). A implementação vai muito além da implementação do XSLT 1.0 em navegadores da Web, implementando suporte total ao mais recente padrão v3.0 e, eventualmente, ao padrão v4.0 em andamento.
Polyfill
Há um polyfill que tenta permitir que o código atual, que depende das implementações de XSLT 1.0 dos navegadores da Web, continue funcionando sem usar recursos nativos de XSLT do navegador. O polyfill está localizado no GitHub.
O polyfill contém uma substituição funcional baseada em WASM para a classe XSLTProcessor. Assim, o código JavaScript atual pode continuar funcionando como está:
<script src="xslt-polyfill.min.js"></script>
<script>
const xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsltDoc);
const fragment = xsltProcessor.transformToFragment(xmlDoc, document);
</script>
O polyfill também oferece uma função utilitária automática para substituir facilmente documentos XML que usam instruções de processamento XSLT:
Para um arquivo demo.xml original como este:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
...content...
Uma linha pode ser adicionada para invocar o polyfill e transformar o documento com a folha de estilo XSLT referenciada:
<?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...
Nesse caso, o novo elemento <script> carrega o polyfill, que detecta o
tipo de documento XML e a instrução de processamento XSLT e carrega
de forma transparente, substituindo o documento.
Extensão
Há também uma extensão do Chrome que pode ser adicionada aos navegadores compatíveis e aplica o mesmo polyfill XSLT a todas as páginas XML brutas que contêm instruções de processamento XSLT ou chamadas para XSLTProcessor. Isso pode ser usado em aplicativos em que o XML ou XSLT de origem não pode ser alterado para manter a funcionalidade.
Em particular, quando o XSLT está desativado, o Chrome agora mostra um banner de aviso que vincula diretamente a uma página de pesquisa de extensões para ajudar os usuários a encontrar uma extensão:
Casos de uso específicos
Na discussão sobre padrões HTML, vários casos de uso concretos foram identificados. Esta seção fala especificamente sobre cada um deles para recomendar caminhos para desenvolvedores que publicam recursos XML usando XSLT hoje.
Feeds RSS e Atom
Em muitos feeds RSS ou Atom, o XSLT é usado para tornar os feeds XML brutos legíveis para humanos quando visualizados diretamente em um navegador. O principal caso de uso é que, quando um usuário clica acidentalmente no link do feed RSS de um site, em vez de colar esse link no leitor de RSS, ele recebe uma resposta HTML formatada que pode ler, em vez do XML bruto.
Há dois caminhos para esse caso de uso. A maneira "padrão" de fazer isso em HTML é adicionar <link rel="alternate" type="application/rss+xml"> a um site (baseado em HTML), em vez de adicionar um <a
href="something.xml"> explícito (visível para o usuário) em que os usuários podem clicar por acidente. Essa solução permite que
leitores de RSS encontrem o feed se um usuário colar apenas o URL do site, mas também
permite que usuários humanos vejam o conteúdo HTML normal sem se confundir
com um link para um recurso XML. Isso também segue o paradigma normal da Web de que HTML é para humanos e XML é para máquinas. É claro que isso não resolve o caso em que um usuário apenas "tem" um link RSS de algum lugar e o cola no navegador da Web (em vez do leitor de RSS).
Quando essa solução não é desejada, o polyfill oferece outro caminho. Como mencionado
anteriormente, o feed XML RSS/Atom pode ser aumentado com uma linha, <script
src="xslt-polyfill.min.js"
xmlns="[http://www.w3.org/1999/xhtml](http://www.w3.org/1999/xhtml)"></script>,
que vai manter o comportamento atual da transformação baseada em XSLT para HTML.
Isso não deve afetar a capacidade do leitor de RSS de continuar analisando o XML, já que
o <script> é um filho direto do elemento raiz.
Saída da API para dispositivos incorporados
Alguns dispositivos comerciais incorporados medem ou geram dados XML para consumo dos usuários na rede local. Alguns desses dispositivos fazem isso
gerando um único feed de dados XML que usa XSLT para transformá-lo em um
formato HTML legível para humanos. Isso permite que a API seja visualizada diretamente em um
navegador sem precisar de código adicional no dispositivo ou no navegador.
Como esse é um caso de uso muito específico do aplicativo, a forma da solução
pode variar. Para aplicativos em que o código-fonte do dispositivo incorporado pode ser atualizado, qualquer uma das opções descritas anteriormente (JSON, Polyfill) pode funcionar. No entanto, muitos desses dispositivos são difíceis ou impossíveis de atualizar por vários motivos. Nesse caso, a extensão provavelmente é a melhor opção, já que permite que os navegadores clientes continuem lendo os dados da mesma forma, sem modificar o dispositivo.
Criação de modelos lentos para sites
Os desenvolvedores da Web às vezes usam XSLT no lado do cliente para aplicar marcação de apresentação à marcação semântica, funcionando como uma linguagem de modelo lenta separada do ecossistema JavaScript.
Há duas soluções para esse problema mais geral. Para um site criado dessa forma, a solução mais fácil provavelmente é apenas adicionar o polyfill para manter a funcionalidade atual. Ou talvez realizar a transformação XSLT no lado do servidor e veicular o HTML resultante para o cliente, em vez do XML bruto. A solução de longo prazo para essas propriedades seria migrar para um framework mais moderno baseado em JavaScript ou JSON.