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

Mason Freed

Dominik Röttsches

Opublikowano: 29 października 2025 r.

Chrome zamierza wycofać i usunąć XSLT z przeglądarki. W tym dokumencie opisujemy, jak możesz przenieść kod przed usunięciem tej funkcji pod koniec 2026 r.

Chromium oficjalnie wycofało XSLT, w tym interfejs JavaScript API XSLTProcessor i instrukcję przetwarzania XSLT. Planujemy usunąć obsługę od wersji 158 (17 listopada 2026 r.). Zespoły projektów Firefox i WebKit również ogłosiły plany usunięcia XSLT ze swoich mechanizmów przeglądarek. W tym dokumencie znajdziesz informacje o historii i kontekście, wyjaśnienie, jak usuwamy XSLT, aby zwiększyć bezpieczeństwo Chrome, oraz ścieżkę migracji, zanim te funkcje zostaną usunięte z przeglądarki. Najnowsze informacje znajdziesz też we wpisie dotyczącym stanu platformy Chrome.

Uwaga: aby jeszcze bardziej zwiększyć bezpieczeństwo, planujemy też przenieść analizę XML w Chrome z libxml2 do parsera XML napisanego w języku Rust.

Co zostanie usunięte?

W przeglądarce są 2 interfejsy API, które implementują XSLT, i oba są usuwane:

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

Oś czasu w Chrome

W przypadku Chrome planujemy:

• Chrome 142 (28 października 2025 r.): do Chrome dodano komunikaty konsoli z ostrzeżeniami.
• Chrome 143 (2 grudnia 2025 r.): oficjalne wycofanie interfejsu API – w konsoli i w Lighthouse zaczynają się wyświetlać komunikaty ostrzegawcze o wycofaniu.
• Chrome 145 (2 grudnia 2025 r., Canary): wersje Canary, deweloperska i beta zaczynają domyślnie wyłączać XSLT jako wczesne ostrzeżenie.
• Chrome 146 (10 marca 2026 r.): zasady Enterprise są dostępne do testowania. Dzięki temu firmy mogą wcześniej przetestować wyłączenie XSLT, a także nadal korzystać z funkcji po dacie ich usunięcia.
• Chrome 152 (25 sierpnia 2026 r.): wersja próbna origin jest dostępna do testowania. Pozwalają one witrynom nadal korzystać z funkcji po dacie ich usunięcia.
• Chrome 154 (22 września 2026 r.): w wersjach Canary, deweloperskiej i beta Webview zacznie domyślnie wyłączać XSLT jako wczesne ostrzeżenie.
• 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.): wersja próbna origin i zasady Enterprise przestają działać. Funkcja XSLT jest wyłączona dla wszystkich użytkowników.

Co to jest XSLT?

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

Gdy przeglądarka otrzyma plik XML, który zawiera link do arkusza stylów XSLT, używa reguł z tego arkusza, aby zmienić układ, sformatować i przekonwertować nieprzetworzone dane XML na uporządkowaną stronę (często HTML), którą można wyrenderować dla użytkownika.

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

<?xml version=">1<.0"?
?xml-stylesheet type="text/xsl&quo>t<; hr>ef<=">demo.xsl" ?
<page
 me>s<sage
>  Hello World.
 /message
/page

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

i przetwarza je na ten kod HTML, który przeglądarka wyświetla: HTML

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

Oprócz instrukcji przetwarzania XSL pokazanej w poprzednim przykładzie istnieje też interfejs JavaScript API XSLTProcessor, 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 (W3C) zaleciło XSLT jako język do przekształcania dokumentów XML w inne formaty, najczęściej HTML, w celu wyświetlania ich w przeglądarkach internetowych. Przed oficjalną rekomendacją wersji 1.0 Microsoft podjął wczesną inicjatywę, dostarczając zastrzeżoną implementację opartą na wersji roboczej W3C w Internet Explorerze 5.0, wydanym w marcu 1999 r. Zgodnie z oficjalnym standardem Mozilla wdrożyła natywną obsługę XSLT 1.0 w Netscape 6 pod koniec 2000 roku. Inne popularne przeglądarki, w tym Safari, Opera i późniejsze wersje Chrome, również zawierały natywne procesory XSLT 1.0, dzięki czemu na początku XXI wieku przekształcanie XML na HTML po stronie klienta stało się realną technologią internetową.

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

Dlaczego trzeba usunąć XSLT?

