Google menggunakan teknologi AI untuk menerjemahkan konten ke dalam bahasa pilihan Anda. Terjemahan AI mungkin mengandung kesalahan.

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 resmi menghentikan penggunaan XSLT, termasuk XSLTProcessor JavaScript API dan petunjuk pemrosesan XSLT. Kami bermaksud menghapus dukungan dari 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 menyediakan 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:

Class XSLTProcessor (misalnya, new XSLTProcessor()).
Petunjuk Pemrosesan XSLT Instruksi (misalnya, <?xml-stylesheet type="text/xsl" ... ?>).

Linimasa Untuk Chrome

Chrome memiliki rencana berikut:

Chrome 142 (28 Oktober 2025): Pesan konsol peringatan awal ditambahkan ke Chrome.
Chrome 143 (2 Desember 2025): Penghentian penggunaan API secara resmi - pesan peringatan penghentian penggunaan mulai ditampilkan di konsol dan di Lighthouse.
Chrome 145 (2 Desember 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. Hal ini memungkinkan perusahaan menguji penonaktifan XSLT lebih awal, dan juga memungkinkan mereka terus menggunakan fitur setelah tanggal penghapusan.
Chrome 152 (25 Agustus 2026): Uji Coba Origin (OT) diluncurkan untuk pengujian. Hal ini memungkinkan situs terus menggunakan fitur setelah tanggal penghapusan.
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. Bahasa 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 menggunakan 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 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. Setelah standar resmi, Mozilla mengimplementasikan dukungan XSLT 1.0 native di Netscape 6 pada akhir tahun 2000. Browser utama lainnya, termasuk Safari, Opera, dan Chrome versi yang lebih baru, juga menggabungkan prosesor XSLT 1.0 native, sehingga transformasi XML ke HTML sisi klien menjadi teknologi web yang layak pada awal tahun 2000-an.

Bahasa XSLT itu sendiri terus berkembang, dengan dirilisnya XSLT 2.0 pada 2007 dan XSLT 3.0 pada 2017, yang memperkenalkan fitur canggih seperti ekspresi reguler, jenis data yang ditingkatkan, dan kemampuan untuk memproses JSON. Namun, dukungan browser stagnan. Saat ini, semua mesin browser web utama hanya menyediakan 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?

Pencantuman XSLT 1.0 yang berkelanjutan di browser web menghadirkan 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 buffer overflow, yang dapat menyebabkan eksekusi kode arbitrer. Misalnya, audit keamanan dan pelacak bug telah berulang kali mengidentifikasi kerentanan tingkat tinggi di pengurai 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 untuk mempertahankan fungsi lama yang rapuh ini jauh lebih besar daripada utilitas modernnya yang terbatas.

Selain itu, tujuan awal XSLT sisi klien—mengubah data menjadi HTML yang dapat dirender—telah digantikan oleh JavaScript API yang lebih aman, lebih ergonomis, dan lebih terpelihara. Pengembangan web modern bergantung pada 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 besar-besaran di mesin JavaScript, dan merupakan hal yang 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% 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 yang parah di libxslt, masalah keamanan yang parah baru-baru ini dilaporkan terhadap libxml2 yang digunakan di Chromium untuk mengurai, serialisasi, dan menguji format XML yang benar. Untuk mengatasi masalah keamanan penguraian XML di Chromium pada masa mendatang, kami berencana untuk menghentikan penggunaan libxml2 dan mengganti penguraian XML dengan library penguraian XML yang aman untuk memori yang ditulis di 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.

XML + CSS tidak akan dihapus

Penting untuk membedakan penghentian penggunaan XSLT (<?xml-stylesheet type="text/xsl" ... ?>) dari <?xml-stylesheet ... ?> petunjuk pemrosesan 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 Anda, 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 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 diproduksi oleh Saxonica (lihat dokumentasi komprehensif untuk Saxonica). Implementasinya jauh melampaui implementasi XSLT 1.0 di browser web, menerapkan dukungan penuh untuk standar v3.0 terbaru, dan pada akhirnya standar v4.0 yang sedang berlangsung.

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 di GitHub.

Polyfill berisi pengganti polyfill berbasis WASM yang berfungsi 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 memuat polyfill, yang mendeteksi jenis dokumen XML dan petunjuk pemrosesan XSLT serta memuatnya secara transparan, mengganti dokumen.

Ekstensi

Ada juga ekstensi Chromeyang 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 tidak dapat mengubah XML atau XSLT sumber, 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 di standar HTML, beberapa kasus penggunaan konkret telah diidentifikasi. Bagian ini membahas secara khusus setiap kasus penggunaan 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 saat pengguna tidak sengaja mengklik link feed RSS situs, bukan menempelkan link tersebut ke pembaca RSS mereka, mereka akan mendapatkan respons HTML yang diformat yang dapat mereka baca, bukan XML mentah itu sendiri.

Ada dua jalur ke depan untuk kasus penggunaan ini. Cara HTML "standar" untuk melakukan ini adalah dengan menambahkan <link rel="alternate" type="application/rss+xml"> ke situs (berbasis HTML), bukan menambahkan <a href="something.xml"> eksplisit (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 adalah untuk manusia dan XML adalah untuk mesin. Tentu saja hal ini tidak menyelesaikan kasus ketika pengguna hanya "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"></script>, yang akan mempertahankan perilaku transformasi berbasis XSLT yang ada ke HTML. Hal tersebut 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 membuat 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 oleh 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 berbeda-beda. Untuk aplikasi yang kode sumber perangkat sematannya dapat diupdate, salah satu opsi yang dijelaskan sebelumnya (JSON, Polyfill) dapat berfungsi. Namun, khususnya, banyak perangkat semacam itu sulit atau tidak mungkin diupdate, karena berbagai alasan. Dalam hal ini, ekstensi kemungkinan adalah opsi terbaik, karena memungkinkan browser klien terus membaca data dengan cara yang sama persis, tanpa mengubah perangkat.

Pembuatan template 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 ada yang 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.

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 dalam codebase Anda dengan beberapa cara. Bagian ini menguraikan dua di antaranya.

Reporting API

Reporting API adalah mekanisme pelaporan generik untuk aplikasi web yang digunakan untuk melaporkan berbagai fitur dan kondisi platform, termasuk penghentian penggunaan fitur. Untuk menyiapkan pelaporan 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 kode ini dalam tindakan di CodePen.

Laporan Teknologi Lama perusahaan

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