Gepubliceerd: 29 oktober 2025
Chrome is van plan XSLT uit de browser te verwijderen. Dit document beschrijft hoe u uw code kunt migreren vóór de verwijdering eind 2026.
Chromium heeft XSLT officieel afgeschaft, inclusief de XSLTProcessor JavaScript API en de XML-stylesheetverwerkingsinstructie . We zijn van plan de ondersteuning vanaf versie 155 (17 november 2026) te beëindigen. De Firefox- en WebKit -projecten hebben ook aangegeven XSLT uit hun browsers te willen verwijderen. Dit document biedt een stukje geschiedenis en context, legt uit hoe we XSLT verwijderen om Chrome veiliger te maken en biedt een migratiepad voordat deze functies uit de browser worden verwijderd.
Wat wordt er verwijderd?
Er zijn twee API's in de browser die XSLT implementeren, en beide worden verwijderd:
- De XSLTProcessor -klasse (bijvoorbeeld
new XSLTProcessor()). - De XSLT-verwerkingsinstructie (bijvoorbeeld
<?xml-stylesheet … ?>).
Tijdlijn voor Chrome
Chrome heeft het volgende plan:
- Chrome 142 (28 oktober 2025): Er zijn consoleberichten met vroege waarschuwingen toegevoegd aan Chrome.
- Chrome 143 (2 december 2025): Officiële veroudering van de API: waarschuwingsberichten over veroudering worden weergegeven in de console en in Lighthouse.
- Chrome 148 (10 maart 2026 Canary): Canary-, Dev- en bètaversies schakelen XSLT standaard uit als vroege waarschuwing.
- Chrome 152 (25 augustus 2026): Origin Trial (OT) en Enterprise Policy (EP) zijn live gegaan voor tests. Hierdoor kunnen sites en bedrijven functies blijven gebruiken na de verwijderingsdatum.
- Chrome 155 (17 november 2026): XSLT werkt niet meer op stabiele releases, voor alle gebruikers behalve Origin Trial- en Enterprise Policy-deelnemers.**
- Chrome 164 (17 aug. 2027): Origin Trial en Enterprise Policy werken niet meer. XSLT is voor alle gebruikers uitgeschakeld.**
Wat is XSLT?
XSLT, oftewel Extensible Stylesheet Language Transformations, is een taal die gebruikt wordt om XML-documenten te transformeren, meestal naar andere formaten zoals HTML. Het gebruikt een XSLT-stylesheetbestand om de regels voor deze conversie te definiëren en een XML-bestand met de gegevens die als invoer worden gebruikt.
Wanneer in een browser een XML-bestand wordt ontvangen dat is gekoppeld aan een XSLT-stijlblad, gebruikt de browser de regels in dat stijlblad om de onbewerkte XML-gegevens opnieuw te ordenen, op te maken en te converteren naar een gestructureerde pagina (vaak HTML) die voor de gebruiker kan worden weergegeven.
Een XSLT-stijlblad kan bijvoorbeeld de volgende XML-invoer verwerken:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl" ?>
<page>
<message>
Hello World.
</message>
</page>
en dit XSL-stijlblad:
<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>
en verwerk ze in deze HTML zodat de browser ze kan weergeven: HTML
<body>
<p>Message: Hello World.</p>
</body>
Naast de XSL-verwerkingsinstructie die in het vorige voorbeeld is weergegeven, is er ook de XSLTProcessor JavaScript API die kan worden gebruikt om lokale XML-documenten te verwerken met lokale XSLT-stijlbladmodellen.
Geschiedenis van XSLT
XSLT werd op 16 november 1999 aanbevolen door het World Wide Web Consortium (W3C) als taal voor het transformeren van XML-documenten naar andere formaten, meestal HTML, voor weergave in webbrowsers. Vóór de officiële aanbeveling voor versie 1.0 nam Microsoft al een initiatief door een eigen implementatie te leveren, gebaseerd op een W3C-werkversie, in Internet Explorer 5.0 , uitgebracht in maart 1999. In navolging van de officiële standaard implementeerde Mozilla eind 2000 native XSLT 1.0-ondersteuning in Netscape 6. Andere belangrijke browsers, waaronder Safari, Opera en later Chrome, integreerden ook native XSLT 1.0-processoren, waardoor client-side XML-naar-HTML-transformaties begin jaren 2000 een haalbare webtechnologie werden.
De XSLT-taal zelf bleef evolueren, met de release van XSLT 2.0 in 2007 en XSLT 3.0 in 2017 , die krachtige functies introduceerden zoals reguliere expressies, verbeterde gegevenstypen en de mogelijkheid om JSON te verwerken. Browserondersteuning stagneerde echter. Tegenwoordig bieden alle grote webbrowser-engines alleen nog native ondersteuning voor de originele XSLT 1.0 uit 1999. Dit gebrek aan vooruitgang, in combinatie met de opkomst van het gebruik van JSON als een wire-formaat en JavaScript-bibliotheken en -frameworks (zoals jQuery, React en Vue.js) die flexibelere en krachtigere DOM-manipulatie en -templates bieden, heeft geleid tot een aanzienlijke afname in het gebruik van client-side XSLT. De rol ervan binnen de webbrowser is grotendeels overtroffen door deze op JavaScript gebaseerde technologieën.
Waarom moet XSLT verwijderd worden?
De voortdurende integratie van XSLT 1.0 in webbrowsers vormt een aanzienlijk en onnodig beveiligingsrisico. De onderliggende bibliotheken die deze transformaties verwerken, zoals libxslt (gebruikt door Chromium-browsers), zijn complexe, verouderde C/C++-codebases. Dit type code is notoir gevoelig voor kwetsbaarheden in de geheugenveiligheid, zoals bufferoverlopen, die kunnen leiden tot willekeurige code-uitvoering. Zo hebben beveiligingsaudits en bugtrackers herhaaldelijk zeer ernstige kwetsbaarheden in deze parsers geïdentificeerd (bijv. CVE-2025-7425 en CVE-2022-22834 , beide in libxslt). Omdat client-side XSLT nu een niche, zelden gebruikte functie is, krijgen deze bibliotheken veel minder onderhoud en beveiligingscontrole dan de belangrijkste JavaScript-engines, maar ze vormen een direct, krachtig aanvalsoppervlak voor de verwerking van niet-vertrouwde webinhoud. XSLT is zelfs de bron van verschillende recente , opvallende beveiligingslekken die browsergebruikers nog steeds in gevaar brengen. De veiligheidsrisico's die gepaard gaan met het in stand houden van deze kwetsbare, verouderde functionaliteit wegen veel zwaarder dan de beperkte moderne bruikbaarheid ervan.
Bovendien is het oorspronkelijke doel van client-side XSLT – het omzetten van data in renderbare HTML – vervangen door veiligere, ergonomischere en beter onderhouden JavaScript API's. Moderne webontwikkeling vertrouwt op zaken als de Fetch API om data op te halen (meestal JSON) en de DOMParser API om XML- of HTML-strings veilig te parseren naar een DOM-structuur binnen de beveiligde JavaScript-sandbox van de browser. Frameworks zoals React, Vue en Svelte beheren vervolgens de rendering van deze data efficiënt en veilig. Deze moderne toolchain wordt actief ontwikkeld, profiteert van de enorme beveiligingsinvestering in JavaScript-engines en is wat vrijwel alle webontwikkelaars tegenwoordig gebruiken. Sterker nog, slechts ongeveer 0,02% van de webpagina's die tegenwoordig worden geladen, maakt gebruik van XSLT, en minder dan 0,001% gebruikt XSLT-verwerkingsinstructies.
Dit is geen actie die alleen door Chrome of Chromium kan worden uitgevoerd: de andere twee grote browsers ondersteunen ook het verwijderen van XSLT van het webplatform: WebKit en Gecko .
Door XSLT af te schaffen en te verwijderen, wordt het aanvalsoppervlak van de browser voor alle gebruikers verkleind, wordt het webplatform vereenvoudigd en kunnen technische resources zich richten op het beveiligen van de technologieën die het moderne web daadwerkelijk aandrijven, zonder dat dit in de praktijk ten koste gaat van de mogelijkheden van ontwikkelaars.
Verbetering van de beveiliging van XML-parsing
Net als de ernstige beveiligingsproblemen in libxslt, zijn er onlangs ernstige beveiligingsproblemen gemeld met libxml2, dat in Chromium wordt gebruikt voor het parsen, serialiseren en testen van de welgevormdheid van XML. Om toekomstige beveiligingsproblemen met XML-parsing in Chromium aan te pakken, zijn we van plan het gebruik van libxml2 geleidelijk af te bouwen en XML-parsing te vervangen door een geheugenveilige XML-parsingbibliotheek, geschreven in Rust. Belangrijk is dat we XML niet uit de browser zullen verwijderen; alleen XSLT wordt hier overwogen. We willen ervoor zorgen dat de vervanging van libxml2 volledig transparant is voor webontwikkelaars.
Hoe te migreren
Er zijn een paar alternatieve migratieroutes.
JSON
Voor sites die volledig op XML en XSL zijn gebouwd, is er geen universele manier om de overstap te maken. Migratieopties omvatten het verplaatsen van de XSLT-verwerkingspijplijn naar de server en het verzenden van de gerenderde HTML naar de client, of het migreren van server-side XML API-eindpunten naar JSON en het uitvoeren van client-side rendering met behulp van JavaScript om JSON om te zetten in HTML DOM en CSS.
Client-side XSLT in JavaScript
Er zijn een paar client-side (JavaScript-gebaseerde) XSLT-bibliotheken beschikbaar, maar verreweg de grootste wordt geproduceerd door Saxonica (bekijk de uitgebreide documentatie voor Saxonica ). De implementatie gaat veel verder dan de XSLT 1.0-implementatie in webbrowsers en biedt volledige ondersteuning voor de nieuwste v3.0-standaard en uiteindelijk de v4.0-standaard die nog in ontwikkeling is .
Polyfill
Er is een polyfill die probeert bestaande code, die afhankelijk is van de implementaties van XSLT 1.0 in webbrowsers, te laten functioneren zonder de native XSLT-functies van de browser te gebruiken. De polyfill is te vinden op GitHub .
De polyfill bevat een functionele WASM-gebaseerde polyfilled vervanging voor de XSLTProcessor-klasse, zodat bestaande JavaScript-code ongewijzigd kan blijven werken:
<script src="xslt-polyfill.min.js"></script>
<script>
const xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsltDoc);
const fragment = xsltProcessor.transformToFragment(xmlDoc, document);
</script>
Polyfill biedt ook een automatische hulpprogrammafunctie waarmee u op een eenvoudige manier XML-documenten kunt vervangen die gebruikmaken van XSLT-verwerkingsinstructies:
Voor een origineel demo.xml -bestand zoals dit:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
...content...
Er kan één regel worden toegevoegd om de polyfill aan te roepen en het document te transformeren met het gerefereerde XSLT-stijlblad:
<?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 dit geval laadt het nieuwe <script> -element de polyfill, die het XML-documenttype en de XSLT-verwerkingsinstructie detecteert en deze transparant laadt, waarbij het document wordt vervangen.
Verlenging
Er is ook een Chrome-extensie die kan worden toegevoegd aan ondersteunde browsers. Deze extensie past dezelfde XSLT-polyfill toe op alle onbewerkte XML-pagina's die XSLT-verwerkingsinstructies of aanroepen van XSLTProcessor bevatten. Deze extensie kan worden gebruikt voor toepassingen waarbij de bron-XML of XSLT niet kan worden gewijzigd, om de functionaliteit te behouden.
Wanneer XSLT is uitgeschakeld, toont Chrome nu een waarschuwingsbanner met een directe link naar een zoekpagina voor extensies, om gebruikers te helpen een extensie te vinden:
Specifieke use cases
In de discussie over HTML-standaarden werden verschillende concrete use cases geïdentificeerd. In deze sectie wordt specifiek op elk van deze use cases ingegaan om verdere stappen aan te bevelen voor ontwikkelaars die XML-bronnen publiceren die momenteel XSLT gebruiken.
RSS- en Atom-feeds
In veel bestaande RSS- of Atom-feeds wordt XSLT gebruikt om onbewerkte XML-feeds leesbaar te maken wanneer ze rechtstreeks in een browser worden bekeken. Het belangrijkste gebruik is dat wanneer een gebruiker per ongeluk op de RSS-feedlink van een website klikt, deze in plaats van de link in zijn RSS-lezer te plakken, een geformatteerd HTML-antwoord krijgt dat leesbaar is, in plaats van de onbewerkte XML zelf.
Er zijn twee mogelijke toepassingen voor deze use case. De "standaard" HTML-manier om dit te doen is door <link rel="alternate" type="application/rss+xml"> toe te voegen aan een (HTML-gebaseerde) site, in plaats van een expliciete (voor de gebruiker zichtbare) <a href="something.xml"> toe te voegen waar gebruikers per ongeluk op kunnen klikken. Deze oplossing stelt RSS-lezers in staat de feed te vinden als een gebruiker alleen de URL van de website plakt, maar stelt menselijke gebruikers ook in staat de reguliere HTML-inhoud te bekijken zonder in de war te raken door een link naar een XML-bron. Dit volgt ook het normale webparadigma: HTML is voor mensen en XML voor machines. Dit lost natuurlijk niet het geval op waarbij een gebruiker ergens een RSS-link "heeft" en deze in zijn webbrowser plakt (in plaats van in zijn RSS-lezer).
Wanneer die oplossing niet gewenst is, biedt de polyfill een andere mogelijkheid. Zoals eerder vermeld, kan de RSS/Atom XML-feed worden aangevuld met één regel, <script src="xslt-polyfill.min.js" xmlns="[http://www.w3.org/1999/xhtml](http://www.w3.org/1999/xhtml)"></script> , waardoor het bestaande gedrag van XSLT-gebaseerde transformatie naar HTML behouden blijft. Dit zou geen invloed moeten hebben op de mogelijkheid van de RSS-lezer om de XML te blijven parsen, aangezien de <script> een direct onderliggend element is van het root-element.
API-uitvoer voor ingebedde apparaten
Sommige commerciële embedded apparaten meten of genereren op een andere manier XML-gegevens voor gebruik door gebruikers op het lokale netwerk. Sommige van deze apparaten doen dit door één XML-datafeed te genereren die XSLT gebruikt om deze om te zetten in een voor mensen leesbaar HTML-formaat. Hierdoor kan de API direct in een browser worden bekeken zonder dat er extra code op het apparaat of in de browser nodig is.
Omdat dit een zeer toepassingsspecifieke use case is, kan de vorm van de oplossing variëren. Voor toepassingen waarbij de broncode van het embedded apparaat kan worden bijgewerkt, kunnen alle eerder beschreven opties (JSON, Polyfill) werken. Veel van dergelijke apparaten zijn echter om verschillende redenen moeilijk of onmogelijk bij te werken. In dat geval is de extensie waarschijnlijk de beste optie, omdat clientbrowsers de gegevens hiermee op exact dezelfde manier kunnen blijven lezen, zonder het apparaat aan te passen.
Luie sjablonen voor websites
Webontwikkelaars gebruiken XSLT soms aan de clientzijde om presentatiemarkeringen toe te passen op semantische markeringen. Het fungeert dan als een 'luie sjabloontaal' die losstaat van het JavaScript-ecosysteem.
Er zijn twee oplossingen voor dit meer algemene probleem. Voor een bestaande site die op deze manier is gebouwd, is de eenvoudigste oplossing waarschijnlijk om gewoon de polyfill toe te voegen om de bestaande functionaliteit te behouden. Of misschien de XSLT-transformatie op de server uit te voeren en de resulterende HTML aan de client te leveren in plaats van de onbewerkte XML. De meer langetermijnoplossing voor dergelijke eigenschappen zou zijn om te migreren naar een moderner JavaScript- of JSON-gebaseerd framework.