Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Entfernen von XSLT für einen sichereren Browser

Mason Freed

Dominik Röttsches

Veröffentlicht: 29. Oktober 2025

Chrome beabsichtigt, XSLT im Browser einzustellen und zu entfernen. In diesem Dokument wird beschrieben, wie Sie Ihren Code vor der Entfernung Ende 2026 migrieren können.

Chromium hat XSLT offiziell eingestellt, einschließlich der JavaScript API XSLTProcessor und der XSLT-Verarbeitungsanweisung. Wir beabsichtigen, die Unterstützung ab Version 158 (17. November 2026) einzustellen. Die Projekte Firefox und WebKit haben ebenfalls Pläne angekündigt, XSLT aus ihren Browser-Engines zu entfernen. In diesem Dokument finden Sie einige Hintergrundinformationen und Kontext. Außerdem wird erläutert, wie wir XSLT entfernen, um Chrome sicherer zu machen, und wie Sie migrieren können, bevor diese Funktionen aus dem Browser entfernt werden. Die neuesten Updates finden Sie auch im Eintrag zum Chrome-Plattformstatus.

Was wird entfernt?

Es gibt zwei APIs im Browser, die XSLT implementieren. Beide werden entfernt:

Die Klasse XSLTProcessor (z. B. new XSLTProcessor()).
Die XSLT-Verarbeitungsanweisung (z. B. <?xml-stylesheet type="text/xsl" ... ?>).

Zeitachse für Chrome

Chrome hat folgenden Plan:

Chrome 142 (28. Oktober 2025): Chrome wurden Frühwarnmeldungen in der Konsole hinzugefügt.
Chrome 143 (2. Dezember 2025): Offizielle Einstellung der API – Warnmeldungen zur Einstellung werden in der Konsole und in Lighthouse angezeigt.
Chrome 145 (2. Dezember 2025, Canary): In Canary-, Dev- und Beta-Releases wird XSLT standardmäßig deaktiviert, um frühzeitig darauf hinzuweisen.
Chrome 146 (10. März 2026): Die Unternehmensrichtlinie wird zu Testzwecken eingeführt. So können Unternehmen die Deaktivierung von XSLT frühzeitig testen und Funktionen auch nach dem Entfernungstermin weiter verwenden.
Chrome 152 (25. August 2026): Der Ursprungstest (Origin Trial, OT) wird zu Testzwecken eingeführt. Dadurch können Websites Funktionen auch nach dem Entfernungstermin weiter verwenden.
Chrome 154 (22. September 2026): In den Canary-, Entwickler- und Beta-Releases von WebView wird XSLT standardmäßig deaktiviert, um frühzeitig zu warnen.
Chrome 158 (17. November 2026): XSLT funktioniert in stabilen Versionen für alle Nutzer außer Teilnehmern am Ursprungstest und an der Unternehmensrichtlinie nicht mehr.
Chrome 176 (17. August 2027): Ursprungstest und Unternehmensrichtlinie funktionieren nicht mehr. XSLT ist für alle Nutzer deaktiviert.

Was ist XSLT?

XSLT (Extensible Stylesheet Language Transformations) ist eine Sprache, mit der XML-Dokumente in andere Formate wie HTML umgewandelt werden. Dabei werden die Regeln für diese Konvertierung in einer XSLT-Stylesheet-Datei definiert und die als Eingabe verwendeten Daten in einer XML-Datei gespeichert.

Wenn ein Browser eine XML-Datei empfängt, die mit einem XSLT-Stylesheet verknüpft ist, verwendet er die Regeln in diesem Stylesheet, um die XML-Rohdaten neu anzuordnen, zu formatieren und in eine strukturierte Seite (häufig HTML) zu konvertieren, die für den Nutzer gerendert werden kann.

Ein XSLT-Stylesheet könnte beispielsweise die folgende XML-Eingabe verwenden:

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

und dieses XSL-Stylesheet:

<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

