Эта страница переведена с помощью Cloud Translation API.

Удаление XSLT для более безопасного браузера

Mason Freed

Dominik Röttsches

Опубликовано: 29 октября 2025 г.

Chrome планирует отказаться от XSLT и удалить его из браузера. В этом документе подробно описано, как вы можете перенести свой код до удаления XSLT в конце 2026 года.

Chromium официально объявил XSLT устаревшим, включая JavaScript API XSLTProcessor и инструкцию обработки XML-таблиц стилей . Мы планируем прекратить поддержку начиная с версии 155 (17 ноября 2026 г.). Проекты Firefox и WebKit также заявили о планах удалить XSLT из своих браузерных движков. В этом документе представлена историческая справка и контекст, объясняется, как мы удаляем XSLT, чтобы сделать Chrome более безопасным, и предлагается путь миграции до удаления этих функций из браузера. Для получения последних обновлений также см. запись «Статус платформы Chrome» .

Что именно удаляется?

В браузере есть два API, реализующих XSLT, и оба будут удалены:

Класс XSLTProcessor (например, new XSLTProcessor() ).
Инструкция обработки XSLT (например, <?xml-stylesheet … ?> ).

Хронология для Chrome

В Chrome действует следующий план:

Chrome 142 (28 октября 2025 г.): В Chrome добавлены сообщения раннего предупреждения в консоли.
Chrome 143 (2 декабря 2025 г.): Официальное объявление API устаревшим — предупреждающие сообщения об устаревании начинают отображаться в консоли и в Lighthouse.
Chrome 148 (10 марта 2026 г., Canary): В версиях Canary, Dev и Beta по умолчанию начинает отключаться XSLT в качестве предупреждения.
Chrome 152 (25 августа 2026 г.): Запущены функции Origin Trial (OT) и Enterprise Policy (EP) для тестирования. Это позволит сайтам и предприятиям продолжать использовать функции после даты их удаления.
Chrome 155 (17 ноября 2026 г.): XSLT перестает работать в стабильных версиях для всех пользователей, кроме участников пробной версии Origin и участников корпоративной политики.**
Chrome 164 (17 августа 2027 г.): Пробная версия Origin и корпоративная политика перестали работать. XSLT отключен для всех пользователей.**

Что такое XSLT?

XSLT, или расширяемый язык преобразования таблиц стилей, — это язык, используемый для преобразования XML-документов, обычно в другие форматы, такие как HTML. Он использует файл таблицы стилей XSLT для определения правил этого преобразования и XML-файл, содержащий данные, используемые в качестве входных данных.

В браузерах, когда получен XML-файл, содержащий ссылку на таблицу стилей XSLT, браузер использует правила этой таблицы стилей для перегруппировки, форматирования и преобразования исходных XML-данных в структурированную страницу (часто HTML), которая может быть отображена для пользователя.

Например, таблица стилей XSLT может принимать на вход следующий XML-код:

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl" ?>
<page>
 <message>
  Hello World.
 </message>
</page>

и этот 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>

и обработать их, чтобы получить следующий HTML-код для отображения в браузере: HTML

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

В дополнение к инструкции обработки XSL, показанной в предыдущем примере, существует также JavaScript API XSLTProcessor , который можно использовать для обработки локальных XML-документов с локальными таблицами стилей XSLT.

История XSLT

XSLT был рекомендован Всемирным консорциумом веб-технологий (W3C) 16 ноября 1999 года в качестве языка для преобразования XML-документов в другие форматы, чаще всего в HTML, для отображения в веб-браузерах. До официальной рекомендации версии 1.0 компания Microsoft предприняла раннюю инициативу, выпустив собственную реализацию на основе рабочего проекта W3C в Internet Explorer 5.0 , выпущенном в марте 1999 года. Следуя официальному стандарту, Mozilla реализовала встроенную поддержку XSLT 1.0 в Netscape 6 в конце 2000 года. Другие основные браузеры, включая Safari, Opera и позже Chrome, также включили встроенные процессоры XSLT 1.0, что сделало преобразование XML в HTML на стороне клиента жизнеспособной веб-технологией в начале 2000-х годов.

Сам язык XSLT продолжал развиваться, с выпуском XSLT 2.0 в 2007 году и XSLT 3.0 в 2017 году , которые представили мощные функции, такие как регулярные выражения, улучшенные типы данных и возможность обработки JSON. Однако поддержка браузерами застопорилась. Сегодня все основные движки веб-браузеров предоставляют только нативную поддержку оригинального XSLT 1.0 1999 года. Это отсутствие развития, в сочетании с ростом использования JSON в качестве формата передачи данных, а также библиотеками и фреймворками JavaScript (такими как jQuery, React и Vue.js), которые предлагают более гибкие и мощные возможности манипулирования DOM и шаблонизации, привело к значительному снижению использования клиентского XSLT. Его роль в веб-браузере в значительной степени вытеснена этими технологиями на основе JavaScript.

Почему необходимо удалить XSLT?

