Usuwanie XSLT w celu zwiększenia bezpieczeństwa przeglądarki

Mason Freed
Mason Freed
X GitHub
Dominik Röttsches
Dominik Röttsches
GitHub Mastodon

Opublikowano: 29 października 2025 r.

Chrome zamierza wycofać i usunąć XSLT z przeglądarki. Z tego dokumentu dowiesz się, jak przenieść kod przed usunięciem funkcji pod koniec 2026 r.

Chromium oficjalnie wycofał XSLT, w tym XSLTProcessor JavaScript API i instrukcję przetwarzania XSLT. Planujemy usunąć obsługę w wersji 158 (17 listopada 2026 r.). Projekty Firefox i WebKit również zapowiedziały usunięcie XSLT z mechanizmów przeglądarek. W tym dokumencie znajdziesz informacje o historii i kontekście, wyjaśnienie, dlaczego usuwamy XSLT, aby zwiększyć bezpieczeństwo Chrome, oraz instrukcje dotyczące migracji przed usunięciem tych funkcji z przeglądarki. Najnowsze informacje znajdziesz też w artykule Stan platformy Chrome.

Co zostanie usunięte?

W przeglądarce są 2 interfejsy API, które implementują XSLT. Oba zostaną usunięte:

  • Klasa XSLTProcessor (np. new XSLTProcessor()).
  • Instrukcja przetwarzania XSLT (np. <?xml-stylesheet type="text/xsl" ... ?>).

Harmonogram dla Chrome

Chrome ma następujący plan:

  • Chrome 142 (28 października 2025 r.): dodanie do Chrome wczesnych ostrzeżeń w konsoli.
  • Chrome 143 (2 grudnia 2025 r.): oficjalne wycofanie interfejsu API – w konsoli i Lighthouse zaczną się wyświetlać ostrzeżenia o wycofaniu.
  • Chrome 145 (2 grudnia 2025 r. Canary): wersje Canary, Dev i Beta zaczną domyślnie wyłączać XSLT jako wczesne ostrzeżenie.
  • Chrome 146 (10 marca 2026 r.): zasady Enterprise (EP) wersja próbna. Umożliwi to firmom zarówno wcześniejsze testowanie wyłączania XSLT, jak i dalsze korzystanie z funkcji po dacie ich usunięcia.
  • Chrome 152 (25 sierpnia 2026 r.): Wersja próbna origin (OT). Umożliwi to witrynom dalsze korzystanie z funkcji po dacie ich usunięcia.
  • Chrome 158 (17 listopada 2026 r.): XSLT przestanie działać w wersjach stabilnych u wszystkich użytkowników z wyjątkiem uczestników testowania origin i użytkowników podlegających zasadom firmy.
  • Chrome 176 (17 sierpnia 2027 r.): testowanie origin i zasady firmowe przestaną działać. XSLT jest wyłączony dla wszystkich użytkowników.

Co to jest XSLT?

XSLT (Extensible Stylesheet Language Transformations) to język używany do przekształcania dokumentów XML, zwykle na inne formaty, takie jak HTML. Do definiowania reguł tej konwersji używa pliku arkusza stylów XSLT oraz pliku XML zawierającego dane wejściowe.

Gdy przeglądarka otrzyma plik XML, który zawiera link do arkusza stylów XSLT, używa reguł z tego arkusza do zmiany układu, formatowania i konwertowania surowych danych XML na uporządkowaną stronę (często HTML), którą można wyświetlić użytkownikowi.

Na przykład arkusz stylów XSLT może przyjąć te dane wejściowe w formacie XML:

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

i ten arkusz stylów 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>

a następnie przetworzyć je na ten kod HTML, który przeglądarka ma wyświetlić: HTML

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

Oprócz instrukcji przetwarzania XSL pokazanej w poprzednim przykładzie, istnieje też XSLTProcessor JavaScript API, którego można używać do przetwarzania lokalnych dokumentów XML za pomocą lokalnych arkuszy stylów XSLT.

Historia XSLT

16 listopada 1999 r. konsorcjum World Wide Web Consortium (W3C) zaleciło XSLT jako język do przekształcania dokumentów XML na inne formaty, najczęściej HTML, do wyświetlania w przeglądarkach internetowych. Przed oficjalnym zaleceniem wersji 1.0 firma Microsoft podjęła wczesną inicjatywę, udostępniając w przeglądarce Internet Explorer 5.0 (wydanej w marcu 1999 r.) zastrzeżoną implementację opartą na roboczej wersji W3C. Po opublikowaniu oficjalnego standardu firma Mozilla zaimplementowała natywną obsługę XSLT 1.0 w przeglądarce Netscape 6 pod koniec 2000 r. Inne popularne przeglądarki, w tym Safari, Opera i później Chrome, również zawierały natywne procesory XSLT 1.0, dzięki czemu przekształcanie XML na HTML po stronie klienta stało się wczesną technologią internetową na początku XXI wieku.

