Gepubliceerd: 29 oktober 2025
Chrome is van plan XSLT uit te faseren en uit de browser te verwijderen. Dit document beschrijft hoe u uw code kunt migreren vóór deze verwijdering eind 2026.
Chromium heeft XSLT officieel afgekeurd, inclusief de XSLTProcessor JavaScript API en de XML-stylesheetverwerkingsinstructie . We zijn van plan de ondersteuning hiervoor te verwijderen vanaf versie 155 (17 november 2026). De Firefox- en WebKit -projecten hebben ook aangegeven XSLT uit hun browserengines te willen verwijderen. Dit document geeft een overzicht van de achtergrond 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. Voor de meest recente updates kunt u ook het Chrome Platform Status-item raadplegen.
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): Waarschuwingsberichten in de console toegevoegd aan Chrome.
- Chrome 143 (2 december 2025): Officiële uitfasering van de API - waarschuwingsberichten over de uitfasering verschijnen in de console en in Lighthouse.
- Chrome 148 (Canary-versie van 10 maart 2026): Canary-, Dev- en Beta-versies schakelen XSLT standaard uit als een soort waarschuwing.
- Chrome 152 (25 augustus 2026): Origin Trial (OT) en Enterprise Policy (EP) worden beschikbaar gesteld voor testen. Hiermee kunnen websites en bedrijven functies blijven gebruiken na de datum waarop ze worden verwijderd.
- Chrome 155 (17 november 2026): XSLT werkt niet meer in stabiele versies, voor alle gebruikers behalve deelnemers aan Origin Trial en Enterprise Policy.**
- Chrome 164 (17 aug. 2027): Origin Trial en Enterprise Policy werken niet meer. XSLT is uitgeschakeld voor alle gebruikers.**
Wat is XSLT?
XSLT, ofwel Extensible Stylesheet Language Transformations, is een taal die wordt gebruikt om XML-documenten om te zetten, meestal naar andere formaten zoals HTML. Het maakt gebruik van 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 een browser een XML-bestand ontvangt dat verwijst naar een XSLT-stylesheet, gebruikt de browser de regels in die stylesheet om de ruwe XML-gegevens te herschikken, te formatteren en om te zetten in een gestructureerde pagina (vaak HTML) die aan de gebruiker kan worden getoond.
Een XSLT-stylesheet kan bijvoorbeeld de volgende XML-invoer accepteren:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl" ?>
<page>
<message>
Hello World.
</message>
</page>
en dit XSL-stijlbestand:
<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 deze verwerken tot deze HTML-code die de browser kan weergeven: HTML
<body>
<p>Message: Hello World.</p>
</body>
Naast de XSL-verwerkingsinstructie die in het vorige voorbeeld werd getoond, is er ook de XSLTProcessor JavaScript API die kan worden gebruikt om lokale XML-documenten met lokale XSLT-stijlbladen te verwerken.
Geschiedenis van XSLT
XSLT werd op 16 november 1999 door het World Wide Web Consortium (W3C) aanbevolen als een taal voor het omzetten van XML-documenten naar andere formaten, meestal HTML, voor weergave in webbrowsers. Voordat de officiële aanbeveling voor versie 1.0 kwam, nam Microsoft al vroeg het initiatief door een eigen implementatie, gebaseerd op een W3C-werkversie, te leveren in Internet Explorer 5.0 , dat in maart 1999 werd uitgebracht. Na 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, namen ook native XSLT 1.0-processors op, waardoor client-side XML-naar-HTML-transformaties begin jaren 2000 een haalbare webtechnologie werden.
De XSLT-taal zelf bleef zich ontwikkelen, 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. De browserondersteuning stagneerde echter. Tegenwoordig bieden alle belangrijke webbrowsers alleen nog native ondersteuning voor de originele XSLT 1.0 uit 1999. Dit gebrek aan vooruitgang, in combinatie met de opkomst van JSON als communicatieformaat en JavaScript-bibliotheken en -frameworks (zoals jQuery, React en Vue.js) die flexibelere en krachtigere DOM-manipulatie en templating bieden, heeft geleid tot een aanzienlijke afname van het gebruik van client-side XSLT. De rol ervan binnen de webbrowser is grotendeels overgenomen 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 geheugenveiligheidslekken zoals bufferoverloop, wat kan leiden tot het uitvoeren van willekeurige code. Zo hebben beveiligingsaudits en bugtrackers herhaaldelijk ernstige kwetsbaarheden in deze parsers geïdentificeerd (bijv. CVE-2025-7425 en CVE-2022-22834 , beide in libxslt). Omdat client-side XSLT nu een nichefunctie is die zelden wordt gebruikt, krijgen deze bibliotheken veel minder onderhoud en beveiligingscontrole dan de kern-JavaScript-engines, terwijl ze een direct en krachtig aanvalsoppervlak vormen voor het verwerken van onbetrouwbare webinhoud. XSLT is dan ook de bron van verschillende recente , spraakmakende beveiligingslekken die browsergebruikers blijven bedreigen. De veiligheidsrisico's van 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 naar renderbare HTML – achterhaald door veiligere, ergonomischere en beter onderhouden JavaScript API's. Moderne webontwikkeling vertrouwt op API's zoals de Fetch API om data (meestal JSON) op te halen en de DOMParser API om XML- of HTML-strings veilig te parsen naar een DOM-structuur binnen de beveiligde JavaScript-sandbox van de browser. Frameworks zoals React, Vue en Svelte beheren vervolgens de weergave van deze data efficiënt en veilig. Deze moderne toolchain wordt actief ontwikkeld, profiteert van de enorme investeringen in beveiliging in JavaScript-engines en wordt tegenwoordig door vrijwel alle webontwikkelaars gebruikt. Sterker nog, slechts ongeveer 0,02% van de webpagina's gebruikt tegenwoordig nog XSLT, en minder dan 0,001% gebruikt XSLT-verwerkingsinstructies.
Dit is geen actie die alleen Chrome of Chromium uitvoert: de andere twee belangrijke browserengines ondersteunen ook het verwijderen van XSLT uit het webplatform: WebKit en Gecko .
Om deze redenen verkleint het afschaffen en verwijderen van XSLT het aanvalsoppervlak van de browser voor alle gebruikers, vereenvoudigt het het webplatform en kunnen technische resources zich richten op het beveiligen van de technologieën die het moderne web daadwerkelijk aandrijven, zonder dat ontwikkelaars in de praktijk aan functionaliteit inboeten.
Verbetering van de beveiliging bij het parsen van XML
Net als bij de ernstige beveiligingsproblemen met libxslt, zijn er recentelijk ook ernstige beveiligingsproblemen gemeld met libxml2, dat in Chromium wordt gebruikt voor het parsen, serialiseren en testen van de correcte structuur 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 de 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 te verwijderen. We streven ernaar dat de vervanging van libxml2 volledig transparant is voor webontwikkelaars.
Hoe migreren?
Er zijn een aantal alternatieve migratiemogelijkheden.
JSON
Voor websites die volledig op XML en XSL zijn gebouwd, bestaat er geen standaardmethode voor de overstap. Migratiemogelijkheden zijn onder andere het verplaatsen van de XSLT-verwerkingspipeline naar de serverzijde en het verzenden van de gegenereerde 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 aantal client-side (op JavaScript gebaseerde) XSLT-bibliotheken beschikbaar, maar de verreweg grootste is die van 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 ook voor de in ontwikkeling zijnde v4.0-standaard .
Polyfill
Er bestaat een polyfill die ervoor zorgt dat bestaande code, die afhankelijk is van de XSLT 1.0-implementaties van webbrowsers, blijft functioneren zonder gebruik te maken van de native XSLT-functies van de browser. De polyfill is te vinden op GitHub .
De polyfill bevat een functionele, op WASM gebaseerde, gepolyfillde vervanging voor de XSLTProcessor-klasse, zodat bestaande JavaScript-code gewoon 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>
De polyfill biedt ook een automatische hulpprogrammafunctie waarmee XML-documenten die XSLT-verwerkingsinstructies gebruiken, eenvoudig kunnen worden vervangen.
Voor een origineel demo.xml -bestand zoals dit:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
...content...
Met één regel code kan de polyfill worden aangeroepen en het document worden getransformeerd met behulp van het XSLT-stijlbestand waarnaar wordt verwezen:
<?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 aan ondersteunde browsers kan worden toegevoegd. Deze extensie past dezelfde XSLT-polyfill toe op alle onbewerkte XML-pagina's die XSLT-verwerkingsinstructies of aanroepen naar XSLTProcessor bevatten. Dit kan worden gebruikt voor toepassingen waarbij de bron-XML of XSLT niet kan worden gewijzigd, om de functionaliteit te behouden.
Met name wanneer XSLT is uitgeschakeld, toont Chrome nu een waarschuwingsbanner die direct linkt naar een pagina voor het zoeken naar extensies, zodat gebruikers een extensie kunnen vinden:
Specifieke gebruiksscenario's
In de discussie over HTML-standaarden werden verschillende concrete gebruiksscenario's geïdentificeerd. In dit gedeelte wordt elk scenario specifiek besproken, om aanbevelingen te doen voor ontwikkelaars die momenteel XML-bronnen publiceren die XSLT gebruiken.
RSS- en Atom-feeds
In veel bestaande RSS- of Atom-feeds wordt XSLT gebruikt om ruwe XML-feeds leesbaar te maken voor mensen wanneer ze direct in een browser worden bekeken. Het belangrijkste gebruiksscenario is dat wanneer een gebruiker per ongeluk op een RSS-feedlink van een site klikt, hij of zij in plaats van de link in de RSS-reader te plakken, een opgemaakte HTML-respons krijgt die kan worden gelezen.
Er zijn twee manieren om dit probleem op te lossen. De "standaard" HTML-manier is om <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 zouden kunnen klikken. Deze oplossing stelt RSS-lezers in staat de feed te vinden als een gebruiker alleen de URL van de website plakt, maar zorgt er ook voor dat gebruikers de reguliere HTML-inhoud kunnen zien zonder in de war te raken door een link naar een XML-bron. Dit volgt ook het gangbare webparadigma dat HTML voor mensen is en XML voor machines. Dit lost natuurlijk niet het probleem op waarbij een gebruiker een RSS-link van ergens "heeft" en deze in zijn webbrowser plakt (in plaats van in zijn RSS-lezer).
Als die oplossing niet gewenst is, biedt de polyfill een alternatief. 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> , waardoor het bestaande gedrag van XSLT-gebaseerde transformatie naar HTML behouden blijft. Dit zou geen invloed mogen hebben op het vermogen van de RSS-lezer om de XML te blijven parsen, aangezien <script> een direct kindelement is van het root-element.
API-uitvoer voor ingebedde apparaten
Sommige commerciële embedded apparaten meten of genereren XML-gegevens die door gebruikers op het lokale netwerk kunnen worden gebruikt. Sommige van deze apparaten doen dit door één enkele XML-datafeed te genereren die met behulp van XSLT wordt omgezet in een 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 toepassingsspecifiek gebruiksscenario is, kan de vorm van de oplossing variëren. Voor toepassingen waarbij de broncode van het embedded apparaat kan worden bijgewerkt, zouden alle eerder beschreven opties (JSON, Polyfill) kunnen werken. In het bijzonder zijn veel van dergelijke apparaten echter om verschillende redenen moeilijk of onmogelijk bij te werken. In dat geval is de extensie waarschijnlijk de beste optie, omdat clientbrowsers hiermee de gegevens op exact dezelfde manier kunnen blijven lezen, zonder het apparaat aan te passen.
Lazy templates voor websites
Webontwikkelaars gebruiken XSLT soms aan de clientzijde om presentatiemarkup toe te passen op semantische markup. Het functioneert als een luie sjabloonengine die losstaat van het JavaScript-ecosysteem.
Er zijn twee oplossingen voor dit meer algemene probleem. Voor een bestaande website die op deze manier is gebouwd, is de eenvoudigste oplossing waarschijnlijk om de polyfill toe te voegen om de bestaande functionaliteit te behouden. Of misschien is het beter om de XSLT-transformatie aan de serverzijde uit te voeren en de resulterende HTML naar de client te sturen in plaats van de ruwe XML. Een oplossing voor de lange termijn voor dergelijke websites zou zijn om over te stappen naar een moderner JavaScript- of JSON-gebaseerd framework.
Als je in Chrome een specifiek probleem tegenkomt dat verband houdt met deze afschaffing van XSLT, meld dan hier een bug .
Hoe detecteer je het gebruik van XSLT?
Over het algemeen kunnen verouderde functies zoals XSLT op een aantal manieren in uw codebase worden opgespoord. In dit gedeelte worden er twee beschreven.
De rapportage-API
De Reporting API is een algemeen rapportagemechanisme voor webapplicaties om te rapporteren over verschillende platformfuncties en -condities, waaronder het afschaffen van functies. Om de API zo in te stellen dat er gerapporteerd wordt over het afschaffen van XSLT, kan een codefragment zoals dit worden gebruikt:
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 over verouderde bedrijfstechnologieën
Voor beheerders van een organisatie kan het rapport 'Verouderde technologieën' worden gebruikt om automatisch het gebruik van verouderde functies te verzamelen en dit op een gebruiksvriendelijke manier te rapporteren. Zie dit Google Support-artikel voor meer informatie over het inschakelen van deze functie.