Publicado el 29 de octubre de 2025
Chrome planea dar de baja y quitar XSLT del navegador. En este documento, se detalla cómo puedes migrar tu código antes de la eliminación a fines de 2026.
Chromium dejó de admitir oficialmente XSLT, incluida la API de JavaScript XSLTProcessor y la instrucción de procesamiento de hojas de estilo XML. Tenemos la intención de quitar la compatibilidad con la versión 155 (17 de noviembre de 2026). Los proyectos Firefox y WebKit también indicaron que planean quitar XSLT de sus motores de navegador. En este documento, se proporciona información histórica y contextual, se explica cómo quitaremos XSLT para que Chrome sea más seguro y se indica una ruta de migración antes de que se quiten estas funciones del navegador.
¿Qué se quitará?
En el navegador, hay dos APIs que implementan XSLT, y ambas se quitarán:
- La clase XSLTProcessor (por ejemplo,
new XSLTProcessor()). - La instrucción de procesamiento XSLT (por ejemplo,
<?xml-stylesheet … ?>).
Cronograma para Chrome
Chrome tiene el siguiente plan:
- Chrome 142 (28 de octubre de 2025): Se agregaron mensajes de advertencia anticipada a la consola de Chrome.
- Chrome 143 (2 de diciembre de 2025): Baja oficial de la API. Los mensajes de advertencia de baja comienzan a aparecer en la consola y en Lighthouse.
- Chrome 148 (Canary del 10 de marzo de 2026): Las versiones Canary, Beta y para desarrolladores comienzan a inhabilitar XSLT de forma predeterminada como advertencia anticipada.
- Chrome 152 (25 de agosto de 2026): Se lanzan la prueba de origen (OT) y la política empresarial (EP) para las pruebas. Estos permiten que los sitios y las empresas sigan usando las funciones después de la fecha de eliminación.
- Chrome 155 (17 de noviembre de 2026): XSLT dejará de funcionar en las versiones estables para todos los usuarios, excepto los participantes de la prueba de origen y la política empresarial.**
- Chrome 164 (17 de agosto de 2027): Dejarán de funcionar la prueba de origen y la política empresarial. XSLT está inhabilitado para todos los usuarios**.
¿Qué es XSLT?
XSLT, o Lenguaje de hoja de estilo extensible para transformaciones, es un lenguaje que se usa para transformar documentos XML, comúnmente en otros formatos, como HTML. Utiliza un archivo de hoja de estilo XSLT para definir las reglas de esta conversión y un archivo XML que contiene los datos que se usan como entrada.
En los navegadores, cuando se recibe un archivo XML que vincula a una hoja de estilo XSLT, el navegador usa las reglas de esa hoja de estilo para reorganizar, dar formato y convertir los datos XML sin procesar en una página estructurada (a menudo HTML) que se puede renderizar para el usuario.
Por ejemplo, una hoja de estilo XSLT podría tomar la siguiente entrada XML:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl" ?>
<page>
<message>
Hello World.
</message>
</page>
y esta hoja 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>
y procesarlos en este código HTML para que el navegador lo muestre: HTML
<body>
<p>Message: Hello World.</p>
</body>
Además de la instrucción de procesamiento XSL que se muestra en el ejemplo anterior, también existe la API de JavaScript XSLTProcessor, que se puede usar para procesar documentos XML locales con hojas de estilo XSLT locales.
Historia de XSLT
El World Wide Web Consortium (W3C) recomendó XSLT el 16 de noviembre de 1999 como un lenguaje para transformar documentos XML en otros formatos, principalmente HTML para su visualización en navegadores web. Antes de la recomendación oficial 1.0, Microsoft tomó la iniciativa de lanzar una implementación propietaria basada en un borrador de trabajo del W3C en Internet Explorer 5.0, que se lanzó en marzo de 1999. Siguiendo el estándar oficial, Mozilla implementó la compatibilidad nativa con XSLT 1.0 en Netscape 6 a fines del año 2000. Otros navegadores populares, como Safari, Opera y Chrome (versiones posteriores), también incorporaron procesadores XSLT 1.0 nativos, lo que convirtió las transformaciones de XML a HTML del cliente en una tecnología web viable a principios de la década del 2000.
El lenguaje XSLT en sí siguió evolucionando con el lanzamiento de XSLT 2.0 en 2007 y XSLT 3.0 en 2017, que introdujeron funciones potentes, como expresiones regulares, tipos de datos mejorados y la capacidad de procesar JSON. Sin embargo, la compatibilidad con navegadores se estancó. Actualmente, todos los motores de navegadores web principales solo proporcionan compatibilidad nativa con el XSLT 1.0 original de 1999. Esta falta de avance, junto con el aumento del uso de JSON como formato de transferencia y las bibliotecas y los frameworks de JavaScript (como jQuery, React y Vue.js) que ofrecen una manipulación y una creación de plantillas del DOM más flexibles y potentes, provocó una disminución significativa en el uso de XSLT del cliente. Su rol en el navegador web se vio reemplazado en gran medida por estas tecnologías basadas en JavaScript.
¿Por qué se debe quitar XSLT?
La inclusión continua de XSLT 1.0 en los navegadores web representa un riesgo de seguridad significativo e innecesario. Las bibliotecas subyacentes que procesan estas transformaciones, como libxslt (que usan los navegadores Chromium), son bases de código complejas y antiguas de C/C++. Este tipo de código es notoriamente susceptible a vulnerabilidades de seguridad de la memoria, como desbordamientos de búfer, que pueden provocar la ejecución de código arbitrario. Por ejemplo, las auditorías de seguridad y los sistemas de seguimiento de errores identificaron reiteradamente vulnerabilidades de gravedad alta en estos analizadores (p.ej., CVE-2025-7425 y CVE-2022-22834, ambas en libxslt). Debido a que la XSLT del cliente ahora es una función de nicho que se usa con poca frecuencia, estas bibliotecas reciben mucho menos mantenimiento y supervisión de seguridad que los motores principales de JavaScript, pero representan una superficie de ataque directa y potente para procesar contenido web no confiable. De hecho, XSLT es la fuente de varios exploits de seguridad de alto perfil recientes que siguen poniendo en riesgo a los usuarios del navegador. Los riesgos de seguridad de mantener esta función heredada y frágil superan con creces su utilidad moderna limitada.
Además, el propósito original de XSLT del cliente (transformar datos en HTML renderizable) se reemplazó por APIs de JavaScript más seguras, ergonómicas y mejor mantenidas. El desarrollo web moderno se basa en elementos como la API de Fetch para recuperar datos (por lo general, JSON) y la API de DOMParser para analizar de forma segura cadenas XML o HTML en una estructura DOM dentro de la zona de pruebas segura de JavaScript del navegador. Luego, los frameworks como React, Vue y Svelte administran la renderización de estos datos de manera eficiente y segura. Esta cadena de herramientas moderna se desarrolla de forma activa, se beneficia de la gran inversión en seguridad en los motores de JavaScript y es lo que prácticamente todos los desarrolladores web usan hoy en día. De hecho, solo alrededor del 0.02% de las cargas de páginas web actuales usan XSLT, y menos del 0.001% usan instrucciones de procesamiento de XSLT.
Esta no es una acción exclusiva de Chrome o Chromium: los otros dos motores de navegador principales también admiten la eliminación de XSLT de la plataforma web: WebKit y Gecko.
Por estos motivos, la baja y la eliminación de XSLT reducen la superficie de ataque del navegador para todos los usuarios, simplifican la plataforma web y permiten que los recursos de ingeniería se enfoquen en proteger las tecnologías que realmente impulsan la Web moderna, sin pérdida práctica de capacidad para los desarrolladores.
Mejora de la seguridad del análisis de XML
Al igual que los problemas de seguridad graves en libxslt, recientemente se informaron problemas de seguridad graves en libxml2, que se usa en Chromium para analizar, serializar y probar el formato correcto de XML. Para abordar futuros problemas de seguridad con el análisis de XML en Chromium, planeamos eliminar gradualmente el uso de libxml2 y reemplazar el análisis de XML con una biblioteca de análisis de XML segura para la memoria escrita en Rust. Es importante destacar que no quitaremos XML del navegador, sino que solo se está considerando quitar XSLT. Nuestro objetivo es garantizar que el reemplazo de libxml2 sea completamente transparente para los desarrolladores web.
Cómo realizar la migración
Existen algunas rutas alternativas para la migración.
JSON
Para los sitios que se compilan completamente en XML y XSL, no existe una forma única de realizar la transición. Entre las opciones de migración, se incluyen trasladar la canalización de procesamiento de XSLT al servidor y enviar el HTML renderizado al cliente, o migrar los extremos de la API de XML del servidor a JSON y realizar la renderización del cliente con JavaScript para transformar JSON en DOM de HTML y CSS.
XSLT del cliente en JavaScript
Existen algunas bibliotecas XSLT del cliente (basadas en JavaScript), pero la más grande, con diferencia, es la que produce Saxonica (consulta la documentación integral de Saxonica). La implementación va mucho más allá de la implementación de XSLT 1.0 en los navegadores web, ya que implementa la compatibilidad total con el estándar v3.0 más reciente y, finalmente, con el estándar v4.0 en curso.
Polyfill
Existe un polyfill que intenta permitir que el código existente, que depende de las implementaciones de XSLT 1.0 de los navegadores web, siga funcionando sin usar las funciones nativas de XSLT del navegador. El polyfill se encuentra en GitHub.
El polyfill contiene un reemplazo funcional basado en WASM para la clase XSLTProcessor, por lo que el código JavaScript existente puede seguir funcionando tal como está:
<script src="xslt-polyfill.min.js"></script>
<script>
const xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsltDoc);
const fragment = xsltProcessor.transformToFragment(xmlDoc, document);
</script>
El polyfill también proporciona una función de utilidad automática para reemplazar fácilmente los documentos XML que usan instrucciones de procesamiento XSLT:
Para un archivo demo.xml original como este:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
...content...
Se puede agregar una línea para invocar el polyfill y transformar el documento con la hoja de estilo XSLT a la que se hace referencia:
<?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...
En este caso, el nuevo elemento <script> carga el polyfill, que detecta el tipo de documento XML y la instrucción de procesamiento XSLT, y lo carga de forma transparente, reemplazando el documento.
Extensión
También hay una extensión de Chrome que se puede agregar a los navegadores compatibles, la cual aplicará el mismo polyfill de XSLT a todas las páginas XML sin procesar que contengan instrucciones de procesamiento de XSLT o llamadas a XSLTProcessor. Esto se puede usar para aplicaciones en las que no se puede cambiar el código fuente XML o XSLT, para mantener la funcionalidad.
En particular, cuando se inhabilita XSLT, Chrome ahora muestra un banner de advertencia que vincula directamente a una página de búsqueda de extensiones para ayudar a los usuarios a encontrar una extensión:
Casos de uso específicos
En el debate sobre los estándares de HTML, se identificaron varios casos de uso concretos. En esta sección, se habla específicamente de cada uno de ellos para recomendar a los desarrolladores que publican recursos XML que usan XSLT en la actualidad los caminos a seguir.
Feeds RSS y Atom
En muchos feeds RSS o Atom existentes, se usa XSLT para que los feeds XML sin procesar sean legibles para los usuarios cuando se ven directamente en un navegador. El caso de uso principal es que, cuando un usuario hace clic accidentalmente en el vínculo del feed RSS de un sitio, en lugar de pegar ese vínculo en su lector de RSS, obtiene una respuesta en formato HTML que puede leer, en lugar del XML sin procesar.
Existen dos caminos a seguir para este caso de uso. La forma "estándar" de HTML para hacer esto es agregar <link rel="alternate" type="application/rss+xml"> a un sitio (basado en HTML), en lugar de agregar un <a
href="something.xml"> explícito (visible para el usuario) en el que los usuarios podrían hacer clic accidentalmente. Esta solución permite que los lectores de RSS encuentren el feed si un usuario pega solo la URL del sitio web, pero también permite que los usuarios humanos vean el contenido HTML normal sin confundirse con un vínculo a un recurso XML. Esto también sigue el paradigma web normal de que el HTML es para humanos y el XML es para máquinas. Por supuesto, esto no resuelve el caso en el que un usuario simplemente "tiene" un vínculo RSS de algún lugar y lo pega en su navegador web (en lugar de en su lector de RSS).
Cuando no se desea esa solución, el polyfill ofrece otra ruta. Como se mencionó anteriormente, el feed XML de RSS/Atom se puede aumentar con una línea, <script
src="xslt-polyfill.min.js"
xmlns="[http://www.w3.org/1999/xhtml](http://www.w3.org/1999/xhtml)"></script>, que mantendrá el comportamiento existente de la transformación basada en XSLT a HTML.
Esto no debería afectar la capacidad del lector de RSS para seguir analizando el XML, ya que <script> es un elemento secundario directo del elemento raíz.
Salida de la API para dispositivos integrados
Algunos dispositivos integrados comerciales miden o generan datos XML para que los usuarios los consuman en la red local. Algunos de estos dispositivos generan un solo feed de datos XML que usa XSLT para transformarlo en un formato HTML legible. Esto permite que la API se vea directamente en un navegador sin necesidad de código adicional en el dispositivo o en el navegador.
Dado que este es un caso de uso muy específico de la aplicación, la forma de la solución puede variar. En el caso de las aplicaciones en las que se puede actualizar el código fuente del dispositivo integrado, cualquiera de las opciones descritas anteriormente (JSON, Polyfill) podría funcionar. Sin embargo, muchos de estos dispositivos son difíciles o imposibles de actualizar por varios motivos. En ese caso, la extensión probablemente sea la mejor opción, ya que permite que los navegadores del cliente sigan leyendo los datos exactamente de la misma manera, sin modificar el dispositivo.
Plantillas diferidas para sitios web
A veces, los desarrolladores web usan XSLT en el cliente para aplicar el lenguaje de marcado de presentación al lenguaje de marcado semántico, lo que funciona como un lenguaje de plantillas diferido independiente del ecosistema de JavaScript.
Existen dos soluciones para este problema más general. En el caso de un sitio existente creado de esta manera, la solución más sencilla probablemente sea agregar el polyfill para mantener la funcionalidad existente. O tal vez realizar la transformación XSLT en el servidor y entregar el HTML resultante al cliente, en lugar del XML sin procesar. La solución a largo plazo para esas propiedades sería migrar a un framework más moderno basado en JavaScript o JSON.