Sam język XSLT był dalej rozwijany. W 2007 r. wydano XSLT 2.0, a w 2017 r. – XSLT 3.0. Wprowadzono w nich zaawansowane funkcje, takie jak wyrażenia regularne, ulepszone typy danych i możliwość przetwarzania JSON. Obsługa w przeglądarkach jednak się nie rozwijała. Obecnie wszystkie główne mechanizmy przeglądarek internetowych zapewniają tylko natywną obsługę oryginalnego XSLT 1.0 z 1999 r. Ten brak postępu w połączeniu z rosnącym wykorzystaniem JSON jako formatu przesyłania danych oraz bibliotek i frameworków JavaScript (takich jak jQuery, React i Vue.js), które oferują bardziej elastyczną i wydajną manipulację DOM oraz tworzenie szablonów, doprowadził do znacznego spadku wykorzystania XSLT po stronie klienta. Jego rolę w przeglądarce internetowej w dużej mierze przejęły te technologie oparte na języku JavaScript.

Dlaczego trzeba usunąć XSLT?

Dalsze uwzględnianie XSLT 1.0 w przeglądarkach internetowych stwarza poważne i niepotrzebne zagrożenie dla bezpieczeństwa. Biblioteki bazowe, które przetwarzają te transformacje, takie jak libxslt (używana przez przeglądarki Chromium), to złożone, starsze bazy kodu C/C++. Ten typ kodu jest notorycznie podatny na luki w zabezpieczeniach pamięci, takie jak przepełnienie bufora, które mogą prowadzić do wykonania dowolnego kodu. Na przykład audyty bezpieczeństwa i narzędzia do śledzenia błędów wielokrotnie wykrywały w tych analizatorach luki w zabezpieczeniach o wysokim stopniu ważności (np. CVE-2025-7425 i CVE-2022-22834, oba w libxslt). Ponieważ XSLT po stronie klienta jest obecnie rzadko używaną funkcją, biblioteki te są znacznie rzadziej poddawane konserwacji i kontroli bezpieczeństwa niż podstawowe mechanizmy języka JavaScript. Stanowią one bezpośrednią, potężną powierzchnię ataku do przetwarzania niezaufanych treści internetowych. XSLT jest źródłem kilku niedawnych głośnych luk w zabezpieczeniach którenadal zagrażają użytkownikom przeglądarek. Ryzyko związane z utrzymywaniem tej kruchej, starszej funkcji znacznie przewyższa jej ograniczone nowoczesne zastosowanie.

Ponadto pierwotny cel XSLT po stronie klienta – przekształcanie danych na HTML do renderowania – został zastąpiony przez bezpieczniejsze, bardziej ergonomiczne i lepiej utrzymywane interfejsy JavaScript API. Nowoczesne tworzenie stron internetowych opiera się na takich elementach jak interfejs Fetch API do pobierania danych (zwykle JSON) i interfejs DOMParser API do bezpiecznego analizowania ciągów XML lub HTML na strukturę DOM w bezpiecznej piaskownicy JavaScript przeglądarki. Frameworki takie jak React, Vue i Svelte zarządzają następnie renderowaniem tych danych w sposób wydajny i bezpieczny. Ten nowoczesny łańcuch narzędzi jest aktywnie rozwijany, korzysta z ogromnych inwestycji w bezpieczeństwo mechanizmów JavaScript i jest obecnie używany przez praktycznie wszystkich programistów stron internetowych. W rzeczywistości tylko około 0,02% wczytań stron internetowych korzysta obecnie z XSLT, a mniej niż 0,001% używa instrukcji przetwarzania XSLT.

Nie jest to działanie tylko w Chrome ani Chromium. Pozostałe 2 główne mechanizmy przeglądarek również obsługują usunięcie XSLT z platformy internetowej: WebKit, Gecko.

Z tych powodów wycofanie i usunięcie XSLT zmniejsza powierzchnię ataku przeglądarki dla wszystkich użytkowników, upraszcza platformę internetową i pozwala skupić zasoby inżynieryjne na zabezpieczaniu technologii, które faktycznie obsługują nowoczesny internet, bez praktycznej utraty możliwości dla deweloperów.

Zwiększanie bezpieczeństwa analizowania XML

