O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Remoção do XSLT para um navegador mais seguro

Mason Freed

Dominik Röttsches

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 descontinuou oficialmente o XSLT, incluindo a XSLTProcessor XSLTProcessor e a instrução de processamento XSLT. Pretendemos remover o suporte da versão 158 (17 de novembro de 2026). Os Firefox Firefox WebKit WebKit também indicaram planos de remover o XSLT dos mecanismos de navegação. Este documento fornece um pouco de histórico e contexto, explica como estamos removendo o XSLT para tornar o Chrome mais seguro e oferece um caminho para migrar antes que esses recursos sejam removidos do navegador. Para as atualizações mais recentes, consulte também a entrada Status da plataforma Chrome.

O que está sendo removido?

Há duas APIs no navegador que implementam o XSLT, e ambas estão sendo removidas:

A XSLTProcessor (por exemplo, new XSLTProcessor()).
A instrução de processamento XSLT (por exemplo, <?xml-stylesheet type="text/xsl" ... ?>).

Cronograma do Chrome

O Chrome tem o seguinte plano:

Chrome 142 (28 de outubro de 2025): mensagens de console de aviso 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 145 (2 de dezembro de 2025 Canary): as versões Canary, Dev e Beta começam a desativar o XSLT por padrão, como um aviso antecipado.
Chrome 146 (10 de março de 2026): a política corporativa (EP, na sigla em inglês) é lançada para testes. Isso permite que as empresas testem a desativação do XSLT com antecedência e também continuem usando recursos após a data da remoção.
Chrome 152 (25 de agosto de 2026): o teste de origem (OT, na sigla em inglês) é lançado para testes. Isso permite que os sites continuem usando recursos após a data da remoção.
Chrome 158 (17 de novembro de 2026): o XSLT para de funcionar nas versões Stable para todos os usuários, exceto para os participantes do teste de origem e da política corporativa.
Chrome 176 (17 de agosto de 2027): o teste de origem e a política corporativa param de funcionar. O XSLT está desativado 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 é recebido e vinculado a uma folha de estilo XSLT, o navegador usa as regras nessa 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 receber 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 processá-los neste HTML para o navegador exibir: HTML

<body>
  <p>Message: Hello World.</p>
</body>

Além da instrução de processamento XSL mostrada no exemplo anterior, também há a XSLTProcessor API JavaScript, que pode ser usada para processar documentos XML locais com folhas de estilo XSLT locais.

Histórico do XSLT

O XSLT foi recomendado 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 inicial 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, mais tarde, o Chrome, também incorporaram processadores XSLT 1.0 nativos, tornando as transformações XML-para-HTML do lado do cliente uma tecnologia da Web viável no início dos anos 2000.

A linguagem XSLT continuou a evoluir, 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 do navegador ficou estagnado. Atualmente, todos os principais mecanismos de navegador da Web oferecem suporte nativo apenas para o XSLT 1.0 original de 1999. Essa falta de avanço, aliada ao aumento do uso de JSON como um formato de fio e bibliotecas e frameworks JavaScript (como jQuery, React e Vue.js) que oferecem manipulação e modelos de DOM mais flexíveis e eficientes, levou a um declínio significativo no uso do XSLT do lado do cliente. A função dele no navegador da Web foi amplamente substituída 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 pelo 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 JavaScript básicos. No entanto, elas representam uma superfície de ataque direta e potente para processar conteúdo da Web não confiável. Aliás, o XSLT é a origem de vários exploits de segurança recentes e de grande repercussão que continuam colocando os usuários de navegadores em risco. Os riscos de segurança de manter essa funcionalidade legada e frágil superam em muito a utilidade moderna limitada.

Além disso, o objetivo original do XSLT do lado do cliente (transformar dados em HTML renderizável) foi substituído por APIs JavaScript mais seguras, ergonômicas e bem mantidas. O desenvolvimento da Web moderno depende de elementos 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 na sandbox JavaScript segura 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 em mecanismos JavaScript e é o que praticamente todos os desenvolvedores da Web usam hoje. Na verdade, apenas cerca de 0,02% dos carregamentos de páginas da Web atuais usam o XSLT, com menos de 0,001% usando instruções de processamento 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, 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.