Dalsze uwzględnianie XSLT 1.0 w przeglądarkach internetowych stanowi poważne i niepotrzebne zagrożenie dla bezpieczeństwa. Biblioteki, które przetwarzają te przekształcenia, takie jak libxslt (używana przez przeglądarki Chromium), to złożone, starsze bazy kodu C/C++. Tego typu kod jest notorycznie podatny na luki w zabezpieczeniach pamięci, takie jak przepełnienie bufora, co może prowadzić do samowolnego wykonania kodu. Na przykład audyty bezpieczeństwa i narzędzia do śledzenia błędów wielokrotnie wykrywały w tych parserach luki w zabezpieczeniach o wysokim poziomie ważności (np. CVE-2025-7425 i CVE-2022-22834, obie w libxslt). Ponieważ XSLT po stronie klienta jest obecnie rzadko używaną funkcją, biblioteki te są znacznie rzadziej poddawane konserwacji i kontroli zabezpieczeń niż podstawowe mechanizmy języka JavaScript. Stanowią one bezpośrednią, potężną powierzchnię ataku do przetwarzania niezaufanych treści z internetu. XSLT jest źródłem kilku niedawnych głośnych luk w zabezpieczeniach, które nadal zagrażają użytkownikom przeglądarek. Zagrożenia bezpieczeństwa związane z utrzymywaniem tej niestabilnej, starszej funkcji znacznie przewyższają jej ograniczoną użyteczność.

Ponadto pierwotny cel XSLT po stronie klienta, czyli przekształcanie danych w kod HTML, który można wyrenderować, został zastąpiony przez bezpieczniejsze, bardziej ergonomiczne i lepiej utrzymywane interfejsy API JavaScriptu. 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 znaków XML lub HTML w strukturze DOM w bezpiecznej piaskownicy JavaScriptu w przeglądarce. Frameworki takie jak React, Vue i Svelte zarządzają następnie renderowaniem tych danych w sposób wydajny i bezpieczny. Ten nowoczesny zestaw narzędzi jest aktywnie rozwijany, korzysta z ogromnych inwestycji w bezpieczeństwo silników JavaScriptu i jest używany przez praktycznie wszystkich programistów stron internetowych. Obecnie tylko około 0,02% wczytań stron internetowych korzysta z XSLT, a mniej niż 0,001% używa instrukcji przetwarzania XSLT.

Nie jest to działanie dotyczące tylko Chrome lub 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 na przeglądarkę dla wszystkich użytkowników, upraszcza platformę internetową i umożliwia skupienie zasobów inżynieryjnych na zabezpieczaniu technologii, które faktycznie napędzają nowoczesny internet, bez praktycznej utraty możliwości dla deweloperów.

Ulepszanie zabezpieczeń analizy XML

Podobnie jak w przypadku poważnych problemów z zabezpieczeniami w libxslt, niedawno zgłoszono poważne problemy z zabezpieczeniami w libxml2, które są używane w Chromium do analizowania, serializacji i testowania poprawności XML. Aby rozwiązać przyszłe problemy z bezpieczeństwem związane z analizą XML w Chromium, planujemy wycofać użycie libxml2 i zastąpić analizę XML biblioteką analizy 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 przejrzyste dla programistów stron internetowych.

XML + CSS nie są usuwane

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

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

Jak przeprowadzić migrację

Istnieje kilka alternatywnych ścieżek migracji.

JSON

W przypadku witryn, które są w pełni oparte na XML i XSL, nie ma jednego uniwersalnego sposobu na przejście na AMP. Opcje migracji obejmują przeniesienie potoku przetwarzania XSLT na stronę serwera i wysłanie wyrenderowanego kodu HTML do klienta lub przeniesienie punktów końcowych interfejsu XML API po stronie serwera do formatu JSON i przeprowadzenie renderowania po stronie klienta za pomocą JavaScriptu w celu przekształcenia formatu JSON w HTML DOM i CSS.

XSLT po stronie klienta w języku JavaScript

Dostępnych jest kilka bibliotek XSLT po stronie klienta (opartych na języku JavaScript), ale zdecydowanie największą z nich jest biblioteka firmy Saxonica (zobacz kompleksową dokumentację firmy Saxonica). Implementacja wykracza daleko poza implementację XSLT 1.0 w przeglądarkach internetowych, zapewniając pełną obsługę najnowszego standardu w wersji 3.0, a docelowo także opracowywanego standardu w wersji 4.0.

Kod polyfill

Dostępny jest 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 z przeglądarki. Polyfill znajduje się na GitHubie.

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.mi><n.js&qu>ot<;/scri>pt

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

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

W przypadku oryginalnego pliku demo.xml, takiego jak ten:

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

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

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