Podobnie jak w przypadku poważnych problemów z bezpieczeństwem w libxslt, poważne problemy z bezpieczeństwem zostały niedawno zgłoszone w libxml2, która jest używana w Chromium do analizowania, serializacji i testowania poprawności XML. Aby rozwiązać przyszłe problemy z bezpieczeństwem analizowania XML w Chromium, planujemy stopniowo wycofywać użycie libxml2 i zastąpić analizowanie XML biblioteką analizowania XML napisaną w języku Rust, która jest bezpieczna dla pamięci. Co ważne, nie usuniemy XML z przeglądarki. Rozważamy tylko usunięcie XSLT. Chcemy, aby zastąpienie libxml2 było całkowicie niewidoczne dla deweloperów internetowych.

XML + CSS nie zostanie usunięty

Należy odróżnić wycofanie XSLT (<?xml-stylesheet type="text/xsl" ... ?>) od <?xml-stylesheet ... ?> samej instrukcji przetwarzania, która pozostaje obsługiwana w przypadku użycia z CSS. Nadal możesz używać instrukcji przetwarzania z type="text/css" aby stosować standardowe reguły układu i projektowania do surowych danych, tak jak w przypadku HTML. Na przykład:

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

Jak przeprowadzić migrację

Istnieje kilka alternatywnych sposobów migracji.

JSON

W przypadku witryn w całości opartych na XML i XSL nie ma uniwersalnego sposobu na przeprowadzenie migracji. Opcje migracji obejmują przeniesienie potoku przetwarzania XSLT na serwer i wysyłanie do klienta renderowanego kodu HTML lub przeniesienie punktów końcowych interfejsu XML API po stronie serwera na JSON oraz renderowanie po stronie klienta za pomocą JavaScriptu w celu przekształcenia JSON na HTML DOM i CSS.

XSLT po stronie klienta w JavaScript

Dostępnych jest kilka bibliotek XSLT po stronie klienta (opartych na JavaScript), ale największa z nich jest tworzona przez Saxonica (zapoznaj się z obszerną dokumentacją Saxonica). Implementacja wykracza daleko poza implementację XSLT 1.0 w przeglądarkach internetowych, ponieważ obsługuje w pełni najnowszy standard v3.0, a w przyszłości także standard v4.0, który jest w trakcie opracowywania.

Kod polyfill

Istnieje kod polyfill, który umożliwia dalsze działanie istniejącego kodu zależnego od implementacji XSLT 1.0 w przeglądarkach, bez używania natywnych funkcji XSLT w przeglądarce. Kod polyfill znajduje się na GitHub.

Kod polyfill zawiera funkcjonalny zamiennik klasy XSLTProcessor oparty na WASM, dzięki czemu istniejący kod JavaScript może nadal działać bez zmian:

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

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

Kod polyfill udostępnia też automatyczną funkcję użytkową, która ułatwia zastępowanie dokumentów XML używających instrukcji przetwarzania XSLT:

W przypadku oryginalnego pliku demo.xml takiego jak ten:

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

Możesz dodać 1 wiersz, aby wywołać kod polyfill i przekształcić dokument za pomocą arkusza stylów XSLT, do którego odwołuje się dokument:

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

W tym przypadku nowy element <script> wczytuje kod polyfill, który wykrywa typ dokumentu XML i instrukcję przetwarzania XSLT, a następnie wczytuje ją w sposób niewidoczny dla użytkownika, zastępując dokument.

Rozszerzenie

Dostępne jest też rozszerzenie Chrome, które można dodać do obsługiwanych przeglądarek. Będzie ono stosować ten sam kod polyfill XSLT do wszystkich surowych stron XML zawierających instrukcje przetwarzania XSLT lub wywołania XSLTProcessor. Można go używać w aplikacjach, w których nie można zmienić źródłowego XML ani XSLT, aby zachować funkcjonalność.

Gdy XSLT jest wyłączony, Chrome wyświetla teraz baner z ostrzeżeniem, który zawiera link bezpośrednio do strony wyszukiwania rozszerzeń, aby ułatwić użytkownikom znalezienie rozszerzenia:

Komunikat wyświetlany w Chrome po wykryciu pliku XSLT.

Konkretne przypadki użycia

Podczas dyskusji na temat standardów HTML zidentyfikowano kilka konkretnych przypadków użycia. W tej sekcji omówimy każdy z nich, aby polecić deweloperom publikującym obecnie zasoby XML, które używają XSLT, odpowiednie rozwiązania.

Kanały RSS i Atom

W wielu istniejących kanałach RSS lub Atom XSLT jest używany do tego, aby surowe kanały XML były czytelne dla człowieka, gdy są wyświetlane bezpośrednio w przeglądarce. Główny przypadek użycia polega na tym, że gdy użytkownik przypadkowo kliknie link do kanału RSS witryny, zamiast wkleić ten link do czytnika RSS, otrzyma sformatowaną odpowiedź HTML, którą może przeczytać, a nie surowy XML.