und verarbeitet sie zu diesem HTML-Code, den der Browser anzeigen kann: HTML

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

Zusätzlich zur XSL-Verarbeitungsanweisung im vorherigen Beispiel gibt es auch die JavaScript API XSLTProcessor, mit der lokale XML-Dokumente mit lokalen XSLT-Stylesheets verarbeitet werden können.

Geschichte von XSLT

XSLT wurde am 16. November 1999 vom World Wide Web Consortium (W3C) als Sprache für die Transformation von XML-Dokumenten in andere Formate empfohlen, am häufigsten HTML für die Anzeige in Webbrowsern. Vor der offiziellen 1.0-Empfehlung ergriff Microsoft die Initiative und lieferte im März 1999 mit Internet Explorer 5.0 eine proprietäre Implementierung auf Grundlage eines W3C-Arbeitsentwurfs aus. Gemäß dem offiziellen Standard implementierte Mozilla Ende 2000 die native XSLT 1.0-Unterstützung in Netscape 6. Andere gängige Browser, darunter Safari, Opera und später Chrome, enthielten ebenfalls native XSLT 1.0-Prozessoren, sodass clientseitige XML-zu-HTML-Transformationen in den frühen 2000er-Jahren zu einer praktikablen Webtechnologie wurden.

Die XSLT-Sprache selbst wurde mit der Veröffentlichung von XSLT 2.0 im Jahr 2007 und XSLT 3.0 im Jahr 2017 weiterentwickelt. Dabei wurden leistungsstarke Funktionen wie reguläre Ausdrücke, verbesserte Datentypen und die Möglichkeit zur Verarbeitung von JSON eingeführt. Die Browserunterstützung stagnierte jedoch. Derzeit bieten alle gängigen Webbrowser-Engines nur native Unterstützung für die ursprüngliche XSLT 1.0-Version von 1999. Diese fehlende Weiterentwicklung in Verbindung mit der zunehmenden Verwendung von JSON als Wire-Format und JavaScript-Bibliotheken und -Frameworks (wie jQuery, React und Vue.js), die eine flexiblere und leistungsstärkere DOM-Manipulation und Vorlagenerstellung ermöglichen, hat zu einem erheblichen Rückgang der Verwendung von clientseitiger XSLT geführt. Ihre Rolle im Webbrowser wurde weitgehend durch diese JavaScript-basierten Technologien ersetzt.

Warum muss XSLT entfernt werden?

Die fortgesetzte Einbindung von XSLT 1.0 in Webbrowser stellt ein erhebliches und unnötiges Sicherheitsrisiko dar. Die zugrunde liegenden Bibliotheken, die diese Transformationen verarbeiten, z. B. libxslt (von Chromium-Browsern verwendet), sind komplexe, veraltete C/C++-Codebasen. Diese Art von Code ist bekanntermaßen anfällig für Speichersicherheitslücken wie Überläufe des Zwischenspeichers, die zur Code-Ausführung von beliebigem Code führen können. Beispielsweise wurden bei Sicherheitsaudits und in Bug-Trackern wiederholt Sicherheitslücken mit hohem Schweregrad in diesen Parsern festgestellt (z.B. CVE-2025-7425 und CVE-2022-22834, beide in libxslt). Da clientseitige XSLT mittlerweile eine Nischenfunktion ist, die nur selten verwendet wird, werden diese Bibliotheken viel seltener gewartet und auf Sicherheit geprüft als die wichtigsten JavaScript-Engines. Sie stellen jedoch eine direkte, wirksame Angriffsfläche für die Verarbeitung nicht vertrauenswürdiger Webinhalte dar. Tatsächlich ist XSLT die Quelle mehrerer kürzlich aufgetretener schwerwiegender Sicherheitslücken, die Browsernutzer weiterhin gefährden. Die Sicherheitsrisiken, die mit der Beibehaltung dieser anfälligen, veralteten Funktionalität verbunden sind, überwiegen bei Weitem den begrenzten Nutzen, den sie heute noch hat.

