Menghapus XSLT untuk browser yang lebih aman

Mason Freed
Mason Freed
Dominik Röttsches
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 resmi menghentikan penggunaan XSLT, termasuk XSLTProcessor JavaScript API dan petunjuk pemrosesan XSLT. Kami akan menghapus dukungan mulai versi 158 (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. Untuk mengetahui update terbaru, lihat juga entri Status Platform Chrome.

Apa yang akan dihapus?

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

Linimasa untuk Chrome

Chrome memiliki rencana berikut:

  • Chrome 142 (28 Okt 2025): Pesan konsol peringatan awal ditambahkan ke Chrome.
  • Chrome 143 (2 Des 2025): Penghentian resmi API - pesan peringatan penghentian penggunaan mulai ditampilkan di konsol dan di Lighthouse.
  • Chrome 145 (2 Des 2025 Canary): Rilis Canary, Dev, dan Beta mulai menonaktifkan XSLT secara default, sebagai peringatan awal.
  • Chrome 146 (10 Maret 2026): Kebijakan Enterprise (EP) diluncurkan untuk pengujian. Dengan demikian, perusahaan dapat menguji penonaktifan XSLT lebih awal, dan juga dapat terus menggunakan fitur setelah tanggal penghapusan.
  • Chrome 152 (25 Agustus 2026): Uji Coba Origin (OT) diluncurkan untuk pengujian. Dengan demikian, situs dapat terus menggunakan fitur setelah tanggal penghapusan.
  • Chrome 154 (22 September 2026): Rilis Canary, Dev, dan Beta Webview mulai menonaktifkan XSLT secara default, sebagai peringatan awal.
  • Chrome 158 (17 November 2026): XSLT berhenti berfungsi pada rilis Stabil, untuk semua pengguna selain peserta Uji Coba Origin dan Kebijakan Enterprise.
  • Chrome 176 (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 mengubah dokumen XML, biasanya menjadi 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 tertaut 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 menjadi HTML ini untuk ditampilkan 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.

Histori XSLT

XSLT direkomendasikan oleh World Wide Web Consortium (W3C) pada 16 November 1999, sebagai bahasa untuk mengubah dokumen XML menjadi format lain, yang paling umum adalah HTML untuk ditampilkan di browser web. Sebelum rekomendasi 1.0 resmi, 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 native di Netscape 6 pada akhir tahun 2000. Browser utama lainnya, termasuk Safari, Opera, dan Chrome versi lebih baru, juga menggabungkan pemroses XSLT 1.0 native, sehingga transformasi XML ke HTML sisi klien menjadi teknologi web yang layak pada awal tahun 2000-an.

Bahasa XSLT sendiri terus berkembang, dengan dirilisnya 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 mengalami stagnasi. 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 kabel, 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?

Penyertaan XSLT 1.0 yang berkelanjutan di browser web menimbulkan risiko keamanan yang signifikan dan tidak perlu. Library dasar yang memproses transformasi ini, seperti libxslt (digunakan oleh browser Chromium), adalah codebase C/C++ yang sudah lama dan kompleks. Jenis kode ini terkenal rentan terhadap kerentanan keamanan memori seperti buffer overflow, 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 di libxslt). Karena XSLT sisi klien kini menjadi fitur khusus 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 dari mempertahankan fungsi lama yang rentan ini jauh lebih besar daripada kegunaan modernnya yang terbatas.

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, mendapatkan manfaat dari investasi keamanan yang besar dalam mesin JavaScript, dan digunakan oleh hampir semua developer web saat ini. Faktanya, saat ini hanya sekitar 0,02% pemuatan halaman web yang benar-benar menggunakan XSLT, dengan kurang dari 0,001% yang menggunakan petunjuk pemrosesan XSLT.

Tindakan ini tidak hanya berlaku 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 resource engineering difokuskan untuk mengamankan teknologi yang benar-benar mendukung web modern, tanpa kehilangan kemampuan praktis bagi developer.

Meningkatkan keamanan penguraian XML

Mirip dengan masalah keamanan serius di libxslt, masalah keamanan serius baru-baru ini dilaporkan terhadap libxml2 yang digunakan di Chromium untuk penguraian, serialisasi, dan pengujian format XML yang baik. Untuk mengatasi masalah keamanan di masa mendatang terkait penguraian XML di Chromium, kami berencana untuk menghentikan penggunaan libxml2 secara bertahap dan mengganti penguraian XML dengan library penguraian XML yang aman untuk memori yang ditulis dalam Rust. Yang penting, kami tidak akan menghapus XML dari browser; hanya XSLT yang dipertimbangkan untuk dihapus di sini. Kami ingin memastikan bahwa penggantian libxml2 sepenuhnya transparan bagi developer web.

XML + CSS tidak dihapus

Penting untuk membedakan penghentian penggunaan XSLT (<?xml-stylesheet type="text/xsl" ... ?>) dari petunjuk pemrosesan <?xml-stylesheet ... ?> itu sendiri, yang tetap didukung saat digunakan dengan CSS. Anda masih dapat menggunakan petunjuk pemrosesan dengan type="text/css" untuk menerapkan aturan tata letak dan desain standar ke data mentah, seperti yang dapat Anda lakukan dengan HTML. Contoh:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="styles.css"?>
<root>
  <item>Content here</item>
</root>

Cara melakukan migrasi

Ada beberapa jalur alternatif untuk migrasi.

JSON

Untuk situs yang sepenuhnya dibuat di XML dan XSL, tidak ada cara yang cocok untuk semua dalam melakukan transisi. Opsi migrasi mencakup pemindahan 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 DOM HTML dan CSS.

XSLT sisi klien di JavaScript

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

Polyfill

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

Polyfill berisi pengganti polyfill berbasis WASM fungsional 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 direferensikan:

<?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 akan memuat polyfill, yang mendeteksi jenis dokumen XML dan petunjuk pemrosesan XSLT, lalu memuatnya secara transparan, menggantikan dokumen.

Ekstensi

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, guna mempertahankan fungsionalitas.

Secara khusus, 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 membahas secara khusus 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 manusia saat dilihat langsung di browser. Kasus penggunaan utamanya adalah saat pengguna tidak sengaja mengklik link feed RSS situs, alih-alih menempelkan link tersebut ke pembaca RSS, mereka akan mendapatkan respons HTML berformat yang dapat mereka baca, bukan XML mentah itu sendiri.

Ada dua jalur ke depan 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 oleh pengguna) yang mungkin tidak sengaja diklik pengguna. Solusi ini memungkinkan pembaca RSS menemukan feed jika pengguna hanya menempelkan URL situs, tetapi juga memungkinkan pengguna manusia melihat konten HTML reguler tanpa bingung dengan link ke resource XML. Hal ini juga mengikuti paradigma web normal bahwa HTML ditujukan untuk manusia dan XML ditujukan untuk mesin. Tentu saja, hal ini tidak menyelesaikan kasus saat pengguna hanya "memiliki" link RSS dari suatu tempat, dan 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"></script>, yang akan mempertahankan perilaku transformasi berbasis XSLT yang ada ke HTML. Hal ini tidak akan memengaruhi kemampuan pembaca RSS untuk terus mengurai XML, karena <script> adalah turunan langsung dari elemen root.

