Clickjacking untuk Pemula: Saat yang Anda Klik Bukan yang Anda Lihat

Bayangkan Anda mengunjungi sebuah situs yang menawarkan "Putar Video Gratis". Ada tombol play besar di tengah layar. Anda klik. Yang terjadi bukan video yang mulai diputar — melainkan Anda baru saja menekan tombol "Follow" pada akun media sosial Anda, atau lebih parah, tombol "Transfer Dana" di aplikasi perbankan yang sedang login di tab lain.

Anda tidak pernah melihat tombol asli itu. Yang Anda lihat hanyalah lapisan palsu di atasnya. Inilah Clickjacking, atau lebih formal disebut UI Redressing — serangan yang mengelabui mata, bukan mengeksploitasi kode.

Kalau XSS, SQL Injection, dan CSRF menyerang lewat data atau request, Clickjacking menyerang lewat sesuatu yang lebih sederhana: apa yang Anda percaya sedang Anda klik.

Trik di Baliknya: Iframe Tak Terlihat

Inti dari Clickjacking sebenarnya sangat sederhana. Penyerang memuat halaman korban (misalnya halaman bank atau situs media sosial Anda) ke dalam sebuah <iframe>, lalu membuat iframe itu tidak terlihat dengan opacity: 0. Di atasnya, penyerang menaruh tampilan palsu yang menarik — tombol "Putar Video", "Menangkan Hadiah", atau semacamnya.

<style>
  iframe {
    position: absolute;
    top: 0;
    left: 0;
    width: 500px;
    height: 500px;
    opacity: 0;       /* Iframe asli tak terlihat mata */
    z-index: 2;        /* Tapi tetap di lapisan paling atas */
  }
  .tombol-umpan {
    position: absolute;
    top: 200px;
    left: 150px;
    z-index: 1;
  }
</style>

<div class="tombol-umpan">
  <button>Klik untuk Menangkan iPhone Gratis!</button>
</div>

<iframe src="https://bank-korban.com/transfer?tujuan=rekening-penyerang&jumlah=5000000"></iframe>

Trik posisinya: iframe asli (yang berisi tombol sungguhan di situs korban) diposisikan tepat di atas tombol umpan, tapi dibuat transparan. Secara visual Anda melihat tombol "Menangkan iPhone", tapi klik Anda sebenarnya jatuh tepat pada tombol asli yang tersembunyi di lapisan atasnya.

Browser Anda mencatat ini sebagai klik yang sah dari pengguna asli — karena memang begitu adanya, secara teknis. Anda benar-benar mengklik dengan mouse Anda sendiri. Yang dimanipulasi bukan browsernya, melainkan apa yang Anda kira sedang Anda klik.

Variasi yang lebih canggih disebut cursorjacking, di mana penyerang bahkan memanipulasi tampilan kursor mouse itu sendiri agar posisi klik Anda makin sulit ditebak dengan mata telanjang.

Kenapa Ini Berbeda dari CSRF?

Sekilas Clickjacking mirip CSRF — sama-sama memanfaatkan sesi login korban yang sedang aktif. Tapi mekanismenya sangat berbeda:

• CSRF memaksa browser mengirim request tanpa interaksi pengguna sama sekali — cukup memuat gambar atau form yang auto-submit.
• Clickjacking justru membutuhkan interaksi asli dari pengguna, tapi menipu di mana interaksi itu sebenarnya jatuh.

Ini juga berarti pertahanan CSRF token tidak otomatis melindungi dari Clickjacking. Kenapa? Karena pada Clickjacking, korban benar-benar berinteraksi dengan halaman asli lewat iframe — token CSRF yang sah pun ikut terkirim, sebab requestnya memang datang dari halaman resmi, hanya saja disamarkan secara visual.

Apa Saja yang Bisa Dieksploitasi?

Clickjacking sering diremehkan karena "cuma soal klik", padahal dampaknya bisa serius tergantung target:

• Like-jacking — memaksa korban menekan tombol "Like" atau "Follow" tanpa sadar, biasa dipakai untuk manipulasi engagement palsu.
• Perubahan pengaturan akun — mengklik "Aktifkan" pada fitur berbahaya, seperti mengizinkan akses kamera atau mikrofon di halaman yang meminta izin browser.
• Transaksi finansial — pada aplikasi yang tidak melindungi halaman transfer atau pembelian dari iframe, klik korban bisa memicu transaksi nyata.
• Login jacking — mengelabui korban memasukkan kredensial ke form yang terlihat normal, padahal form itu sebenarnya dikendalikan penyerang lewat manipulasi lapisan.

