Halaman ini diterjemahkan oleh Cloud Translation API.

Menghapus XSLT untuk browser yang lebih aman

Mason Freed

Dominik Röttsches

Dipublikasikan: 29 Oktober 2025

Chrome bermaksud menghentikan penggunaan dan menghapus XSLT dari browser. Dokumen ini menjelaskan cara memigrasikan kode Anda sebelum penghapusan pada akhir tahun 2026.

Chromium telah secara resmi menghentikan penggunaan XSLT, termasuk XSLTProcessor JavaScript API dan petunjuk pemrosesan stylesheet XML. Kami berencana menghapus dukungan dari versi 155 (17 November 2026). Project Firefox dan WebKit juga telah mengindikasikan rencana untuk menghapus XSLT dari mesin browser mereka. Dokumen ini memberikan beberapa histori dan konteks, menjelaskan cara kami menghapus XSLT untuk membuat Chrome lebih aman, dan memberikan jalur untuk bermigrasi sebelum fitur ini dihapus dari browser.

Apa yang dihapus?

Ada dua API di browser yang mengimplementasikan XSLT, dan keduanya akan dihapus:

Class XSLTProcessor (misalnya, new XSLTProcessor()).
Petunjuk Pemrosesan XSLT (misalnya, <?xml-stylesheet … ?>).

Linimasa Untuk Chrome

Chrome memiliki paket berikut:

Chrome 142 (28 Oktober 2025): Pesan konsol peringatan awal ditambahkan ke Chrome.
Chrome 143 (2 Desember 2025): Penghentian penggunaan resmi API - pesan peringatan penghentian penggunaan mulai ditampilkan di konsol dan di lighthouse.
Chrome 148 (10 Maret 2026 Canary): Rilis Canary, Dev, dan Beta mulai menonaktifkan XSLT secara default, sebagai peringatan awal.
Chrome 152 (25 Agustus 2026): Uji Coba Origin (OT) dan Kebijakan Perusahaan (EP) ditayangkan untuk pengujian. Hal ini memungkinkan situs dan perusahaan terus menggunakan fitur setelah tanggal penghapusan.
Chrome 155 (17 Nov 2026): XSLT berhenti berfungsi di rilis Stabil, untuk semua pengguna selain peserta Uji Coba Origin dan Kebijakan Enterprise.**
Chrome 164 (17 Agustus 2027): Uji Coba Origin dan Kebijakan Enterprise berhenti berfungsi. XSLT dinonaktifkan untuk semua pengguna.**

Apa itu XSLT?

XSLT, atau Extensible Stylesheet Language Transformations, adalah bahasa yang digunakan untuk mentransformasi dokumen XML, biasanya ke format lain seperti HTML. Alat ini menggunakan file stylesheet XSLT untuk menentukan aturan konversi ini, dan file XML yang berisi data yang digunakan sebagai input.

Di browser, saat file XML yang ditautkan ke stylesheet XSLT diterima, browser akan menggunakan aturan dalam stylesheet tersebut untuk mengatur ulang, memformat, dan mengonversi data XML mentah menjadi halaman terstruktur (sering kali HTML) yang dapat dirender untuk pengguna.

Misalnya, stylesheet XSLT dapat mengambil input XML berikut:

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl" ?>
<page>
 <message>
  Hello World.
 </message>
</page>

dan stylesheet XSL ini:

<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>

dan memprosesnya ke dalam HTML ini agar ditampilkan oleh browser: HTML

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

Selain petunjuk pemrosesan XSL yang ditampilkan dalam contoh sebelumnya, ada juga XSLTProcessor JavaScript API yang dapat digunakan untuk memproses dokumen XML lokal dengan stylesheet XSLT lokal.

Sejarah XSLT

