- By Siti Asiah
- 15 Oktober 2026
Jasa Pembuatan Website Bogor dengan Proteksi Frame Granular Anti-Clickjacking
Bayangkan seorang pengguna membuka sebuah halaman yang tampak biasa, lalu mengklik tombol “Dapatkan Hadiah”. Tanpa ia sadari, di atas tombol itu terdapat lapisan transparan berisi halaman pembayaran milik situs lain, dan klik tersebut sebenarnya menekan tombol “Konfirmasi” di sana. Itulah clickjacking: serangan yang menipu pengguna agar mengklik elemen tersembunyi atau disamarkan di dalam halaman yang dibenamkan.
Bagi portal registrasi sertifikasi dan pembayaran daring, risiko ini serius karena satu klik dapat berarti persetujuan transaksi atau perubahan data.
Bagaimana Serangan Ini Terjadi
Penyerang membuat situs dengan iframe tak terlihat atau disamarkan yang memuat halaman target. Jika server target tidak melarang halamannya dibenamkan, peramban akan merendernya begitu saja. Menurut deskripsi yang lazim dipakai pemindai kerentanan web, kerentanan ini muncul ketika server tidak menyertakan directive frame-ancestors pada header Content-Security-Policy, sehingga aplikasi dapat dibenamkan di situs berbahaya.
Dua Pertahanan Utama: X-Frame-Options dan frame-ancestors
Panduan keamanan MDN menyebut dua mekanisme untuk membatasi pembenaman:
1. Header X-Frame-Options. Sifatnya sederhana dan kasar. Nilainya hanya melarang semua pembenaman (DENY) atau mengizinkan hanya dari origin yang sama (SAMEORIGIN). Nilai ALLOW-FROM sudah usang dan tidak didukung luas.
2. Directive CSP frame-ancestors. Inilah pengganti modern yang jauh lebih fleksibel. Pengelola dapat menuliskan daftar origin yang diizinkan, misalnya hanya 'self' ditambah beberapa domain terdaftar.
Contoh pola yang umum: frame-ancestors 'none' untuk melarang semua pembenaman, frame-ancestors 'self' untuk hanya mengizinkan situs sendiri, atau frame-ancestors 'self' https://domain-resmi.example untuk mengizinkan domain tertentu. Jika kedua header dipasang bersamaan, browser yang mendukung frame-ancestors akan mengabaikan X-Frame-Options, sedangkan browser lama tetap memakai X-Frame-Options sebagai cadangan.
Perlindungan Granular untuk Sistem Iframe Internal
Banyak perusahaan memang perlu membenamkan portal pembayaran atau registrasinya ke dalam sistem internal, seperti dasbor mitra atau aplikasi back-office. Melarang semua pembenaman akan merusak fungsi tersebut, sedangkan membukanya untuk semua pihak berbahaya. Solusinya adalah pendekatan granular:
- Allowlist eksplisit. Daftarkan hanya origin yang benar-benar dikenal, lengkap dengan skema
https, sebagai nilaiframe-ancestors. - Jangan pernah memakai wildcard terbuka. Panduan keamanan header HTTP menegaskan agar tidak memakai
frame-ancestors *maupun menghilangkan directive-nya. - Pasang di semua respons HTML. Header harus hadir pada setiap halaman sensitif, bukan hanya beranda.
- Sinkronkan dengan header cadangan. Karena X-Frame-Options tidak bisa menyatakan beberapa origin sekaligus, nilainya menjadi kompromi untuk browser lama. Satu laporan perbaikan di proyek sumber terbuka bahkan mencatat kasus ketika allowlist kustom masih disertai
X-Frame-Options: DENY, sehingga konfigurasinya saling bertentangan. Detail seperti ini perlu diuji, bukan diasumsikan. - Atur header per rute. Halaman yang memang untuk disematkan dapat memakai allowlist, sementara halaman login dan konfirmasi pembayaran dibuat lebih ketat.
Lapisan Tambahan yang Perlu Menyertai
Header pembatas frame bukan satu-satunya pagar. MDN merekomendasikan pula atribut cookie SameSite pada cookie sesi dengan nilai Lax atau Strict. Kombinasi dengan autentikasi yang kuat, konfirmasi tambahan untuk aksi sensitif seperti pembayaran, dan pengujian rutin akan memperkecil celah yang tersisa. Perlu diingat pula bahwa meta tag tidak dapat menggantikan header: pembatasan frame harus dikirim sebagai header respons HTTP.
Mengapa Perlu Dirancang Sejak Awal
Konfigurasi yang terlalu longgar membuka celah, sedangkan yang terlalu ketat bisa memutus integrasi yang sah. Menentukan keseimbangannya memerlukan pemahaman alur sistem: halaman mana yang disematkan, oleh siapa, dan di domain apa. Layanan Jasa Pembuatan Aplikasi Berbasis Web dari Bogorwebsite.com mencakup pengembangan sistem dengan memperhatikan keamanan sejak tahap perancangan, termasuk untuk portal registrasi dan transaksi daring.
Dengan pengalaman lebih dari 15 tahun menangani proyek bagi berbagai instansi dan perusahaan, yang dapat dilihat pada halaman portofolio, tim kami terbiasa menerjemahkan kebutuhan keamanan menjadi konfigurasi yang rapi dan teruji.
Pastikan Hanya Pihak Terpercaya yang Dapat Membenamkan Halaman Anda
Kepercayaan pada portal pembayaran dan sertifikasi dibangun dari detail yang tidak tampak oleh pengguna. Membatasi siapa yang boleh memuat halaman Anda adalah salah satunya. Jika Anda sedang membangun atau mengevaluasi portal registrasi dan pembayaran daring, tim Bogorwebsite.com siap membantu merancang proteksi yang sesuai. Hubungi kami melalui WhatsApp atau kunjungi halaman kontak.