Como melhorar a segurança da análise XML

Semelhante aos graves problemas de segurança no libxslt, problemas de segurança graves foram recentemente relatados no libxml2, que é usado no Chromium para analisar, serializar e testar a formação de XML. Para resolver problemas de segurança futuros com a análise XML no Chromium, planejamos eliminar o uso do libxml2 e substituir a análise XML por uma biblioteca de análise XML segura para memória escrita em Rust. É importante ressaltar que não vamos remover o XML do navegador. Apenas o XSLT está sendo considerado para remoção. Pretendemos garantir que a substituição do libxml2 seja totalmente transparente para os desenvolvedores da Web.

XML + CSS não está sendo removido

É importante distinguir a descontinuação do XSLT (<?xml-stylesheet type="text/xsl" ... ?>) da <?xml-stylesheet ... ?> instrução de processamento em si, que permanece com suporte quando usada com CSS. Você ainda pode usar a instrução de processamento com type="text/css" para aplicar regras de layout e design padrão aos seus dados brutos, assim como com HTML. Por exemplo:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="styles.css"?>
<root>
  <item>Content here</item>
</root>

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 de 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 longe é produzida pela Saxonica (consulte a documentação abrangente da Saxonica). A implementação vai muito além da implementação XSLT 1.0 em navegadores da Web, implementando suporte completo para o padrão v3.0 mais recente e, por fim, o padrão v4.0 em andamento.

Fibra de poliéster

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 XSLT nativos do navegador. O polyfill está localizado no GitHub.

O polyfill contém uma substituição funcional baseada em WASM para a classe XSLTProcessor, para que o código JavaScript atual possa 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 fornece uma função utilitária automática para uma maneira fácil de substituir 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 <script> elemento carrega o polyfill, que detecta o tipo de documento XML e a instrução de processamento XSLT e o carrega de maneira transparente, substituindo o documento.

Extensão

Há também uma extensão do Chrome que pode ser adicionada aos navegadores com suporte, que vai aplicar 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 para 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:

A mensagem mostrada no Chrome quando o xslt é detectado.

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 que usam XSLT hoje.

Feeds RSS e Atom

Em muitos feeds RSS ou Atom atuais, o XSLT é usado para tornar os feeds XML brutos legíveis 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 HTML "padrão" de fazer isso é 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 ao usuário) que os usuários podem clicar acidentalmente. Essa solução permite que os leitores de RSS encontrem o feed se um usuário colar apenas o URL do site, mas também permite que os 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 o HTML é para humanos e o 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"></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 incorporados comerciais medem ou geram dados XML para consumo por 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. 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, o formato 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 do cliente continuem lendo os dados da mesma maneira, sem modificar o dispositivo.

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 modelos lentos separada do ecossistema JavaScript.

Há duas soluções para esse problema mais geral. Para um site atual criado dessa forma, a solução mais fácil é adicionar o polyfill para manter a funcionalidade atual. Ou talvez realizar a transformação XSLT do lado do servidor e disponibilizar 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.

Se você encontrar um problema específico no Chrome relacionado a essa descontinuação do XSLT, informe um bug aqui.

Como detectar o uso do XSLT

Geralmente, recursos descontinuados, como o XSLT, podem ser detectados na sua base de código de algumas maneiras. Esta seção descreve duas delas.

A API Reporting

A API Reporting é um mecanismo de relatórios genérico para aplicativos da Web que usam relatórios sobre várias condições e recursos da plataforma, incluindo descontinuações de recursos. Para configurá-lo para gerar relatórios sobre a descontinuação do XSLT, um snippet de código como este pode ser usado:

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();

Confira esse código em ação no CodePen.

O relatório de tecnologia legada corporativa

Para administradores de uma empresa, o relatório de tecnologia legada pode ser usado para coletar automaticamente o uso de recursos descontinuados e gerar relatórios de maneira fácil de usar. Consulte este artigo do Suporte do Google para mais informações sobre como ativar esse recurso.