Diese Seite wurde von der Cloud Translation API übersetzt.

Entfernen von XSLT für einen sichereren Browser

Mason Freed

Dominik Röttsches

Veröffentlicht: 29. Oktober 2025

XSLT soll in Chrome eingestellt und entfernt werden. In diesem Dokument wird beschrieben, wie Sie Ihren Code vor der Entfernung Ende 2026 migrieren können.

In Chromium wurde XSLT offiziell als veraltet eingestuft, einschließlich der JavaScript-API XSLTProcessor und der Anweisung zur Verarbeitung von XML-Stylesheets. Wir planen, die Unterstützung für Version 155 am 17. November 2026 einzustellen. Auch die Projekte Firefox und WebKit haben angekündigt, XSLT aus ihren Browser-Engines zu entfernen. In diesem Dokument werden die Hintergründe und der Kontext erläutert. Außerdem wird beschrieben, wie wir XSLT entfernen, um Chrome sicherer zu machen, und wie Sie vor der Entfernung dieser Funktionen aus dem Browser migrieren können.

Was wird entfernt?

Es gibt zwei APIs im Browser, die XSLT implementieren, und beide werden entfernt:

Die Klasse XSLTProcessor (z. B. new XSLTProcessor()).
Die XSLT-Verarbeitungsanweisung (z. B. <?xml-stylesheet … ?>).

Zeitachse für Chrome

Für Chrome ist der folgende Plan verfügbar:

Chrome 142 (28. Oktober 2025): In Chrome werden Konsolennachrichten mit Frühwarnungen hinzugefügt.
Chrome 143 (2. Dezember 2025): Offizielle Einstellung der API – in der Konsole und in Lighthouse werden Einstellungs-Warnmeldungen angezeigt.
Chrome 148 (10. März 2026, Canary): In Canary-, Entwickler- und Betaversionen wird XSLT standardmäßig deaktiviert, um Nutzer frühzeitig zu warnen.
Chrome 152 (25. August 2026): Ursprungstest und Unternehmensrichtlinie werden für Tests eingeführt. Dadurch können Websites und Unternehmen Funktionen auch nach dem Entfernen weiterhin nutzen.
Chrome 155 (17. November 2026): XSLT funktioniert in stabilen Versionen nicht mehr für alle Nutzer außer für Teilnehmer des Origin-Trials und der Unternehmensrichtlinie.**
Chrome 164 (17. August 2027): Der Ursprungstest und die Unternehmensrichtlinie funktionieren nicht mehr. XSLT ist für alle Nutzer deaktiviert.**

Was ist XSLT?

XSLT (Extensible Stylesheet Language Transformations) ist eine Sprache, die zum Transformieren von XML-Dokumenten verwendet wird, in der Regel in andere Formate wie HTML. Dabei wird eine XSLT-Stylesheet-Datei verwendet, um die Regeln für diese Konvertierung zu definieren, sowie eine XML-Datei mit den Daten, die als Eingabe verwendet werden.

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 in eine strukturierte Seite (oft HTML) umzuordnen, zu formatieren und 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" 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 verarbeitet sie zu diesem HTML-Code, der im Browser angezeigt wird: HTML

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