Pencegahan Utama: Larang Situs Anda Dijadikan Iframe

Kabar baiknya, pencegahan Clickjacking jauh lebih sederhana dibanding XSS atau SQL Injection. Intinya: cegah situs Anda dimuat di dalam iframe milik situs lain.

1. Header X-Frame-Options

Ini adalah header HTTP klasik yang didukung hampir semua browser:

X-Frame-Options: DENY

atau, jika Anda memang perlu meng-iframe-kan halaman Anda sendiri dari domain yang sama:

X-Frame-Options: SAMEORIGIN

Header ini memberi tahu browser: "Tolak muat halaman ini di dalam iframe apa pun." Simpel, langsung bekerja, dan cukup untuk sebagian besar kasus.

Contoh implementasi di Express:

app.use((req, res, next) => {
  res.setHeader('X-Frame-Options', 'DENY');
  next();
});

Contoh di konfigurasi Nginx:

add_header X-Frame-Options "DENY" always;

2. Content-Security-Policy: frame-ancestors

X-Frame-Options sudah mulai dianggap warisan lama. Standar modern menggantinya dengan directive frame-ancestors pada header Content-Security-Policy (CSP), yang jauh lebih fleksibel:

Content-Security-Policy: frame-ancestors 'none';

Atau jika Anda ingin mengizinkan domain tertentu saja untuk meng-iframe-kan halaman Anda:

Content-Security-Policy: frame-ancestors 'self' https://partner-terpercaya.com;

Keunggulan frame-ancestors dibanding X-Frame-Options adalah bisa mendaftarkan beberapa domain sekaligus — sesuatu yang tidak bisa dilakukan X-Frame-Options. Jika kedua header ini sama-sama dipasang, browser modern akan memprioritaskan CSP, sehingga X-Frame-Options berfungsi sebagai fallback untuk browser yang lebih tua.

Praktik terbaik: pasang keduanya sekaligus. frame-ancestors untuk browser modern, X-Frame-Options sebagai jaring pengaman untuk kompatibilitas lawas.

3. Frame-Busting Script (Tidak Direkomendasikan)

Sebelum header di atas populer, developer biasa memakai trik JavaScript seperti ini untuk "memecahkan" iframe:

if (top !== self) {
  top.location = self.location;
}

Pendekatan ini rapuh dan mudah dilewati — penyerang cukup memakai atribut sandbox pada iframe untuk menonaktifkan navigasi JavaScript dari dalamnya. Jangan mengandalkan ini sebagai satu-satunya pertahanan; selalu gunakan header HTTP sebagai lini utama.

Pertahanan Tambahan di Sisi Pengguna

Meski tanggung jawab utama ada di developer, beberapa kebiasaan berikut membantu mengurangi risiko dari sisi pengguna:

• Waspadai halaman dengan tombol yang terasa "terlalu menggoda" — hadiah gratis, konten eksklusif, atau tombol play mencurigakan.
• Ekstensi browser modern dan pengaturan privasi umumnya sudah memblokir sebagian pola iframe mencurigakan secara otomatis.
• Logout dari sesi penting (perbankan, admin panel) saat tidak digunakan, terutama sebelum menjelajah situs yang tidak dikenal.

Kesalahan yang Sering Terjadi

• Hanya memasang X-Frame-Options tanpa frame-ancestors — cukup untuk browser modern hari ini, tapi kehilangan fleksibilitas mengizinkan beberapa domain tepercaya sekaligus.
• Mengandalkan frame-busting script sebagai satu-satunya pertahanan, padahal mudah dilewati.
• Lupa memproteksi halaman transaksi/pengaturan sensitif karena fokus proteksi hanya di halaman login.
• Header CSP terlalu longgar — misalnya memasang frame-ancestors * tanpa sadar ini sama saja dengan tidak melindungi apa pun.

Penutup

Clickjacking mengajarkan satu hal penting: keamanan aplikasi tidak selalu soal validasi data atau enkripsi. Kadang, ancamannya sesederhana apa yang tampak di layar tidak sama dengan apa yang sebenarnya diklik.

Untungnya, pertahanannya juga sederhana — dua baris header HTTP sudah cukup menutup celah ini untuk sebagian besar aplikasi. Periksa hari ini: apakah aplikasi Anda sudah mengirim X-Frame-Options atau Content-Security-Policy: frame-ancestors? Jika belum, itu satu perbaikan cepat yang layak dikerjakan sekarang juga.