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

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

Mason Freed

Dominik Röttsches

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

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

Chromium официально объявил устаревшим XSLT, включая JavaScript API XSLTProcessor и инструкцию по обработке таблиц стилей XML . Мы планируем прекратить поддержку XSLT с версии 155 (17 ноября 2026 г.). Проекты Firefox и WebKit также заявили о планах по удалению XSLT из своих браузерных движков. В этом документе представлена история и контекст, объясняется, как мы удаляем XSLT для повышения безопасности 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 Trial и Enterprise Policy.**
Chrome 164 (17 августа 2027 г.): Пробная версия Origin и политика Enterprise прекращают работу. XSLT отключен для всех пользователей.**

Что такое XSLT?

XSLT (Extensible Stylesheet Language Transformations) — язык, используемый для преобразования 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, показанной в предыдущем примере, существует также API JavaScript 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 — было вытеснено более безопасными, эргономичными и лучше поддерживаемыми JavaScript API. Современная веб-разработка опирается на такие вещи, как 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

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

Полифилл

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

Полифилл содержит функциональную замену на основе WASM для класса XSLTProcessor, поэтому существующий код 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-ридер).

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

Вывод API для встраиваемых устройств

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

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

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

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