Darüber hinaus wurde der ursprüngliche Zweck von clientseitigem XSLT – die Umwandlung von Daten in renderbares HTML – durch sicherere, ergonomischere und besser gepflegte JavaScript APIs ersetzt. Die moderne Webentwicklung basiert auf Elementen wie der Fetch API zum Abrufen von Daten (normalerweise JSON) und der DOMParser API zum sicheren Parsen von XML- oder HTML-Strings in eine DOM-Struktur innerhalb der sicheren JavaScript-Sandbox des Browsers. Frameworks wie React, Vue und Svelte verwalten dann das Rendering dieser Daten effizient und sicher. Diese moderne Toolchain wird aktiv weiterentwickelt, profitiert von den massiven Sicherheitsinvestitionen in JavaScript-Engines und wird heute von praktisch allen Webentwicklern verwendet. Tatsächlich wird XSLT heute nur bei etwa 0,02 % der Seitenaufrufe verwendet, wobei weniger als 0,001 % XSLT-Verarbeitungsanweisungen verwenden.

Dies ist keine Aktion, die nur Chrome oder Chromium betrifft: Die beiden anderen großen Browser-Engines unterstützen ebenfalls die Entfernung von XSLT von der Webplattform: WebKit, Gecko.

Aus diesen Gründen wird durch die Einstellung und Entfernung von XSLT die Angriffsfläche des Browsers für alle Nutzer verringert, die Webplattform vereinfacht und es ermöglicht, die Entwicklungsressourcen auf die Sicherung der Technologien zu konzentrieren, die das moderne Web tatsächlich antreiben, ohne dass Entwickler nennenswerte Einbußen bei den Funktionen hinnehmen müssen.

Verbesserung der Sicherheit beim Parsen von XML

Ähnlich wie bei den schwerwiegenden Sicherheitsproblemen in libxslt wurden kürzlich schwerwiegende Sicherheitsprobleme in libxml2 gemeldet, das in Chromium zum Parsen, Serialisieren und Testen der Wohlgeformtheit von XML verwendet wird. Um zukünftige Sicherheitsprobleme beim XML-Parsing in Chromium zu beheben, planen wir, die Verwendung von libxml2 einzustellen und das XML-Parsing durch eine speichersichere XML-Parsing-Bibliothek zu ersetzen, die in Rust geschrieben ist. Wichtig: XML wird nicht aus dem Browser entfernt. Nur XSLT wird hier entfernt. Wir möchten sicherstellen, dass das Ersetzen von libxml2 für Webentwickler vollständig transparent ist.

XML + CSS wird nicht entfernt

Es ist wichtig, die Einstellung von XSLT (<?xml-stylesheet type="text/xsl" ... ?>) von der Verarbeitungsanweisung <?xml-stylesheet ... ?> selbst zu unterscheiden, die bei Verwendung mit CSS weiterhin unterstützt wird. Sie können die Verarbeitungsanweisung mit type="text/css" weiterhin verwenden, um Standardlayout- und Designregeln auf Ihre Rohdaten anzuwenden, genau wie bei HTML. Beispiel:

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

Vorgehensweise

Es gibt einige alternative Migrationspfade.

JSON

Für Websites, die vollständig auf XML und XSL basieren, gibt es keine allgemeingültige Methode für die Umstellung. Zu den Migrationsoptionen gehören das Verschieben der XSLT-Verarbeitungspipeline auf die Serverseite und das Senden des gerenderten HTML-Codes an den Client oder das Migrieren serverseitiger XML-API-Endpunkte zu JSON und das Ausführen des clientseitigen Renderings mit JavaScript, um JSON in HTML-DOM und CSS umzuwandeln.

Clientseitiges XSLT in JavaScript

