Veröffentlicht am 29. Oktober 2025
Chrome plant, XSLT einzustellen und aus dem Browser 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 XSLTProcessor JavaScript API und der XSLT-Verarbeitungs anweisung. Wir planen, die Unterstützung ab Version 158 (17. November 2026) einzustellen. Die Firefox und WebKit Projekte haben ebenfalls Pläne angekündigt, XSLT aus ihren Browser-Engines zu entfernen. In diesem Dokument finden Sie einige Hintergrundinformationen und Kontext, eine Erklärung, warum wir XSLT entfernen, um Chrome sicherer zu machen, und eine Anleitung zur Migration, bevor diese Funktionen aus dem Browser entfernt werden. Die neuesten Updates finden Sie auch im Chrome Platform Status-Eintrag.
Was wird entfernt?
Es gibt zwei APIs im Browser, die XSLT implementieren. Beide werden entfernt:
- Die
XSLTProcessor
-Klasse (z. B.
new XSLTProcessor()). - Die XSLT-Verarbeitungs
anweisung
(z. B.
<?xml-stylesheet type="text/xsl" ... ?>).
Zeitplan für Chrome
Chrome hat folgenden Plan:
- Chrome 142 (28. Oktober 2025): Der Konsole werden frühe Warnmeldungen hinzugefügt.
- Chrome 143 (2. Dezember 2025): Offizielle Einstellung der API – in der Konsole und in Lighthouse werden Warnmeldungen zur Einstellung angezeigt.
- Chrome 145 (2. Dezember 2025 Canary): In den Canary-, Dev- und Beta-Versionen wird XSLT standardmäßig deaktiviert, um frühzeitig zu warnen.
- Chrome 146 (10. März 2026): 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): Ursprung Test (OT) wird zu Testzwecken eingeführt. Dadurch können Websites Funktionen auch nach dem Entfernungstermin weiter verwenden.
- 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 wird eine XSLT-Stylesheet-Datei verwendet, um die Regeln für diese Konvertierung zu definieren, und eine XML-Datei mit den als Eingabe verwendeten Daten.
Wenn in Browsern eine XML-Datei empfangen wird, die auf ein XSLT-Stylesheet verweist, verwendet der Browser die Regeln in diesem Stylesheet, um die Roh-XML-Daten neu anzuordnen, zu formatieren und in eine strukturierte Seite (oft HTML) umzuwandeln, 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" href="demo.xsl" ?>
<page>
<message>
Hello World.
</message>
</page>
und dieses XSL-Stylesheet:
<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>
und sie in dieses HTML verarbeiten, das der Browser anzeigen soll: HTML
<body>
<p>Message: Hello World.</p>
</body>
Neben der im vorherigen Beispiel gezeigten XSL-Verarbeitungsanweisung gibt es auch die XSLTProcessor JavaScript API, 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 zum Umwandeln von XML Dokumenten in andere Formate empfohlen, meist in HTML zur Anzeige in Webbrowsern. Vor der offiziellen Empfehlung der Version 1.0 ergriff Microsoft eine frühe Initiative und lieferte eine proprietäre Implementierung auf Grundlage eines W3C-Arbeitsentwurfs in Internet Explorer 5.0 aus, der im März 1999 veröffentlicht wurde. Nach dem offiziellen Standard implementierte Mozilla Ende 2000 in Netscape 6 die native XSLT 1.0 Unterstützung. Andere gängige Browser wie Safari, Opera und später Chrome enthielten ebenfalls native XSLT 1.0-Prozessoren, wodurch clientseitige XML-zu-HTML-Transformationen in den frühen 2000er-Jahren zu einer praktikablen Webtechnologie wurden.
Die XSLT-Sprache selbst wurde weiterentwickelt. Mit der Veröffentlichung von XSLT 2.0 im Jahr 2007 und XSLT 3.0 im Jahr 2017 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. Heute bieten alle gängigen Webbrowser-Engines nur native Unterstützung für das ursprüngliche XSLT 1.0 von 1999. Diese fehlende Weiterentwicklung in Verbindung mit der zunehmenden Verwendung von JSON als Wire-Format sowie JavaScript-Bibliotheken und -Frameworks (wie jQuery, React und Vue.js), die eine flexiblere und leistungsstärkere DOM-Manipulation und -Vorlagenbildung 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 Einbeziehung von XSLT 1.0 in Webbrowser stellt ein erhebliches und unnötiges Sicherheitsrisiko dar. Die zugrunde liegenden Bibliotheken, die diese Transformationen verarbeiten, wie z. B. libxslt (verwendet von Chromium-Browsern), 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 Ausführung von beliebigem Code führen können. Beispielsweise wurden bei Sicherheitsaudits und in Bug Trackern wiederholt schwerwiegende Sicherheitslücken 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 Sicherheits lücken, die Browsernutzer weiterhin gefährden. Die Sicherheitsrisiken, die mit der Wartung dieser anfälligen, veralteten Funktion verbunden sind, überwiegen bei Weitem ihren begrenzten modernen Nutzen.
Außerdem wurde der ursprüngliche Zweck von clientseitiger XSLT – die Umwandlung von Daten in renderbares HTML – durch sicherere, ergonomischere und besser gewartete JavaScript APIs ersetzt. Die moderne Webentwicklung stützt sich auf Dinge wie die Fetch API zum Abrufen von Daten (in der Regel JSON) und die DOMParser API zum sicheren Parsen von XML- oder HTML-Strings in eine DOM-Struktur in 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 fast allen Webentwicklern verwendet. Tatsächlich wird XSLT heute nur bei etwa 0,02% der Web seitenladevorgänge verwendet, bei weniger als 0,001% werden XSLT-Verarbeitungsanweisungen verwendet.
Dies ist keine Aktion, die nur Chrome oder Chromium betrifft. Die beiden anderen gängigen Browser Engines unterstützen ebenfalls die Entfernung von XSLT von der Webplattform: WebKit, Gecko.
Aus diesen Gründen verringert die Einstellung und Entfernung von XSLT die Angriffsfläche des Browsers für alle Nutzer, vereinfacht die Webplattform und ermöglicht es, technische Ressourcen auf die Sicherung der Technologien zu konzentrieren, die das moderne Web tatsächlich antreiben. Für Entwickler geht damit kein praktischer Verlust an Funktionen einher.
Sicherheit beim XML-Parsing verbessern
Ä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 wurde. Wichtig: Wir entfernen XML nicht aus dem Browser. Nur XSLT wird hier für die Entfernung in Betracht gezogen. Wir möchten sicherstellen, dass der Austausch von libxml2 für Webentwickler völlig transparent ist.
XML + CSS wird nicht entfernt
Es ist wichtig, die Einstellung von XSLT
(<?xml-stylesheet type="text/xsl" ... ?>) von der
<?xml-stylesheet ... ?> Verarbeitungsanweisung selbst zu unterscheiden. Diese wird weiterhin unterstützt,
wenn sie mit CSS verwendet wird. Sie können die Verarbeitungsanweisung weiterhin mit
type="text/css" verwenden, um Standardregeln für Layout und Design auf Ihre Rohdaten anzuwenden,
genau wie bei HTML. Beispiel:
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="styles.css"?>
<root>
<item>Content 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 Möglichkeit, die Umstellung vorzunehmen. Zu den Migrationsoptionen gehören das Verschieben der XSLT-Verarbeitung pipeline auf die Serverseite und das Senden des gerenderten HTML an den Client oder die Migration von serverseitigen XML-API-Endpunkten zu JSON und das clientseitige Rendering mit JavaScript, um JSON in HTML DOM und CSS umzuwandeln.
Clientseitige XSLT in JavaScript
Es gibt einige clientseitige (JavaScript-basierte) XSLT-Bibliotheken. Die mit Abstand größte wird von Saxonica produziert (siehe die umfassende Dokumentation für Saxonica). Die Implementierung geht weit über die XSLT 1.0-Implementierung in Webbrowsern hinaus, bietet vollständige Unterstützung für den neuesten v3.0 Standard und schließlich für den in Arbeit befindlichen v4.0 Standard.
Polyesterfaser
Es gibt ein Polyfill, mit dem vorhandener Code, der von den Implementierungen von XSLT 1.0 in Webbrowsern abhängt, weiterhin funktionieren soll, ohne native XSLT-Funktionen des Browsers zu verwenden. Das Polyfill ist auf GitHub verfügbar.
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.min.js"></script>
<script>
const xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsltDoc);
const fragment = xsltProcessor.transformToFragment(xmlDoc, document);
</script>
Das Polyfill bietet auch 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" href="demo.xsl"?>
<ROOT>
...content...
Es kann eine Zeile hinzugefügt werden, um das Polyfill aufzurufen und das Dokument mit dem referenzierten XSLT-Stylesheet zu transformieren:
<?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...
In diesem Fall lädt das neue <script> Element das Polyfill, das den
XML-Dokumenttyp und die XSLT-Verarbeitungsanweisung erkennt und transparent lädt
es, das Dokument ersetzend.
Erweiterung
Es gibt auch eine Chrome Erweiterung, die unterstützten Browsern hinzugefügt werden kann. Sie wendet dasselbe XSLT-Polyfill auf alle Roh- XML-Seiten an, die XSLT-Verarbeitungsanweisungen oder Aufrufe von XSLTProcessor enthalten. Dies kann für Anwendungen verwendet werden, bei denen die XML- oder XSLT-Quelle nicht geändert werden kann, um die Funktionalität beizubehalten.
Wenn XSLT deaktiviert ist, zeigt Chrome jetzt ein Warnbanner an, das direkt zu einer Seite mit der Erweiterungssuche verlinkt ist, damit Nutzer eine Erweiterung finden können:
Spezifische Anwendungsfälle
In der Diskussion zu HTML Standards wurden mehrere konkrete Anwendungs fälle identifiziert. In diesem Abschnitt werden sie einzeln behandelt, um Entwicklern, die heute XML-Ressourcen mit XSLT veröffentlichen, Wege nach vorn zu empfehlen.
RSS- und Atom-Feeds
In vielen vorhandenen RSS- oder Atom-Feeds wird XSLT verwendet, um Roh-XML-Feeds lesbar zu machen, wenn sie direkt in einem Browser angezeigt werden. Der Hauptanwendungsfall ist, dass Nutzer, wenn sie versehentlich auf den RSS-Feed-Link einer Website klicken, anstatt diesen Link in ihren RSS-Reader einzufügen, eine formatierte HTML-Antwort erhalten, die sie lesen können, anstatt das Roh-XML selbst.
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 einen expliziten (für Nutzer sichtbaren) <a
href="something.xml"> hinzuzufügen, auf den Nutzer versehentlich klicken könnten. Mit dieser Lösung können RSS-Reader den Feed finden, wenn ein Nutzer nur die Website-URL einfügt. Außerdem können 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 den Fall, in dem ein Nutzer einfach einen RSS-Link von irgendwo hat und ihn in seinen Webbrowser (anstatt 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 mit einer Zeile ergänzt werden: <script
src="xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script>.
Dadurch wird das vorhandene Verhalten der XSLT-basierten Transformation in HTML beibehalten.
Das sollte die Fähigkeit von RSS-Readern, das XML weiterhin zu parsen, nicht beeinträchtigen, da
das <script> ein direktes 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, die von Nutzern im lokalen Netzwerk verwendet werden können. Einige dieser Geräte generieren dazu einen einzelnen XML-Datenfeed, der mit XSLT in ein für Menschen lesbares 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 dies ein sehr anwendungsspezifischer Anwendungsfall ist, kann die Lösung unterschiedlich aussehen. Bei Anwendungen, bei denen der Quellcode des eingebetteten Geräts aktualisiert werden kann, können alle zuvor beschriebenen Optionen (JSON, Polyfill) funktionieren. Viele solcher Geräte lassen sich jedoch aus verschiedenen Gründen nur schwer oder gar nicht 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 semantische Auszeichnungen auf Präsentationsauszeichnungen anzuwenden. Es fungiert als Lazy Templating-Sprache, die vom JavaScript-Ökosystem getrennt ist.
Für dieses allgemeinere Problem gibt es zwei Lösungen. Für eine vorhandene Website, die auf diese Weise erstellt wurde, ist die einfachste Lösung wahrscheinlich, einfach das Polyfill hinzuzufügen, um die vorhandene Funktionalität beizubehalten. Oder Sie führen die XSLT-Transformation auf der Serverseite durch und stellen dem Client das resultierende HTML anstelle des Roh-XML zur Verfügung. Die langfristigere 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 dieser Einstellung von XSLT feststellen, melden Sie hier einen Fehler.
Verwendung von XSLT erkennen
Im Allgemeinen können eingestellte 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 generischer Berichtsmechanismus für Webanwendungen, mit dem über verschiedene Plattformfunktionen und -bedingungen berichtet werden kann, einschließlich der Einstellung von Funktionen. Um Berichte zur Einstellung von XSLT zu erhalten, kann ein Code-Snippet wie dieses verwendet werden:
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();
Sehen Sie sich diesen Code in Aktion auf CodePen an.
Bericht zu alter Technologie für Unternehmen
Für Administratoren eines Unternehmens kann der Bericht zu alter Technologie verwendet werden, um die Nutzung eingestellter Funktionen automatisch zu erfassen und auf benutzerfreundliche Weise zu melden. Weitere Informationen zum Aktivieren dieser Funktion finden Sie in diesem Google-Support artikel.