Продолжающееся использование XSLT 1.0 в веб-браузерах представляет собой значительный и ненужный риск для безопасности. Базовые библиотеки, обрабатывающие эти преобразования, такие как libxslt (используемая браузерами Chromium), представляют собой сложные, устаревшие кодовые базы на C/C++. Этот тип кода, как известно, подвержен уязвимостям безопасности памяти, таким как переполнение буфера, что может привести к выполнению произвольного кода. Например, аудиты безопасности и системы отслеживания ошибок неоднократно выявляли серьезные уязвимости в этих парсерах (например, CVE-2025-7425 и CVE-2022-22834 , обе в libxslt). Поскольку клиентский XSLT сейчас является нишевой, редко используемой функцией, эти библиотеки получают гораздо меньше внимания со стороны службы поддержки и контроля безопасности, чем основные движки JavaScript, однако они представляют собой прямую и мощную поверхность атаки для обработки ненадежного веб-контента. Действительно, XSLT является источником нескольких недавних громких эксплойтов безопасности , которые продолжают подвергать пользователей браузеров риску. Риски для безопасности, связанные с поддержанием этой уязвимой, устаревшей функциональности, значительно перевешивают ее ограниченную полезность в современных условиях.

Кроме того, первоначальное назначение клиентского XSLT — преобразование данных в HTML-код, пригодный для рендеринга, — было вытеснено более безопасными, эргономичными и лучше поддерживаемыми API JavaScript. Современная веб-разработка опирается на такие инструменты, как Fetch API для получения данных (обычно JSON) и DOMParser API для безопасного анализа XML или HTML-строк и преобразования их в структуру DOM в защищенной среде JavaScript браузера. Фреймворки, такие как React, Vue и Svelte, затем эффективно и безопасно управляют рендерингом этих данных. Этот современный набор инструментов активно разрабатывается, выигрывает от масштабных инвестиций в безопасность движков JavaScript и используется практически всеми веб-разработчиками сегодня. Действительно, сегодня только около 0,02% загрузок веб-страниц фактически используют XSLT, и менее 0,001% используют инструкции обработки XSLT.

Это касается не только Chrome или Chromium: два других основных браузерных движка также поддерживают удаление XSLT из веб-платформы: WebKit и Gecko .

По этим причинам отказ от XSLT и его удаление уменьшают поверхность атаки браузера для всех пользователей, упрощают веб-платформу и позволяют сосредоточить инженерные ресурсы на обеспечении безопасности технологий, которые фактически обеспечивают работу современного веба, без практической потери возможностей для разработчиков.

Повышение безопасности анализа XML-файлов

Подобно серьезным проблемам безопасности в libxslt, недавно были выявлены серьезные проблемы безопасности в libxml2, используемой в Chromium для парсинга, сериализации и проверки корректности XML. Для решения будущих проблем безопасности при парсинге XML в Chromium мы планируем постепенно отказаться от использования libxml2 и заменить парсинг XML на библиотеку для парсинга XML, безопасную для памяти и написанную на Rust. Важно отметить, что мы не будем удалять XML из браузера; рассматривается только удаление XSLT. Мы намерены обеспечить полную прозрачность замены libxml2 для веб-разработчиков.

Как осуществить миграцию

Существует несколько альтернативных путей миграции.

JSON

Для сайтов, полностью построенных на XML и XSL, нет универсального способа перехода. Варианты миграции включают перенос конвейера обработки XSLT на сторону сервера и отправку сгенерированного HTML клиенту, или миграцию серверных конечных точек XML API на JSON и выполнение рендеринга на стороне клиента с использованием JavaScript для преобразования JSON в HTML DOM и CSS.

XSLT на стороне клиента в JavaScript

Существует несколько клиентских (на основе JavaScript) библиотек XSLT, но самая крупная из них разработана компанией Saxonica ( подробную документацию по Saxonica можно посмотреть здесь). Ее реализация значительно превосходит стандарт XSLT 1.0 для веб-браузеров, обеспечивая полную поддержку новейшего стандарта v3.0 и, в конечном итоге, разрабатываемого стандарта v4.0 .

Полиэфирный наполнитель

Существует полифил, который позволяет существующему коду, зависящему от реализации XSLT 1.0 в веб-браузерах, продолжать функционировать, не используя при этом встроенные функции XSLT браузера. Полифил находится на GitHub .

Полифил содержит функциональную замену класса XSLTProcessor на основе WASM, поэтому существующий код JavaScript может продолжать работать как есть:

<script src="xslt-polyfill.min.js"></script>

<script>
const xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsltDoc);
const fragment = xsltProcessor.transformToFragment(xmlDoc, document);
</script>

Полифил также предоставляет автоматическую вспомогательную функцию для простой замены XML-документов, использующих инструкции обработки XSLT:

Для оригинального файла demo.xml , подобного этому:

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
...content...

Для вызова полифилла и преобразования документа с использованием указанной таблицы стилей XSLT можно добавить всего одну строку:

<?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...

В этом случае новый элемент <script> загружает полифилл, который определяет тип XML-документа и инструкцию обработки XSLT и прозрачно загружает его, заменяя документ.