Neben der im vorherigen Beispiel gezeigten XSL-Verarbeitungsanweisung 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 Umwandlung von XML-Dokumenten in andere Formate empfohlen, am häufigsten in HTML für die Anzeige in Webbrowsern. Vor der offiziellen Empfehlung 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. Gemäß dem offiziellen Standard implementierte Mozilla Ende 2000 die native Unterstützung für XSLT 1.0 in Netscape 6. Andere gängige Browser wie Safari, Opera und spätere Chrome-Versionen 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 entwickelte sich weiter. XSLT 2.0 wurde 2007 und XSLT 3.0 2017 veröffentlicht. Diese Versionen führten leistungsstarke Funktionen wie reguläre Ausdrücke, verbesserte Datentypen und die Möglichkeit zur Verarbeitung von JSON ein. Die Browserunterstützung stagnierte jedoch. Alle wichtigen Webbrowser-Engines bieten heute 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 und JavaScript-Bibliotheken und ‑Frameworks (wie jQuery, React und Vue.js), die flexiblere und leistungsstärkere DOM-Manipulation und ‑Vorlagen bieten, hat zu einem erheblichen Rückgang der Verwendung von clientseitigem XSLT geführt. Seine Rolle im Webbrowser wurde weitgehend von diesen JavaScript-basierten Technologien übernommen.

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 (die von Chromium-Browsern verwendet wird), sind komplexe, veraltete C/C++-Codebases. Diese Art von Code ist notorisch anfällig für Speichersicherheitslücken wie Pufferüberläufe, die zur Ausführung von beliebigem Code führen können. Beispielsweise wurden bei Sicherheitsüberprüfungen und in Bug-Trackern wiederholt Sicherheitslücken mit hohem Schweregrad in diesen Parsern identifiziert (z.B. CVE-2025-7425 und CVE-2022-22834, beide in libxslt. Da clientseitiges XSLT mittlerweile eine Nischenfunktion ist, die nur selten verwendet wird, werden diese Bibliotheken viel seltener gewartet und auf Sicherheit geprüft als die JavaScript-Kern-Engines. Sie stellen jedoch eine direkte, wirksame Angriffsfläche für die Verarbeitung nicht vertrauenswürdiger Webinhalte dar. XSLT ist die Quelle mehrerer aktueller schwerwiegender Sicherheitslücken, die Browsernutzer weiterhin gefährden. Die Sicherheitsrisiken, die mit der Beibehaltung dieser anfälligen, alten Funktion verbunden sind, überwiegen bei Weitem ihren begrenzten modernen Nutzen.

Außerdem wurde der ursprüngliche Zweck von clientseitigem XSLT – die Umwandlung von Daten in rendernbares HTML – durch sicherere, ergonomischere und besser gewartete JavaScript-APIs ersetzt. Die moderne Webentwicklung basiert auf APIs wie der Fetch API zum Abrufen von Daten (in der Regel JSON) und der 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 übernehmen dann das effiziente und sichere Rendern dieser Daten. Diese moderne Toolchain wird aktiv weiterentwickelt, profitiert von den massiven Sicherheitsinvestitionen in JavaScript-Engines und wird heute von praktisch allen Webentwicklern verwendet. Tatsächlich werden XSLT-Verarbeitungsanweisungen heute nur bei etwa 0, 02% der Seitenladezeiten verwendet und bei weniger als 0, 001% der Seitenladezeiten werden XSLT-Verarbeitungsanweisungen verwendet.

Dies ist keine Aktion, die nur in Chrome oder Chromium ausgeführt wird. Die beiden anderen wichtigen 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 können Entwicklerressourcen auf die Sicherung der Technologien konzentriert werden, die das moderne Web tatsächlich antreiben. Für Entwickler geht damit kein praktischer Funktionsverlust einher.

Sicherheit beim XML-Parsing verbessern

Ähnlich wie bei den schwerwiegenden Sicherheitsproblemen in libxslt wurden kürzlich schwerwiegende Sicherheits probleme 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: Wir entfernen kein XML aus dem Browser. Nur XSLT wird hier für die Entfernung in Betracht gezogen. Wir möchten sicherstellen, dass der Ersatz von libxml2 für Webentwickler vollständig transparent ist.

Vorgehensweise

Es gibt einige alternative Migrationspfade.

JSON

Für Websites, die vollständig auf XML und XSL basieren, gibt es keine universelle Methode für die Umstellung. Zu den Migrationsoptionen gehören das Verschieben der XSLT-Verarbeitungs-Pipeline auf die Serverseite und das Senden des gerenderten HTML an den Client oder die Migration serverseitiger XML-API-Endpunkte zu JSON und das clientseitige Rendern 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 (umfassende Dokumentation für Saxonica). Die Implementierung geht weit über die XSLT 1.0-Implementierung in Webbrowsern hinaus. Sie bietet vollständige Unterstützung für den neuesten v3.0-Standard und schließlich auch für den in Arbeit befindlichen v4.0-Standard.

Polyfill

Es gibt ein Polyfill, das versucht, vorhandenen Code, der von den Implementierungen von XSLT 1.0 in Webbrowsern abhängt, weiterhin funktionieren zu lassen, 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 funktionieren 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 Hilfsfunktion, mit der XML-Dokumente, die XSLT-Verarbeitungsanweisungen verwenden, auf einfache Weise ersetzt werden können:

Für eine Originaldatei im demo.xml-Format 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 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 zu 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 das Quell-XML oder XSLT nicht geändert werden kann, um die Funktionalität beizubehalten.

Wenn XSLT deaktiviert ist, wird in Chrome jetzt ein Warnbanner angezeigt, das direkt zu einer Seite mit Erweiterungssuche verlinkt ist, damit Nutzer eine Erweiterung finden können:

Die Meldung, die in Chrome angezeigt wird, wenn XSLT erkannt wird.

Spezifische Anwendungsfälle

In der Diskussion über HTML-Standards wurden mehrere konkrete Anwendungsfälle identifiziert. In diesem Abschnitt werden die einzelnen Optionen genauer beschrieben, um Entwicklern, die derzeit 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 Roh-XML-Feeds lesbar zu machen, wenn sie direkt in einem Browser aufgerufen werden. Der primäre Anwendungsfall ist, dass Nutzer, die versehentlich auf den RSS-Feed-Link einer Website klicken, anstatt ihn in ihren RSS-Reader einzufügen, eine formatierte HTML-Antwort erhalten, die sie lesen können, anstatt des Roh-XML-Codes.

Für diesen Anwendungsfall gibt es zwei Möglichkeiten. Die „Standard“-HTML-Methode hierfür besteht darin, <link rel="alternate" type="application/rss+xml"> auf einer (HTML-basierten) Website hinzuzufügen, anstatt ein explizites (für Nutzer sichtbares) <a href="something.xml"> hinzuzufügen, auf das 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 menschliche Nutzer die regulären HTML-Inhalte 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 irgendwoher hat und ihn in seinen Webbrowser (und nicht in seinen RSS-Reader) einfügt.

Wenn diese Lösung nicht gewünscht ist, bietet das Polyfill einen anderen Weg. Wie bereits erwähnt, kann der RSS-/Atom-XML-Feed mit der Zeile <script src="xslt-polyfill.min.js" xmlns="[http://www.w3.org/1999/xhtml](http://www.w3.org/1999/xhtml)"></script> ergänzt werden, um das bisherige Verhalten der XSLT-basierten Transformation in HTML beizubehalten. Das sollte sich nicht auf die Fähigkeit des RSS-Readers auswirken, das XML weiterhin zu parsen, da <script> 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, 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 aufgerufen werden, ohne dass zusätzlicher Code auf dem Gerät oder im Browser erforderlich ist.
Da es sich um einen sehr anwendungsspezifischen Anwendungsfall handelt, kann die Form der Lösung variieren. Bei Anwendungen, bei denen der Quellcode des eingebetteten Geräts aktualisiert werden kann, können alle zuvor beschriebenen Optionen (JSON, Polyfill) funktionieren. Viele dieser 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 dass das Gerät geändert werden muss.

Lazy Templating für Websites

Webentwickler verwenden XSLT manchmal clientseitig, um Präsentations-Markup auf semantisches Markup anzuwenden. 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 es wahrscheinlich am einfachsten, das Polyfill hinzuzufügen, um die vorhandene Funktionalität beizubehalten. Oder Sie führen die XSLT-Transformation auf dem Server aus und stellen 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.