XSLT direkomendasikan oleh World Wide Web Consortium (W3C) pada 16 November 1999, sebagai bahasa untuk mengubah dokumen XML ke format lain, yang paling umum adalah HTML untuk ditampilkan di browser web. Sebelum rekomendasi resmi 1.0, Microsoft mengambil inisiatif awal dengan mengirimkan implementasi eksklusif berdasarkan draf kerja W3C di Internet Explorer 5.0, yang dirilis pada Maret 1999. Mengikuti standar resmi, Mozilla menerapkan dukungan XSLT 1.0 asli di Netscape 6 pada akhir tahun 2000. Browser utama lainnya, termasuk Safari, Opera, dan Chrome versi yang lebih baru, juga menyertakan pemroses XSLT 1.0 bawaan, sehingga transformasi XML ke HTML di sisi klien menjadi teknologi web yang layak pada awal tahun 2000-an.

Bahasa XSLT itu sendiri terus berkembang, dengan rilis XSLT 2.0 pada tahun 2007 dan XSLT 3.0 pada tahun 2017, yang memperkenalkan fitur canggih seperti ekspresi reguler, jenis data yang ditingkatkan, dan kemampuan untuk memproses JSON. Namun, dukungan browser tidak berkembang. Saat ini, semua mesin browser web utama hanya memberikan dukungan native untuk XSLT 1.0 asli dari tahun 1999. Kurangnya kemajuan ini, ditambah dengan meningkatnya penggunaan JSON sebagai format wire, serta library dan framework JavaScript (seperti jQuery, React, dan Vue.js) yang menawarkan manipulasi dan pembuatan template DOM yang lebih fleksibel dan canggih, telah menyebabkan penurunan signifikan dalam penggunaan XSLT sisi klien. Perannya dalam browser web sebagian besar telah digantikan oleh teknologi berbasis JavaScript ini.

Mengapa XSLT perlu dihapus?

Terus menyertakan XSLT 1.0 di browser web menimbulkan risiko keamanan yang signifikan dan tidak perlu. Library dasar yang memproses transformasi ini, seperti libxslt (yang digunakan oleh browser Chromium), adalah codebase C/C++ yang kompleks dan sudah lama. Jenis kode ini sangat rentan terhadap kerentanan keamanan memori seperti luapan buffer, yang dapat menyebabkan eksekusi kode arbitrer. Misalnya, audit keamanan dan pelacak bug telah berulang kali mengidentifikasi kerentanan tingkat tinggi dalam parser ini (misalnya, CVE-2025-7425 dan CVE-2022-22834, keduanya ada di libxslt). Karena XSLT sisi klien kini menjadi fitur yang jarang digunakan, library ini menerima pemeliharaan dan pemeriksaan keamanan yang jauh lebih sedikit daripada mesin JavaScript inti, tetapi library ini merupakan permukaan serangan langsung yang kuat untuk memproses konten web yang tidak tepercaya. Memang, XSLT adalah sumber dari beberapa eksploitasi keamanan tingkat tinggi baru-baru ini yang terus membahayakan pengguna browser. Risiko keamanan dalam mempertahankan fungsi lama yang rapuh ini jauh lebih besar daripada kegunaannya yang terbatas di era modern.

Selain itu, tujuan awal XSLT sisi klien—mengubah data menjadi HTML yang dapat dirender—telah digantikan oleh API JavaScript yang lebih aman, lebih ergonomis, dan lebih terpelihara. Pengembangan web modern mengandalkan hal-hal seperti Fetch API untuk mengambil data (biasanya JSON) dan DOMParser API untuk mengurai string XML atau HTML dengan aman ke dalam struktur DOM dalam sandbox JavaScript yang aman di browser. Framework seperti React, Vue, dan Svelte kemudian mengelola rendering data ini secara efisien dan aman. Toolchain modern ini dikembangkan secara aktif, mendapat manfaat dari investasi keamanan besar-besaran dalam mesin JavaScript, dan digunakan oleh hampir semua developer web saat ini. Memang, hanya sekitar 0,02% pemuatan halaman web saat ini yang benar-benar menggunakan XSLT, dengan kurang dari 0,001% yang menggunakan petunjuk pemrosesan XSLT.

Tindakan ini bukan hanya untuk Chrome atau Chromium: dua mesin browser utama lainnya juga mendukung penghapusan XSLT dari platform web: WebKit, Gecko.