Расширение

Существует также расширение для Chrome , которое можно добавить в поддерживаемые браузеры. Оно будет применять один и тот же полифилл XSLT ко всем страницам в формате XML, содержащим инструкции обработки XSLT или вызовы XSLTProcessor. Это можно использовать в приложениях, где исходный XML или XSLT нельзя изменить, чтобы сохранить функциональность.

В частности, при отключении XSLT Chrome теперь отображает предупреждающий баннер, который ведет непосредственно на страницу поиска расширений, чтобы помочь пользователям найти нужное расширение:

Сообщение, отображаемое в Chrome при обнаружении XSLT.

Конкретные варианты использования

В ходе обсуждения стандартов HTML было выявлено несколько конкретных вариантов использования. В этом разделе подробно рассматривается каждый из них, чтобы предложить разработчикам, публикующим XML-ресурсы, использующие XSLT, дальнейшие пути развития.

RSS и Atom-каналы

Во многих существующих RSS или Atom-лентах XSLT используется для того, чтобы сделать необработанные XML-данные удобочитаемыми при просмотре непосредственно в браузере. Основное применение заключается в том, что когда пользователь случайно нажимает на ссылку RSS-ленты сайта, вместо того чтобы вставить эту ссылку в свой RSS-ридер, он получает отформатированный HTML-ответ, который он может прочитать, а не сам необработанный XML-код.

Для решения этой задачи есть два пути. Стандартный HTML-способ — добавить <link rel="alternate" type="application/rss+xml"> на сайт (на основе HTML), вместо добавления явно видимого пользователю <a href="something.xml"> , на который пользователи могут случайно нажать. Это решение позволяет RSS-ридерам находить ленту, если пользователь вставляет только URL-адрес веб-сайта, а также позволяет пользователям видеть обычный HTML-контент, не путаясь со ссылкой на XML-ресурс. Это также соответствует обычной веб-парадигме, согласно которой HTML предназначен для людей, а XML — для машин. Конечно, это не решает проблему, когда у пользователя просто есть RSS-ссылка откуда-то, и он вставляет её в свой веб-браузер (а не в RSS-ридер).

Если такое решение не требуется, полифилл предлагает другой путь. Как упоминалось ранее, RSS/Atom XML-ленту можно дополнить одной строкой: <script src="xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script> , которая сохранит существующее поведение преобразования в HTML на основе XSLT. Это не должно повлиять на способность RSS-ридера продолжать анализировать XML, поскольку <script> является прямым дочерним элементом корневого элемента.

Вывод API для встроенных устройств

Некоторые коммерческие встраиваемые устройства измеряют или иным образом генерируют XML-данные для использования пользователями в локальной сети. Некоторые из этих устройств делают это, генерируя единый поток XML-данных, который с помощью XSLT преобразуется в удобочитаемый HTML-формат. Это позволяет просматривать API непосредственно в браузере без необходимости добавления дополнительного кода на устройстве или в браузере.
Поскольку это очень специфический сценарий использования, форма решения может варьироваться. Для приложений, где исходный код встроенного устройства может быть обновлен, может подойти любой из описанных ранее вариантов (JSON, Polyfill). Однако, в частности, многие такие устройства сложно или невозможно обновить по разным причинам. В этом случае расширение , вероятно, будет лучшим вариантом, поскольку оно позволяет клиентским браузерам продолжать считывать данные точно так же, без изменения устройства.

Ленивое создание шаблонов для веб-сайтов

Веб-разработчики иногда используют XSLT на стороне клиента для применения разметки представления к семантической разметке, функционируя как ленивый язык шаблонов, отдельный от экосистемы JavaScript.

Существует два решения этой более общей проблемы. Для уже существующего сайта, построенного таким образом, самым простым решением, вероятно, будет просто добавить полифил для сохранения существующей функциональности. Или, возможно, выполнить XSLT-преобразование на стороне сервера и передать клиенту полученный HTML, а не необработанный XML. Более долгосрочным решением для таких свойств будет переход на более современный фреймворк на основе JavaScript или JSON.

Если вы столкнетесь с конкретной проблемой в Chrome, связанной с устареванием XSLT, сообщите об ошибке здесь .

Как обнаружить использование XSLT

Как правило, устаревшие функции, такие как XSLT, можно обнаружить в вашем коде несколькими способами. В этом разделе описаны два из них.

API для создания отчетов

API для создания отчетов — это универсальный механизм для веб-приложений, позволяющий создавать отчеты о различных функциях и условиях платформы, включая устаревание функций. Для настройки отчетов об устаревании XSLT можно использовать следующий фрагмент кода:

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

Посмотрите, как этот код работает, на CodePen .

Отчет о технологиях, устаревших в корпоративной среде

Администраторы предприятия могут использовать отчет об устаревших технологиях для автоматического сбора информации об использовании устаревших функций и предоставления отчетов в удобном для пользователя формате. Дополнительную информацию о включении этой функции см. в этой статье службы поддержки Google .