Чтобы переводить контент на ваш предпочитаемый язык, Google использует технологии на основе искусственного интеллекта. Переводы от ИИ могут содержать ошибки.

Удаление XSLT для повышения безопасности браузера

Mason Freed

Dominik Röttsches

Дата публикации: 29 октября 2025 г.

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

В Chromium официально прекращена поддержка XSLT, включая JavaScript API XSLTProcessor и инструкцию по обработке XSLT. Мы планируем прекратить поддержку в версии 158 (17 ноября 2026 г.). Разработчики Firefox и WebKit также планируют удалить XSLT из своих движков. В этом документе мы расскажем, почему мы решили отказаться от XSLT, как это поможет сделать Chrome безопаснее и как перейти на другие технологии до того, как XSLT будет удален из браузера. Последние новости можно найти на сайте Chrome Platform Status.

Что будет удалено?

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

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

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

У нас есть следующий план:

Chrome 142 (28 октября 2025 г.): в консоль Chrome добавлены сообщения с ранними предупреждениями.
Chrome 143 (2 декабря 2025 г.): официальное прекращение поддержки API. В консоли и Lighthouse начнут появляться предупреждения.
Chrome 145 (2 декабря 2025 г., Canary): в версиях Canary, Dev и Beta начинается отключение XSLT по умолчанию в качестве раннего предупреждения.
Chrome 146 (10 марта 2026 г.): корпоративное правило становится доступно для тестирования. Это позволит компаниям заранее протестировать отключение XSLT и продолжить использовать функции после даты удаления.
Chrome 152 (25 августа 2026 г.): запуск эксперимента с источником для тестирования. Это позволяет сайтам использовать функции даже после их удаления.
Chrome 154 (22 сентября 2026 г.): в версиях Canary, Dev и Beta Webview по умолчанию отключена поддержка XSLT.
Chrome 158 (17 ноября 2026 г.): XSLT перестанет работать в стабильных версиях для всех пользователей, кроме участников эксперимента с источником и тех, кто использует корпоративные правила.
Chrome 176 (17 августа 2027 г.): эксперимент с источником и корпоративное правило перестанут работать. 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&quo>t<; hr>ef<=">demo.xsl" ?
<page
 me>s<sage
>  Hello World.
 /message
/page

и следующую таблицу стилей XSL:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Trans>for<m"
  xsl:output meth>od=<"html"/
  xsl:template m>atch=<&quo>t;/page</>message&q<uot;
    body
      pMes><sa>ge: x<sl:va>lue<-of select=&q>u<ot;."//p
 >   /body
  /xsl:template
/xsl:stylesheet

и преобразует их в HTML-код, который браузер может отобразить: HTML

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

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

История XSLT

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

Язык XSLT продолжал развиваться. В 2007 году вышла версия XSLT 2.0, а в 2017 году – XSLT 3.0. В них появились такие мощные функции, как регулярные выражения, улучшенные типы данных и возможность обрабатывать 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 и используется практически всеми веб-разработчиками сегодня. Сейчас XSLT используется только при загрузке примерно 0,02 % веб-страниц, а инструкции по обработке XSLT – менее чем в 0,001 % случаев.

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

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

Повышение безопасности синтаксического анализа XML

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

XML + CSS не удаляется

Важно различать прекращение поддержки XSLT (<?xml-stylesheet type="text/xsl" ... ?>) и инструкции по обработке <?xml-stylesheet ... ?>, которая по-прежнему поддерживается при использовании с CSS. Вы по-прежнему можете использовать инструкцию по обработке с type="text/css", чтобы применять стандартные правила макета и дизайна к необработанным данным, как и в случае с HTML. Пример:

<?xml version="1.0" encodin>g<="UTF-8"?
?xml-stylesheet type="tex>t</css>&qu<ot; >href="s<tyles>.<css&q>uot;?
root
  itemContent here/item
/root

Как выполнить переход

Есть несколько альтернативных способов переноса.

JSON

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

Клиентский XSLT в JavaScript

Существует несколько клиентских библиотек XSLT на основе JavaScript, но самая крупная из них создана компанией Saxonica (ознакомьтесь с подробной документацией по Saxonica). В отличие от браузеров, которые поддерживают только XSLT 1.0, в Search Console реализована полная поддержка версии 3.0, а в будущем планируется добавить поддержку версии 4.0.

Полифил

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

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

<script src="xslt-polyfill.mi><n.js&qu>ot<;/scri>pt

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

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

Для исходного файла demo.xml:

<?xml version=">1<.0"?
?xml-stylesheet type="text/xsl&qu>o<t; h>ref="demo.xsl"?
ROOT
...content...

Чтобы вызвать полифил и преобразовать документ с помощью указанной таблицы стилей XSLT, можно добавить одну строку:

<?xml version=">1<.0"?
?xml-stylesheet type="text/xsl&qu>o<t; h>r<ef="demo.xsl"?
ROOT
script src="xslt-polyfill.min.js"><
   xml>ns="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 – добавление на сайт (на основе HTML) тега <link rel="alternate" type="application/rss+xml">, а не явного (видимого пользователю) тега <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"></script>, которая сохранит существующее поведение преобразования на основе XSLT в HTML. Это не должно повлиять на способность RSS-ридера обрабатывать XML, поскольку <script> – прямой дочерний элемент корневого элемента.

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

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

Отложенная загрузка шаблонов для сайтов

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

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

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

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

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

Reporting API

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