XSS melalui innerHTML dan Cara Mencegahnya

Menetapkan el.innerHTML = userInput akan mengurai teks tersebut sebagai HTML. Jika userInput berisi tag <script> atau atribut penangan peristiwa (onclick, onerror), peramban akan menafsirkannya dan menjalankan kode yang dikendalikan penyerang pada halaman.

Setiap kode yang menyisipkan data pengguna ke dalam HTML—templat peladen atau penyusunan tampilan di sisi klien—berisiko menimbulkan XSS jika data tersebut tidak di-escape. Aplikasi satu halaman yang membangun innerHTML dari respons API sangat rentan, terutama ketika respons tersebut berisi konten pengguna.

Nama pengguna "Bob<img src=x onerror=alert(1)>" yang ditetapkan melalui div.innerHTML = `Welcome, ${user}` akan menjalankan alert(1) ketika img gagal dimuat. Muatan yang sama sebagai teks biasa (melalui textContent) tidak berbahaya—peramban hanya melihat karakter, bukan tag.

textContent hanya menetapkan teks—karakter khusus HTML muncul sebagai karakter literal, bukan sebagai tag. Inilah alat yang tepat dalam 90% kasus. Beralihlah ke innerHTML hanya jika Anda benar-benar perlu menampilkan markup, bukan teks.

Untuk membuat elemen dengan data pengguna, buat elemen tersebut menggunakan createElement dan textContent: const li = document.createElement("li"); li.textContent = name; ul.appendChild(li);. Hasilnya identik secara struktur dengan innerHTML, tetapi aman dari XSS sejak awal.

Untuk HTML tepercaya yang dibuat oleh peladen (keluaran templat Anda sendiri atau teks kaya yang telah disanitasi dari editor tepercaya), innerHTML aman digunakan. Jangan pernah menerapkannya secara langsung pada data dari sumber yang tidak tepercaya tanpa sanitasi.

Jika pengguna mengirimkan teks kaya (editor komentar atau tampilan markdown), lakukan sanitasi sebelum menetapkan innerHTML: el.innerHTML = DOMPurify.sanitize(richHtml). DOMPurify menghapus tag dan atribut berbahaya sambil mempertahankan pemformatan yang aman seperti <b>, <em>, dan <a>.

el.insertAdjacentHTML("beforeend", html) mengurai teks HTML—permukaan XSS-nya sama seperti innerHTML. Aturannya juga sama: jangan pernah memasukkan data pengguna secara langsung; lakukan sanitasi atau gunakan metode DOM. Hal yang sama berlaku untuk document.write, meskipun seharusnya tidak ada yang menggunakannya lagi.

React, Vue, Svelte, dan Angular secara bawaan melakukan escape pada teks yang disisipkan—{name} aman. Semuanya menyediakan celah untuk melewati pengamanan (dangerouslySetInnerHTML di React dan v-html di Vue) yang memiliki risiko XSS yang sama; gunakan secara hemat dan sertai sanitasi.

Bahkan nilai atribut dapat menjadi vektor serangan: <a href={url}> dengan url="javascript:alert(1)" akan menjalankan kode ketika diklik. Validasi URL berdasarkan skemanya (izinkan hanya http:, https:, mailto:, dan tel:) sebelum menempatkan masukan pengguna dalam href, src, atau atribut lain yang berisi URL.

Peramban modern mendukung Trusted Types: konfigurasikan CSP dengan require-trusted-types-for 'script', lalu innerHTML akan menolak teks mentah—hanya nilai yang dibungkus oleh kebijakan yang diterima. Cara ini membuat XSS mustahil melalui API, bukan dengan mengandalkan kedisiplinan.

Tidak ada satu lapisan pun yang cukup. Gabungkan validasi masukan di server, pelolosan keluaran saat rendering, CSP untuk memblokir skrip yang disisipkan, Trusted Types untuk menolak string mentah, serta peninjauan keamanan untuk setiap penggunaan innerHTML. Pertahanan berlapis tetap bertahan meskipun terdapat bug di salah satu lapisan.

innerHTML pada masukan pengguna merupakan vektor XSS klasik. Gunakan textContent untuk teks, createElement+textContent untuk struktur, dan DOMPurify jika HTML kaya diperlukan. Validasi skema URL untuk nilai atribut. Lapisi CSP dan Trusted Types untuk menetralkan bug yang lolos dari peninjauan kode. Kerangka kerja modern melakukan escaping secara bawaan — gunakan celah untuk menonaktifkan perlindungan tersebut sesedikit mungkin dan tinjau setiap penggunaannya.