Karena alasan ini, penghentian penggunaan dan penghapusan XSLT mengurangi permukaan serangan browser untuk semua pengguna, menyederhanakan platform web, dan memungkinkan sumber daya teknik difokuskan untuk mengamankan teknologi yang benar-benar mendukung web modern, tanpa kehilangan kemampuan praktis bagi developer.

Meningkatkan keamanan penguraian XML

Mirip dengan masalah keamanan parah di libxslt, masalah keamanan parah baru-baru ini dilaporkan terhadap libxml2 yang digunakan di Chromium untuk mengurai, membuat serial, dan menguji kebenaran XML. Untuk mengatasi masalah keamanan terkait penguraian XML di masa mendatang, kami berencana untuk menghentikan penggunaan libxml2 di Chromium dan mengganti penguraian XML dengan library penguraian XML yang aman untuk memori dan ditulis dalam Rust. Yang penting, kami tidak akan menghapus XML dari browser; hanya XSLT yang dipertimbangkan untuk dihapus di sini. Kami bermaksud memastikan bahwa penggantian libxml2 sepenuhnya transparan bagi developer web.

Cara melakukan migrasi

Ada beberapa jalur alternatif untuk migrasi.

JSON

Untuk situs yang sepenuhnya dibangun di XML dan XSL, tidak ada cara yang cocok untuk semua orang dalam melakukan transisi. Opsi migrasi mencakup memindahkan pipeline pemrosesan XSLT ke sisi server dan mengirimkan HTML yang dirender ke klien, atau memigrasikan endpoint XML API sisi server ke JSON, dan melakukan rendering sisi klien menggunakan JavaScript untuk mengubah JSON menjadi HTML DOM dan CSS.

XSLT sisi klien di JavaScript

Ada beberapa library XSLT sisi klien (berbasis JavaScript) yang tersedia, tetapi yang terbesar sejauh ini dibuat oleh Saxonica (lihat dokumentasi komprehensif untuk Saxonica). Implementasi ini jauh melampaui implementasi XSLT 1.0 di browser web, dengan mengimplementasikan dukungan penuh untuk standar v3.0 terbaru, dan pada akhirnya standar v4.0 yang masih dalam proses.

Polyfill

Ada polyfill yang berupaya mengizinkan kode yang ada, yang bergantung pada implementasi XSLT 1.0 di browser web, untuk terus berfungsi, tanpa menggunakan fitur XSLT native dari browser. Polyfill berada di GitHub.

Polyfill ini berisi pengganti fungsional berbasis WASM yang di-polyfill untuk class XSLTProcessor, sehingga kode JavaScript yang ada dapat terus berfungsi sebagaimana adanya:

<script src="xslt-polyfill.min.js"></script>

<script>
const xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsltDoc);
const fragment = xsltProcessor.transformToFragment(xmlDoc, document);
</script>

Polyfill juga menyediakan fungsi utilitas otomatis untuk cara mudah mengganti dokumen XML yang menggunakan petunjuk pemrosesan XSLT:

Untuk file demo.xml asli seperti ini:

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
...content...

Satu baris dapat ditambahkan untuk memanggil polyfill dan mengubah dokumen dengan stylesheet XSLT yang dirujuk:

<?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...

Dalam hal ini, elemen <script> baru memuat polyfill, yang mendeteksi jenis dokumen XML dan petunjuk pemrosesan XSLT, lalu memuatnya secara transparan dengan menggantikan dokumen.

Perluasan

Ada juga ekstensi Chrome yang dapat ditambahkan ke browser yang didukung, yang akan menerapkan polyfill XSLT yang sama ke semua halaman XML mentah yang berisi petunjuk pemrosesan XSLT atau panggilan ke XSLTProcessor. Hal ini dapat digunakan untuk aplikasi yang XML atau XSLT sumbernya tidak dapat diubah, untuk mempertahankan fungsi.

Khususnya, saat XSLT dinonaktifkan, Chrome kini menampilkan banner peringatan yang menautkan langsung ke halaman penelusuran ekstensi, untuk membantu pengguna menemukan ekstensi:

Pesan yang ditampilkan di Chrome saat xslt terdeteksi.

Kasus penggunaan tertentu