Es gibt einige clientseitige (JavaScript-basierte) XSLT-Bibliotheken, aber die mit Abstand größte wird von Saxonica erstellt (siehe die umfassende Dokumentation für Saxonica). Die Implementierung geht weit über die XSLT 1.0-Implementierung in Webbrowsern hinaus und bietet vollständige Unterstützung für den neuesten v3.0-Standard und schließlich den in der Entwicklung befindlichen v4.0-Standard.

Polyfill

Es gibt ein Polyfill, das versucht, vorhandenen Code, der von den XSLT 1.0-Implementierungen von Webbrowsern abhängt, weiterhin funktionieren zu lassen, ohne native XSLT-Funktionen des Browsers zu verwenden. Das Polyfill befindet sich auf GitHub.

Das Polyfill enthält einen funktionalen WASM-basierten Polyfill-Ersatz für die XSLTProcessor-Klasse, sodass vorhandener JavaScript-Code unverändert weiter verwendet werden kann:

<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

Das Polyfill bietet außerdem eine automatische Dienstfunktion, mit der XML-Dokumente, die XSLT-Verarbeitungsanweisungen verwenden, einfach ersetzt werden können:

Für eine ursprüngliche demo.xml-Datei wie diese:

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

Sie können eine Zeile hinzufügen, um das Polyfill aufzurufen und das Dokument mit dem referenzierten XSLT-Stylesheet zu transformieren:

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

In diesem Fall wird durch das neue <script>-Element das Polyfill geladen, das den XML-Dokumenttyp und die XSLT-Verarbeitungsanweisung erkennt und transparent lädt, wodurch das Dokument ersetzt wird.

Erweiterung

Es gibt auch eine Chrome-Erweiterung, die unterstützten Browsern hinzugefügt werden kann. Dadurch wird dasselbe XSLT-Polyfill auf alle XML-Rohseiten angewendet, die XSLT-Verarbeitungsanweisungen oder Aufrufe von XSLTProcessor enthalten. Dies kann für Anwendungen verwendet werden, bei denen die Quell-XML oder -XSLT nicht geändert werden kann, um die Funktionalität aufrechtzuerhalten.

Wenn XSLT deaktiviert ist, wird in Chrome jetzt ein Warnbanner mit einem direkten Link zu einer Suchseite für Erweiterungen angezeigt, damit Nutzer eine Erweiterung finden können:

Die in Chrome angezeigte Meldung, wenn XSLT erkannt wird.

Spezifische Anwendungsfälle

In der Diskussion zu HTML-Standards wurden mehrere konkrete Anwendungsfälle identifiziert. In diesem Abschnitt werden die einzelnen Optionen genauer beschrieben, um Entwicklern, die XML-Ressourcen mit XSLT veröffentlichen, Empfehlungen für die Zukunft zu geben.

RSS- und Atom-Feeds

In vielen vorhandenen RSS- oder Atom-Feeds wird XSLT verwendet, um rohe XML-Feeds menschenlesbar zu machen, wenn sie direkt in einem Browser angezeigt werden. Der Hauptanwendungsfall ist, dass ein Nutzer, der einen versehentlichen Klick auf den RSS-Feed-Link einer Website macht, anstatt diesen Link in seinen RSS-Reader einzufügen, eine formatierte HTML-Antwort erhält, die er lesen kann, anstatt des unformatierten XML-Codes.

Für diesen Anwendungsfall gibt es zwei Möglichkeiten. Die „Standard“-HTML-Methode besteht darin, einer (HTML-basierten) Website <link rel="alternate" type="application/rss+xml"> hinzuzufügen, anstatt ein explizites (für Nutzer sichtbares) <a href="something.xml"> hinzuzufügen, auf das Nutzer versehentlich klicken könnten. So können RSS-Reader den Feed finden, wenn ein Nutzer nur die Website-URL einfügt. Gleichzeitig können menschliche Nutzer den regulären HTML-Inhalt sehen, ohne durch einen Link zu einer XML-Ressource verwirrt zu werden. Dies entspricht auch dem normalen Webparadigma, dass HTML für Menschen und XML für Maschinen gedacht ist. Das löst natürlich nicht das Problem, wenn ein Nutzer einen RSS-Link von irgendwoher hat und ihn in seinen Webbrowser (statt in seinen RSS-Reader) einfügt.