W takim przypadku nowy element <script> wczytuje polyfill, który wykrywa typ dokumentu XML i instrukcję przetwarzania XSLT, a następnie wczytuje go w sposób przezroczysty, zastępując dokument.

Rozszerzenie

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

W szczególności, gdy XSLT jest wyłączony, Chrome wyświetla teraz baner ostrzegawczy, który prowadzi bezpośrednio do strony wyszukiwania rozszerzeń, aby pomóc użytkownikom znaleźć rozszerzenie:

Konkretne przypadki użycia

W dyskusji na temat standardów HTML zidentyfikowano kilka konkretnych przypadków użycia. W tej sekcji omówimy szczegółowo każdą z tych opcji, aby zaproponować deweloperom publikującym zasoby XML, które obecnie używają XSLT, dalsze kroki.

Kanały RSS i Atom

W wielu istniejących kanałach RSS lub Atom używany jest język XSLT, który sprawia, że nieprzetworzone kanały XML są zrozumiałe dla człowieka, gdy są wyświetlane bezpośrednio w przeglądarce. Głównym zastosowaniem jest sytuacja, gdy użytkownik przypadkowo kliknie link do kanału RSS witryny, zamiast wkleić go do czytnika RSS. Otrzyma wtedy sformatowaną odpowiedź HTML, którą może odczytać, zamiast nieprzetworzonego kodu XML.

W tym przypadku użycia można postąpić na 2 sposoby. „Standardowy” sposób HTML polega na dodaniu do witryny (opartej na HTML) elementu <link rel="alternate" type="application/rss+xml">, a nie jawnego (widocznego dla użytkownika) elementu <a href="something.xml">, który użytkownicy mogą przypadkowo kliknąć. To rozwiązanie pozwala czytnikom RSS znaleźć kanał, jeśli użytkownik wklei tylko adres URL witryny, ale umożliwia też użytkownikom wyświetlanie zwykłej zawartości HTML bez dezorientowania ich linkiem do zasobu XML. Jest to również zgodne z normalnym paradygmatem internetowym, zgodnie z którym HTML jest przeznaczony dla ludzi, a XML dla maszyn. Oczywiście nie rozwiązuje to problemu, gdy użytkownik po prostu „ma” skądś link RSS i wkleja go do przeglądarki (a nie do czytnika RSS).

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

Dane wyjściowe interfejsu API dla urządzeń wbudowanych

Niektóre komercyjne urządzenia wbudowane mierzą lub w inny sposób generują dane XML do wykorzystania przez użytkowników w sieci lokalnej. Niektóre z tych urządzeń robią to, generując pojedynczy plik danych XML, który jest przekształcany w zrozumiały dla człowieka format HTML za pomocą XSLT. Dzięki temu interfejs API można wyświetlać bezpośrednio w przeglądarce bez konieczności stosowania dodatkowego kodu na urządzeniu lub w przeglądarce.
Ponieważ jest to przypadek użycia bardzo 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, można użyć dowolnej z opisanych wcześniej opcji (JSON, polyfill). Wiele takich urządzeń jest jednak trudnych lub niemożliwych do zaktualizowania z różnych powodów. W takim przypadku najlepszym rozwiązaniem jest prawdopodobnie rozszerzenie, ponieważ umożliwia ono przeglądarkom klientów dalsze odczytywanie danych w dokładnie taki sam sposób, bez modyfikowania urządzenia.

Leniwe tworzenie szablonów w witrynach

Programiści stron internetowych czasami używają XSLT po stronie klienta, aby zastosować znaczniki prezentacji do znaczników semantycznych. Działa to jako leniwy język szablonów, który jest oddzielony od ekosystemu JavaScriptu.

Ten bardziej ogólny problem można rozwiązać na 2 sposoby. W przypadku istniejącej witryny utworzonej w ten sposób najprostszym rozwiązaniem jest dodanie kodu polyfill, aby zachować dotychczasowe funkcje. Możesz też przeprowadzić transformację XSLT po stronie serwera i wyświetlić klientowi wynikowy kod HTML, a nie nieprzetworzony kod XML. Długoterminowym rozwiązaniem w przypadku takich usług byłoby przejście na bardziej nowoczesną platformę opartą na języku JavaScript lub formacie JSON.

Jeśli w Chrome napotkasz 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 opisano 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 wycofywania funkcji. Aby skonfigurować go do raportowania wycofania XSLT, można 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, jak ten kod działa w CodePen

Raport o starszych technologiach dla przedsiębiorstw

Administratorzy firm 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 w Centrum pomocy Google.