Dalam diskusi tentang standar HTML, beberapa kasus penggunaan konkret telah diidentifikasi. Bagian ini secara khusus membahas masing-masing opsi tersebut, untuk merekomendasikan jalur ke depan bagi developer yang memublikasikan resource XML yang menggunakan XSLT saat ini.

Feed RSS dan Atom

Di banyak feed RSS atau Atom yang ada, XSLT digunakan untuk membuat feed XML mentah dapat dibaca oleh manusia saat dilihat langsung di browser. Kasus penggunaan utamanya adalah bahwa saat pengguna tidak sengaja mengklik link feed RSS situs, daripada menempelkan link tersebut ke pembaca RSS, mereka akan mendapatkan respons HTML yang diformat yang dapat mereka baca, bukan XML mentah itu sendiri.

Ada dua jalur untuk kasus penggunaan ini. Cara HTML "standar" untuk melakukannya adalah dengan menambahkan <link rel="alternate" type="application/rss+xml"> ke situs (berbasis HTML), bukan menambahkan <a href="something.xml"> eksplisit (yang terlihat pengguna) yang mungkin tidak sengaja diklik pengguna. Solusi ini memungkinkan pembaca RSS menemukan feed jika pengguna menempelkan hanya URL situs, tetapi juga memungkinkan pengguna manusia melihat konten HTML biasa tanpa bingung dengan link ke resource XML. Hal ini juga mengikuti paradigma web normal bahwa HTML adalah untuk manusia dan XML adalah untuk mesin. Tentu saja, hal ini tidak menyelesaikan kasus ketika pengguna "memiliki" link RSS dari suatu tempat, dan mereka menempelkannya ke browser web (bukan pembaca RSS).

Jika solusi tersebut tidak diinginkan, polyfill menawarkan jalur lain. Seperti yang disebutkan sebelumnya, feed XML RSS/Atom dapat ditambah dengan satu baris, <script src="xslt-polyfill.min.js" xmlns="[http://www.w3.org/1999/xhtml](http://www.w3.org/1999/xhtml)"></script>, yang akan mempertahankan perilaku transformasi berbasis XSLT ke HTML yang ada. Hal ini tidak akan memengaruhi kemampuan pembaca RSS untuk terus mem-parsing XML, karena <script> adalah turunan langsung dari elemen root.

Output API untuk perangkat sematan

Beberapa perangkat komersial tersemat mengukur atau membuat data XML untuk penggunaan oleh pengguna di jaringan lokal. Beberapa perangkat ini melakukannya dengan membuat feed data XML tunggal yang menggunakan XSLT untuk mengubahnya menjadi format HTML yang mudah dibaca. Hal ini memungkinkan API dilihat langsung di browser tanpa memerlukan kode tambahan di perangkat atau di browser.
Karena ini adalah kasus penggunaan yang sangat spesifik untuk aplikasi, bentuk solusinya dapat bervariasi. Untuk aplikasi yang kode sumber perangkat sematan dapat diperbarui, opsi apa pun yang dijelaskan sebelumnya (JSON, Polyfill) dapat berfungsi. Namun, khususnya, banyak perangkat tersebut sulit atau tidak mungkin diupdate karena berbagai alasan. Dalam hal ini, ekstensi mungkin merupakan opsi terbaik, karena memungkinkan browser klien terus membaca data dengan cara yang sama persis, tanpa mengubah perangkat.

Templating lambat untuk situs web

Developer web terkadang menggunakan XSLT di sisi klien untuk menerapkan markup presentasi ke markup semantik, yang berfungsi sebagai bahasa pembuatan template lambat yang terpisah dari ekosistem JavaScript.

Ada dua solusi untuk masalah yang lebih umum ini. Untuk situs yang sudah ada dan dibuat dengan cara ini, solusi termudah kemungkinan hanya menambahkan polyfill untuk mempertahankan fungsi yang ada. Atau mungkin melakukan transformasi XSLT di sisi server, dan menayangkan HTML yang dihasilkan ke klien, bukan XML mentah. Solusi jangka panjang untuk properti tersebut adalah bermigrasi ke framework berbasis JavaScript atau JSON yang lebih modern.