Wenn diese Lösung nicht gewünscht ist, bietet das Polyfill eine andere Möglichkeit. Wie bereits erwähnt, kann der RSS-/Atom-XML-Feed um eine Zeile (<script src="xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script>) erweitert werden, um das bestehende Verhalten der XSLT-basierten Transformation in HTML beizubehalten. Das sollte die Fähigkeit des RSS-Readers, den XML-Code weiterhin zu parsen, nicht beeinträchtigen, da das <script>-Element ein direkt untergeordnetes Element des Stammelements ist.

API-Ausgabe für eingebettete Geräte

Einige kommerzielle eingebettete Geräte messen oder generieren auf andere Weise XML-Daten für die Nutzung durch Nutzer im lokalen Netzwerk. Einige dieser Geräte generieren dazu einen einzelnen XML-Datenfeed, der mithilfe von XSLT in ein menschenlesbares HTML-Format umgewandelt wird. So kann die API direkt in einem Browser angezeigt werden, ohne dass zusätzlicher Code auf dem Gerät oder im Browser erforderlich ist.
Da es sich hierbei um einen sehr anwendungsspezifischen Anwendungsfall handelt, kann die Form der Lösung variieren. Für Anwendungen, bei denen der Quellcode des eingebetteten Geräts aktualisiert werden kann, können alle zuvor beschriebenen Optionen (JSON, Polyfill) verwendet werden. Insbesondere sind viele dieser Geräte aus verschiedenen Gründen nur schwer oder gar nicht zu aktualisieren. In diesem Fall ist die Erweiterung wahrscheinlich die beste Option, da Clientbrowser die Daten weiterhin auf genau dieselbe Weise lesen können, ohne das Gerät zu ändern.

Lazy-Templating für Websites

Webentwickler verwenden XSLT manchmal auf der Clientseite, um semantisches Markup mit Präsentations-Markup zu versehen. Es fungiert als Lazy-Templating-Sprache, die vom JavaScript-Ökosystem getrennt ist.

Für dieses allgemeinere Problem gibt es zwei Lösungen. Bei einer bestehenden Website, die auf diese Weise erstellt wurde, ist die einfachste Lösung wahrscheinlich, das Polyfill hinzuzufügen, um die vorhandene Funktionalität beizubehalten. Oder führen Sie die XSLT-Transformation auf der Serverseite durch und stellen Sie dem Client das resultierende HTML anstelle des Roh-XML bereit. Die langfristige Lösung für solche Properties wäre die Migration zu einem moderneren JavaScript- oder JSON-basierten Framework.

Wenn Sie in Chrome ein bestimmtes Problem im Zusammenhang mit der Einstellung von XSLT feststellen, melden Sie den Fehler hier.

XSLT-Nutzung erkennen

Im Allgemeinen können verworfene Funktionen wie XSLT auf verschiedene Arten in Ihrer Codebasis erkannt werden. In diesem Abschnitt werden zwei davon beschrieben.

Reporting API

Die Reporting API ist ein allgemeiner Berichtsmechanismus für Webanwendungen, mit dem Berichte zu verschiedenen Plattformfunktionen und -bedingungen erstellt werden können, einschließlich der Einstellung von Funktionen. Mit einem Code-Snippet wie dem folgenden können Sie die Berichterstellung für die Einstellung von XSLT einrichten:

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

Codebeispiel auf CodePen ansehen

Bericht zu veralteten Technologien für Unternehmen

Administratoren eines Unternehmens können den Bericht zu veralteten Technologien verwenden, um die Nutzung veralteter Funktionen automatisch zu erfassen und in einer nutzerfreundlichen Form zu melden. Weitere Informationen zum Aktivieren dieser Funktion finden Sie in diesem Google-Support-Artikel.