Cross-Site Scripting (XSS): Pengertian, Jenis, dan Cara Mencegahnya

XSS atau cross-site scripting adalah celah keamanan yang membuat sebuah situs menampilkan skrip buatan pihak lain seolah-olah skrip itu bagian dari situs tersebut. Skrip itu kemudian berjalan di browser pengunjung dengan hak yang sama seperti kode resmi situs. Berikut pengertian, jenis, dan langkah pencegahan XSS yang dapat langsung diterapkan oleh pengembang maupun pemilik situs.

Apa Itu XSS dan Mengapa Berbahaya?

Menurut dokumentasi MDN, semua serangan XSS membutuhkan dua syarat: situs menerima masukan yang bisa dibuat oleh penyerang, dan situs memasukkan masukan itu ke dalam halaman tanpa pengolahan yang benar sehingga dapat berjalan sebagai JavaScript. Karena skrip berjalan dengan hak istimewa yang sama dengan kode situs, ia dapat melewati same-origin policy browser.

Dampaknya mencakup pencurian token atau cookie sesi yang berujung pengambilalihan akun, pembacaan dan pengubahan isi halaman, pengiriman permintaan atas nama pengguna, pengalihan ke situs lain, serta pemasangan formulir palsu di dalam halaman asli. Situs yang hanya menampilkan konten pun bisa terdampak. Pada OWASP Top 10 edisi 2025, XSS dikelompokkan dalam kategori Injection (A05:2025), yang menurut OWASP memuat lebih dari 30 ribu CVE bertipe XSS. Konteks daftar itu dibahas di artikel tentang OWASP Top 10.

Sebagai gambaran konseptual, bayangkan sebuah forum yang menampilkan komentar anggota apa adanya. Jika satu komentar berisi skrip dan forum tidak meng-encode-nya, setiap anggota atau moderator yang membuka utas itu menjalankan skrip tersebut dengan sesi login miliknya sendiri. Di sinilah XSS menjadi jalan pintas untuk menguasai akun berhak akses tinggi tanpa perlu menebak kata sandi.

Jenis-Jenis XSS

Reflected XSS

Masukan pengguna, misalnya parameter pencarian di URL, langsung dipantulkan ke dalam respons halaman tanpa disimpan. Korban perlu diperdaya agar membuka tautan khusus. Karena itu serangan ini sering dikaitkan dengan phishing dan pesan berantai.

Stored XSS

Masukan berbahaya tersimpan di server, misalnya di kolom komentar, profil, atau pesan forum, dan dijalankan oleh setiap orang yang membuka konten tersebut. MDN menyebut jenis ini sangat serius karena korbannya tidak perlu mengklik tautan apa pun. Varian blind XSS terjadi ketika masukan baru tampil di tampilan internal, misalnya panel admin, sehingga penyerang tidak melihat hasilnya secara langsung.

DOM-based XSS

Masalahnya terjadi di sisi browser: skrip halaman sendiri mengambil data dari sumber yang bisa dikendalikan pihak lain, seperti bagian URL, lalu menuliskannya ke halaman lewat fungsi berisiko seperti innerHTML atau document.write. Server mungkin tidak pernah melihat muatannya, sehingga filter di sisi server tidak membantu.

Cara Mendeteksi Celah XSS

Pendeteksian dilakukan lewat tiga jalur yang saling melengkapi. Pertama, tinjauan kode: cari tempat input pengguna masuk ke keluaran HTML, atribut, JavaScript, atau URL tanpa encoding, dan cari pemakaian sink berisiko seperti innerHTML. Kedua, pengujian keamanan aplikasi web oleh tim yang berwenang, baik berupa pemindaian otomatis maupun uji manual dalam kerangka penetration testing. Ketiga, pemantauan produksi lewat laporan pelanggaran CSP, log WAF, dan keluhan pengguna tentang tampilan atau pop-up yang aneh.