Output API untuk perangkat sematan

Beberapa perangkat sematan komersial mengukur atau menghasilkan data XML untuk digunakan oleh pengguna di jaringan lokal. Beberapa perangkat ini melakukannya dengan membuat satu feed data XML yang menggunakan XSLT untuk mengubahnya menjadi format HTML yang dapat dibaca manusia. 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 mungkin bervariasi. Untuk aplikasi yang kode sumber perangkat tersematnya dapat diperbarui, salah satu opsi yang dijelaskan sebelumnya (JSON, Polyfill) dapat berfungsi. Namun, khususnya, banyak perangkat semacam itu yang sulit atau tidak mungkin diupdate, karena berbagai alasan. Dalam hal ini, ekstensi kemungkinan merupakan opsi terbaik, karena memungkinkan browser klien untuk terus membaca data dengan cara yang sama persis, tanpa mengubah perangkat.

Pembuatan template lambat untuk situs

Developer web terkadang menggunakan XSLT di sisi klien untuk menerapkan markup presentasi ke markup semantik, yang berfungsi sebagai bahasa 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 mungkin adalah menambahkan polyfill untuk mempertahankan fungsi yang ada. Atau, mungkin lakukan transformasi XSLT di sisi server, dan tayangkan 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.

Jika Anda mengalami masalah tertentu di Chrome terkait penghentian penggunaan XSLT ini, laporkan bug di sini.

Cara mendeteksi penggunaan XSLT

Secara umum, fitur yang tidak digunakan lagi seperti XSLT dapat dideteksi di codebase Anda dengan beberapa cara. Bagian ini menguraikan dua di antaranya.

Reporting API

Reporting API adalah mekanisme pelaporan umum untuk aplikasi web yang digunakan untuk melaporkan berbagai fitur dan kondisi platform, termasuk penghentian penggunaan fitur. Untuk menyiapkannya agar melaporkan penghentian penggunaan XSLT, cuplikan kode seperti ini dapat digunakan:

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();

Lihat cara kerja kode ini di CodePen.

Laporan Teknologi Lama perusahaan

Bagi admin perusahaan, Laporan Teknologi Lama dapat digunakan untuk mengumpulkan penggunaan fitur yang tidak digunakan lagi secara otomatis dan melaporkannya kembali dengan cara yang mudah digunakan. Lihat artikel Dukungan Google ini untuk mengetahui informasi selengkapnya tentang cara mengaktifkan fitur ini.