W tym przypadku użycia są 2 rozwiązania. „Standardowy” sposób na to w HTML polega na dodaniu do witryny (opartej na HTML) elementu <link rel="alternate" type="application/rss+xml">, zamiast dodawania jawnego (widocznego dla użytkownika) elementu <a href="something.xml">, który użytkownicy mogą przypadkowo kliknąć. To rozwiązanie umożliwia czytnikom RSS znalezienie kanału, jeśli użytkownik wklei tylko adres URL witryny, ale też pozwala użytkownikom zobaczyć zwykłą zawartość HTML bez mylenia się z linkiem do zasobu XML. Jest to też zgodne z normalnym paradygmatem internetowym, że HTML jest przeznaczony dla ludzi, a XML – dla maszyn. Oczywiście nie rozwiązuje to sytuacji, w której użytkownik po prostu „ma” link RSS z jakiegoś miejsca i wkleja go do przeglądarki internetowej (zamiast do czytnika RSS).

Jeśli to rozwiązanie nie jest odpowiednie, kod polyfill oferuje inną ścieżkę. Jak wspomnieliśmy wcześniej, kanał XML RSS/Atom można rozszerzyć o 1 wiersz, <script src="xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script>, który zachowa dotychczasowe działanie przekształcania opartego na XSLT na HTML. Nie powinno to wpływać na możliwość dalszego analizowania XML przez czytnik RSS, ponieważ element <script> jest bezpośrednim elementem podrzędnym elementu głównego.

Dane wyjściowe interfejsu API na urządzenia wbudowane

Niektóre komercyjne urządzenia wbudowane mierzą lub generują dane XML do użytku przez użytkowników w sieci lokalnej. Niektóre z tych urządzeń robią to, generując pojedynczy plik danych XML, który używa XSLT do przekształcenia go na czytelny dla człowieka format HTML. Dzięki temu interfejs API można wyświetlać bezpośrednio w przeglądarce bez konieczności dodawania dodatkowego kodu na urządzeniu lub w przeglądarce.
Ponieważ jest to przypadek użycia specyficzny dla aplikacji, kształt rozwiązania może się różnić. W przypadku aplikacji, w których można zaktualizować kod źródłowy urządzenia wbudowanego, może działać dowolna z opisanych wcześniej opcji (JSON, kod polyfill). Z różnych powodów wiele takich urządzeń jest jednak trudnych lub niemożliwych do zaktualizowania. W takim przypadku rozszerzenie jest prawdopodobnie najlepszym rozwiązaniem, ponieważ umożliwia przeglądarkom klientów dalsze odczytywanie danych w dokładnie taki sam sposób, bez modyfikowania urządzenia.

Lenistwo w tworzeniu szablonów stron internetowych

Deweloperzy internetowi czasami używają XSLT po stronie klienta, aby stosować znaczniki prezentacji do znaczników semantycznych, działając jako leniwy język szablonów, który jest oddzielony od ekosystemu JavaScript.

Istnieją 2 rozwiązania tego bardziej ogólnego problemu. W przypadku istniejącej witryny zbudowanej w ten sposób najłatwiejszym rozwiązaniem jest prawdopodobnie dodanie watoliny poliestrowej, aby zachować dotychczasową funkcjonalność. Możesz też przeprowadzić transformację XSLT po stronie serwera i udostępnić klientowi wynikowy kod HTML zamiast surowego XML. Długoterminowym rozwiązaniem w przypadku takich właściwości byłoby przejście na nowocześniejszy framework oparty na JavaScript lub JSON.

Jeśli w Chrome wystąpi konkretny problem związany z wycofaniem XSLT, zgłoś błąd tutaj.

Jak wykryć użycie XSLT

Ogólnie rzecz biorąc, wycofane funkcje, takie jak XSLT, można wykryć w bazie kodu na kilka sposobów. W tej sekcji opisujemy 2 z nich.

Interfejs API do raportowania

Interfejs Reporting API to ogólny mechanizm raportowania, który umożliwia aplikacjom internetowym raportowanie różnych funkcji i warunków platformy, w tym wycofania funkcji. Aby skonfigurować go do raportowania o wycofaniu XSLT, możesz użyć takiego fragmentu kodu:

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

Zobacz ten kod w działaniu w CodePen.

Raport o starszych technologiach w firmie

Administratorzy w firmie mogą używać raportu o starszych technologiach do automatycznego zbierania informacji o użyciu wycofanych funkcji i raportowania ich w sposób przyjazny dla użytkownika. Więcej informacji o tym, jak włączyć tę funkcję, znajdziesz w tym artykule pomocy Google.