Gepubliceerd: 29 oktober 2025
Chrome is van plan XSLT te beëindigen en te verwijderen uit de browser. In dit document wordt uitgelegd hoe je je code kunt migreren voordat de verwijdering eind 2026 plaatsvindt.
Chromium heeft XSLT officieel beëindigd, waaronder de JavaScript API XSLTProcessor en de XSLT-verwerkingsinstructie. We zijn van plan de ondersteuning te verwijderen vanaf versie 158 (17 november 2026). De projecten Firefox en WebKit hebben ook aangegeven dat ze van plan zijn XSLT te verwijderen uit hun browserengines. In dit document vind je wat geschiedenis en context, leggen we uit hoe we XSLT verwijderen om Chrome veiliger te maken en bieden we een pad voor migratie voordat deze functies uit de browser worden verwijderd. Ga ook naar de vermelding in het Chrome-statusplatform voor de nieuwste updates.
Wat wordt er verwijderd?
Er zijn 2 API's in de browser die XSLT implementeren en beide worden verwijderd:
- De klasse XSLTProcessor (bijvoorbeeld
new XSLTProcessor()). - De XSLT-verwerkingsinstructie (bijvoorbeeld
<?xml-stylesheet type="text/xsl" ... ?>).
Tijdlijn voor Chrome
Chrome heeft het volgende plan:
- Chrome 142 (28 oktober 2025): Er worden consoleberichten met vroege waarschuwingen toegevoegd aan Chrome.
- Chrome 143 (2 december 2025): Officiële beëindiging van de API. Er worden waarschuwingsberichten over de beëindiging getoond in de console en in Lighthouse.
- Chrome 145 (2 december 2025 Canary): Canary-, Dev- en Bèta-releases beginnen XSLT standaard uit te zetten als vroege waarschuwing.
- Chrome 146 (10 maart 2026): Zakelijk beleid (EP) gaat live voor testen. Zo kunnen bedrijven het uitzetten van XSLT vroegtijdig testen en functies blijven gebruiken na de verwijderingsdatum.
- Chrome 152 (25 augustus 2026): Origin trial (OT) gaat live voor testen. Hiermee kunnen sites functies blijven gebruiken na de verwijderingsdatum.
- Chrome 154 (22 september 2026): De Canary-, Dev- en Bèta-releases van Webview zetten XSLT standaard uit als vroege waarschuwing.
- Chrome 158 (17 november 2026): XSLT werkt niet meer in stabiele releases voor alle gebruikers behalve deelnemers aan de origin trial en het zakelijk beleid.
- Chrome 176 (17 augustus 2027): Origin trial en zakelijk beleid werken niet meer. XSLT is uitgezet voor alle gebruikers.
Wat is XSLT?
XSLT, of Extensible Stylesheet Language Transformations, is een taal die wordt gebruikt om XML-documenten te transformeren, meestal naar andere indelingen 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.
Als een browser een XML-bestand krijgt dat is gekoppeld aan een XSLT-stylesheet, gebruikt de browser de regels in die stylesheet om de onbewerkte XML-gegevens opnieuw te rangschikken, op te maken en te converteren naar een gestructureerde pagina (vaak HTML) die voor de gebruiker kan worden weergegeven.
Een XSLT-stylesheet kan bijvoorbeeld de volgende XML-invoer gebruiken:
<?xml version=">1<.0"?
?xml-stylesheet type="text/xsl&quo>t<; hr>ef<=">demo.xsl" ?
<page
me>s<sage
> Hello World.
/message
/page
en deze 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
en verwerkt ze in deze HTML die de browser kan weergeven: HTML
<body>
<p>Message: Hello World.</p>
</body>
Naast de XSL-verwerkingsinstructie in het vorige voorbeeld is er ook de JavaScript API XSLTProcessor, die kan worden gebruikt om lokale XML-documenten te verwerken met lokale XSLT-stylesheets.
Geschiedenis van XSLT
XSLT werd op 16 november 1999 aanbevolen door het World Wide Web Consortium (W3C) als een taal om XML-documenten om te zetten in andere indelingen, meestal HTML voor weergave in webbrowsers. Vóór de officiële 1.0-aanbeveling nam Microsoft een vroeg initiatief door een eigen implementatie te leveren op basis van een W3C-werkconcept in Internet Explorer 5.0, uitgebracht in maart 1999. Volgens de officiële standaard heeft Mozilla eind 2000 native XSLT 1.0-ondersteuning geïmplementeerd in Netscape 6. Andere grote browsers, waaronder Safari, Opera en latere versies van Chrome, bevatten ook native XSLT 1.0-processors, waardoor XML-naar-HTML-transformaties aan de clientzijde een levensvatbare webtechnologie werden in het begin van de jaren 2000.
De XSLT-taal zelf bleef zich ontwikkelen, met de release van XSLT 2.0 in 2007 en XSLT 3.0 in 2017. Deze versies introduceerden krachtige functies zoals reguliere expressies, verbeterde gegevenstypen en de mogelijkheid om json te verwerken. De browserondersteuning stagneerde echter. Op dit moment bieden alle grote webbrowsermotoren alleen native ondersteuning voor de oorspronkelijke XSLT 1.0 uit 1999. Maar door het gebrek aan verdere ontwikkeling, de opkomst van het gebruik van JSON als wire-indeling en JavaScript-bibliotheken en -frameworks (zoals jQuery, React en Vue.js) die flexibelere en krachtigere DOM-manipulatie en -templates bieden, is er een aanzienlijke afname in het gebruik van XSLT aan de clientzijde. De rol van XSLT in de webbrowser is grotendeels vervangen door deze op JavaScript gebaseerde technologieën.
Waarom moet XSLT worden verwijderd?
De voortdurende opname 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 berucht vanwege kwetsbaarheden voor geheugenveiligheid, zoals bufferoverloop, die kunnen leiden tot willekeurige code-uitvoering. Beveiligingsaudits en bugtrackers hebben bijvoorbeeld herhaaldelijk ernstige kwetsbaarheden in deze parsers vastgesteld (bijvoorbeeld CVE-2025-7425 en CVE-2022-22834, beide in libxslt). Omdat XSLT aan de clientzijde nu een niche is en zelden wordt gebruikt, krijgen deze bibliotheken veel minder onderhoud en beveiligingsonderzoek dan de kern-JavaScript-engines. Toch vormen ze een rechtstreeks, krachtig risico op aanvallen voor de verwerking van niet-vertrouwde webcontent. XSLT is de bron van verschillende recente, belangrijke beveiligingslekken die browsergebruikers nog steeds in gevaar brengen. De beveiligingsrisico's van deze kwetsbare, verouderde functionaliteit wegen veel zwaarder dan het beperkte nut ervan.
Bovendien is het oorspronkelijke doel van XSLT aan de clientzijde (gegevens transformeren naar renderbare HTML) vervangen door veiligere, ergonomischere en beter onderhouden JavaScript-API's. Moderne webontwikkeling is afhankelijk van zaken als de Fetch API om gegevens op te halen (meestal JSON) en de DOMParser API om XML- of HTML-tekenreeksen veilig te parseren in een DOM-structuur binnen de beveiligde JavaScript-sandbox van de browser. Frameworks zoals React, Vue en Svelte beheren de weergave van deze gegevens dan efficiënt en beveiligd. Deze moderne toolchain wordt actief ontwikkeld, profiteert van de enorme investeringen in de beveiliging van JavaScript-engines en wordt tegenwoordig door vrijwel alle webontwikkelaars gebruikt. Op dit moment gebruikt maar ongeveer 0, 02% van de geladen webpagina's XSLT en minder dan 0, 001% gebruikt XSLT-verwerkingsinstructies.
Dit is niet alleen een Chrome- of Chromium-actie: de andere 2 grote browserengines ondersteunen ook de verwijdering van XSLT van het webplatform: WebKit, Gecko.
Om deze redenen vermindert de beëindiging en verwijdering van XSLT het risico op aanvallen via de browser voor alle gebruikers, wordt het webplatform vereenvoudigd en kunnen technische resources worden gericht op de beveiliging van de technologieën die het moderne web mogelijk maken, zonder dat ontwikkelaars praktische mogelijkheden verliezen.
Beveiliging van XML-parsering verbeteren
Net als de ernstige beveiligingsproblemen in libxslt, zijn er onlangs ernstige beveiligingsproblemen gemeld voor libxml2, dat in Chromium wordt gebruikt voor parseren, serialisatie en het testen van de juistheid van XML. We willen toekomstige beveiligingsproblemen met XML-parsing in Chromium aanpakken door het gebruik van libxml2 uit te faseren en XML-parsing te vervangen door een geheugenveilige XML-parsing-bibliotheek die is geschreven in Rust. Belangrijk: We verwijderen XML niet uit de browser. Alleen XSLT wordt overwogen voor verwijdering. We willen ervoor zorgen dat de vervanging van libxml2 volledig transparant is voor webontwikkelaars.
XML + CSS wordt niet verwijderd
Het is belangrijk om onderscheid te maken tussen de beëindiging van XSLT (<?xml-stylesheet type="text/xsl" ... ?>) en de verwerkingsinstructie <?xml-stylesheet ... ?> zelf, die ondersteund blijft bij gebruik met CSS. Je kunt de verwerkingsinstructie nog steeds gebruiken met
type="text/css" om standaard lay-out- en ontwerpregels toe te passen op je onbewerkte gegevens,
net zoals je dat kunt doen met HTML. Voorbeeld:
<?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
Migratieproces
Er zijn een paar alternatieve migratiepaden.
Json
Voor sites die volledig zijn gebaseerd op XML en XSL, is er geen universele manier om de overstap te maken. Migratieopties zijn onder andere de XSLT-verwerkingspipeline naar de serverzijde verplaatsen en de gerenderde HTML naar de client sturen, of XML API-eindpunten aan de serverzijde migreren naar JSON en rendering aan de clientzijde uitvoeren met JavaScript om JSON om te zetten in HTML DOM en CSS.
XSLT aan de clientzijde in JavaScript
Er zijn een paar XSLT-bibliotheken aan de clientzijde (op basis van JavaScript) beschikbaar, maar 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. Er wordt volledige ondersteuning geïmplementeerd voor de nieuwste v3.0-standaard en uiteindelijk de v4.0-standaard die in ontwikkeling is.
Polyfill
Er is een polyfill die probeert bestaande code, die afhankelijk is van de implementaties van XSLT 1.0 door webbrowsers, te laten blijven werken zonder de systeemeigen XSLT-functies van de browser te gebruiken. De polyfill staat op GitHub.
De polyfill bevat een functionele, op WASM gebaseerde polyfill-vervanging voor de klasse XSLTProcessor, zodat bestaande JavaScript-code ongewijzigd blijft werken:
<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
De polyfill biedt ook een automatische hulpprogrammafunctie om XML-documenten die XSLT-verwerkingsinstructies gebruiken, makkelijk te vervangen:
Voor een origineel demo.xml-bestand zoals dit:
<?xml version=">1<.0"?
?xml-stylesheet type="text/xsl&qu>o<t; h>ref="demo.xsl"?
ROOT
...content...
Je kunt één regel toevoegen om de polyfill aan te roepen en het document te transformeren met de verwezen XSLT-stylesheet:
<?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 dit geval laadt het nieuwe element <script> de polyfill, die het XML-documenttype en de XSLT-verwerkingsinstructie herkent en deze transparant laadt, waardoor het document wordt vervangen.
Extensie
Er is ook een Chrome-extensie die kan worden toegevoegd aan ondersteunde browsers. Deze past dezelfde XSLT-polyfill toe op alle onbewerkte XML-pagina's die XSLT-verwerkingsinstructies of aanroepen naar XSLTProcessor bevatten. Dit kan worden gebruikt voor apps waarbij de bron-XML of XSLT niet kan worden gewijzigd, om de functionaliteit te behouden.
Als XSLT uitstaat, toont Chrome nu een waarschuwingsbanner die rechtstreeks naar een zoekpagina voor extensies linkt, zodat gebruikers een extensie kunnen vinden:
Specifieke use cases
In de discussie over HTML-standaarden zijn verschillende concrete use cases vastgesteld. In dit gedeelte wordt elk van deze opties specifiek besproken om ontwikkelaars die XML-bronnen publiceren die vandaag de dag XSLT gebruiken, aan te bevelen hoe ze verder kunnen gaan.
RSS- en Atom-feeds
In veel bestaande RSS- of Atom-feeds wordt XSLT gebruikt om onbewerkte XML-feeds door mensen leesbaar te maken wanneer ze rechtstreeks in een browser worden bekeken. De primaire use case is dat wanneer een gebruiker per ongeluk op de link van de RSS-feed van een site klikt, in plaats van die link in de RSS-lezer te plakken, de gebruiker een opgemaakte HTML-reactie krijgt die kan worden gelezen, in plaats van de onbewerkte XML zelf.
Er zijn 2 manieren om dit te doen. De 'standaard' HTML-manier om dit te doen is door <link rel="alternate" type="application/rss+xml"> toe te voegen aan een (op HTML gebaseerde) site, in plaats van een expliciete (voor gebruikers zichtbare) <a
href="something.xml"> toe te voegen waarop gebruikers per ongeluk kunnen klikken. Met deze oplossing kunnen RSS-lezers de feed vinden als een gebruiker alleen de website-URL plakt, maar kunnen menselijke gebruikers ook de normale HTML-content zien zonder in de war te raken door een link naar een XML-bron. Dit volgt ook het normale webparadigma dat HTML voor mensen is en XML voor machines. Dit lost natuurlijk niet het geval op waarin een gebruiker een RSS-link van ergens 'heeft' en deze in de webbrowser (in plaats van de RSS-lezer) plakt.
Als die oplossing niet gewenst is, biedt de polyfill een andere optie. Zoals eerder vermeld, kan de RSS-/Atom XML-feed worden uitgebreid met één regel, <script
src="xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script>, die het bestaande gedrag van op XSLT gebaseerde transformatie naar HTML behoudt.
Dit heeft geen invloed op de mogelijkheid van de RSS-lezer om de XML te blijven parseren, omdat de <script> een direct onderliggend element van het hoofdelement is.
API-uitvoer voor ingesloten apparaten
Sommige commerciële ingesloten 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 door mensen leesbare HTML-indeling. Zo kan de API rechtstreeks 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 apps waarbij de broncode van het ingesloten apparaat kan worden geüpdatet, kunnen alle eerder beschreven opties (JSON, Polyfill) werken. Veel van dergelijke apparaten zijn om verschillende redenen moeilijk of onmogelijk te updaten. In dat geval is de
extensie
waarschijnlijk de beste optie, omdat clientbrowsers de gegevens dan op precies dezelfde manier kunnen blijven lezen zonder het apparaat aan te passen.
Lazy templating voor websites
Webontwikkelaars gebruiken XSLT soms aan de clientzijde om presentatieopmaak toe te passen op semantische opmaak. Dit fungeert als een luie sjabloontaal die losstaat van het JavaScript-ecosysteem.
Er zijn 2 oplossingen voor dit algemenere probleem. Voor een bestaande site die op deze manier is gebouwd, is de makkelijkste oplossing waarschijnlijk om de polyfill toe te voegen om de bestaande functionaliteit te behouden. Of voer de XSLT-transformatie uit aan de serverzijde en lever de resulterende HTML aan de client in plaats van de onbewerkte XML. De oplossing voor de langere termijn voor dergelijke property's is migreren naar een moderner JavaScript- of JSON-gebaseerd framework.
Als je een specifiek probleem tegenkomt in Chrome dat verband houdt met deze beëindiging van XSLT, meld je hier een bug.
Het gebruik van XSLT opsporen
Over het algemeen kunnen beëindigde functies zoals XSLT op een paar manieren worden gedetecteerd in je codebase. In dit gedeelte worden er 2 beschreven.
De Reporting API
De Reporting API is een algemeen rapportagemechanisme voor web-apps om te rapporteren over verschillende platformfuncties en -voorwaarden, waaronder beëindiging van functies. Als je dit wilt instellen om te rapporteren over de beëindiging van XSLT, kun je een codefragment zoals dit gebruiken:
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();
Bekijk deze code in actie op CodePen.
Het rapport Verouderde technologie voor bedrijven
Beheerders van een bedrijf kunnen het rapport over verouderde technologie gebruiken om automatisch het gebruik van beëindigde functies te verzamelen en hier op een gebruiksvriendelijke manier over te rapporteren. Ga naar dit Google Support-artikel voor meer informatie over hoe je deze functie aanzet.