Menguji XSS pada situs yang bukan milik Anda dan tanpa izin tertulis dapat dikenai Pasal 332 KUHP tentang akses ilegal. Gunakan lab sendiri atau program yang memang mengizinkan pengujian.

Cara Mencegah XSS

OWASP XSS Prevention Cheat Sheet dan MDN sama-sama menekankan bahwa pertahanan utama adalah memperlakukan semua data tidak tepercaya sebagai data, bukan sebagai kode.

1. Encode keluaran sesuai konteks. Nilai yang dicetak di isi HTML, atribut, JavaScript, CSS, dan URL masing-masing memerlukan encoding yang berbeda. Selalu beri tanda kutip pada nilai atribut.
2. Andalkan auto-escaping framework. Mesin templat modern dan JSX meng-encode keluaran secara bawaan. Hati-hati dengan fitur yang sengaja menonaktifkannya, misalnya penyisipan HTML mentah.
3. Pilih sink yang aman. Gunakan textContent alih-alih innerHTML bila Anda hanya menampilkan teks.
4. Sanitasi HTML dari pengguna. Jika memang harus menampilkan HTML buatan pengguna, misalnya editor artikel, bersihkan dengan pustaka terpercaya seperti DOMPurify dan jaga agar tetap diperbarui. Mengubah konten setelah disanitasi dapat membatalkan perlindungannya.
5. Pasang Content Security Policy yang ketat. CSP berbasis nonce atau hash membatasi skrip yang boleh berjalan, dan menjadi lapisan cadangan bila ada celah yang lolos. Detailnya ada di pengertian Content Security Policy.
6. Amankan cookie sesi. Atribut seperti HttpOnly, Secure, dan SameSite membatasi dampak XSS, tetapi OWASP menegaskan atribut ini tidak mencegah XSS itu sendiri.

Trusted Types, yaitu API browser yang memaksa sink berisiko hanya menerima nilai yang sudah disanitasi, dapat menjadi pengaman tambahan. OWASP mencatat API ini dapat memblokir sink DOM XSS pada browser berbasis Chromium.

OWASP juga mengingatkan bahwa WAF dan filter permintaan bukan pertahanan XSS yang bisa diandalkan sendirian. Perbaikan harus tetap dilakukan di kode. Hubungannya dengan celah lain: XSS dapat mengalahkan semua perlindungan CSRF karena skrip yang berjalan di origin Anda dapat membaca token dan mengirim permintaan yang sah.

Pertanyaan yang Sering Diajukan

Apa beda XSS dengan SQL injection?

XSS menyasar browser pengguna dengan menyisipkan skrip ke halaman, sedangkan SQL injection menyasar basis data di server dengan menyisipkan perintah ke dalam query. Keduanya sama-sama berakar pada input yang tidak diperlakukan sebagai data.

Apakah HTTPS mencegah XSS?

Tidak. HTTPS melindungi data dalam perjalanan, tetapi tidak mengubah cara aplikasi menyusun halaman. Skrip yang disisipkan tetap berjalan di situs ber-HTTPS.

Apakah framework modern otomatis bebas XSS?

Tidak sepenuhnya. Framework membantu lewat auto-escaping, tetapi celah muncul lagi ketika pengembang memakai fitur penyisipan HTML mentah, sink DOM berisiko, atau pustaka pihak ketiga yang rentan.

Apakah XSS hanya berbahaya bagi situs besar?

Tidak. Situs kecil dengan form komentar, kolom pencarian, atau plugin yang jarang diperbarui juga bisa dipakai untuk menyerang pengunjung maupun admin situs.

Kesimpulan

XSS terjadi ketika data tidak tepercaya berubah menjadi kode di browser. Pertahanannya berlapis: encoding sesuai konteks, sanitasi HTML, penggunaan sink yang aman, CSP yang ketat, dan pengamanan cookie. Jika Anda ingin berlatih mengenali dan memperbaiki celah seperti ini secara legal, kunjungi daftar kursus Linuxhackingid dan pelajari materi keamanan aplikasi web dari dasar.