Tujuan artikel ini: menjelaskan CSRF (Cross‑Site Request Forgery) dengan bahasa sederhana, memisahkan mitos dari fakta, danr? menunjukkan apa yang benar‑benar terjadi di balik layar browser kita.
1️⃣ Mitos: “CSRF sama dengan hacking super rumit.”
Fakta:
CSRF justru serangan yang sangat sederhana. Penyerang hanya butuh satu hal: kamu masih login di situs target. Setelah itu, dia bisa menyelipkan gambar, form, atau link berbahaya yang memaksa browser‑mu mengirim permintaan ke situs tersebut.
Di balik layar: Browser selalu “rajin” mengirim cookie login tanpa menanya dulu, selama permintaan menuju domain yang sama. Penyerang memanfaatkan kerajinan ini.
2️⃣ Mitos: “Kalau pakai HTTPS, otomatis aman dari CSRF.”
Fakta:
HTTPS hanya mengenkripsi data saat dikirim, bukan mencegah browser mengirimnya. Kalau cookie login ikut terkirim lewat HTTPS, server tetap menganggap permintaan itu sah.
Di balik layar: Enkripsi HTTPS melindungi data dari penyadapan, bukan dari kesalahan tujuan (mis‑routing) yang dimanfaatkan CSRF.
3️⃣ Mitos: “Form pakai metode GET itu wajar kok, nggak bahaya.”
Fakta:
Metode GET sebaiknya untuk baca data saja. Kalau dipakai untuk aksi sensitif (hapus akun, transfer uang), URL‑nya bisa disisipkan di tag <img>, <a>, atau <script>—tempat favorit CSRF.
Di balik layar: Browser memuat gambar? Ia tetap jalankan URL itu, meski berisi perintah berbahaya, selama pakai GET.
4️⃣ Mitos: “CSRF cuma bisa terjadi di situs besar seperti bank.”
Fakta:
Selama situs punya fitur login, form, atau API yang mengubah data, dia rentan CSRF—baik blog pribadi, toko online, maupun portal sekolah.
Di balik layar: Skala tidak penting; yang penting ada cookie sesi. Penyerang menargetkan siapa saja, bahkan admin panel kecil.
5️⃣ Mitos: “Kalau sudah pakai token anti‑CSRF, 100 % aman.”
Fakta:
Token efektif asal diterapkan benar: token harus unik per sesi/form, diverifikasi server, dan tidak boleh terekspos lewat URL. Salah konfigurasi = celah baru.
Di balik layar: Banyak dev menaruh token di localStorage atau cache publik, lalu bisa dicuri lewat XSS. Token invalid? Server kadang lupa memeriksa!
6️⃣ Mitos: “JWT selalu kebal CSRF.”
Fakta:
JWT (JSON Web Token) memang tidak dikirim otomatis jika disimpan di localStorage, sehingga lebih aman dari CSRF. Namun, kalau JWT disimpan di cookie HttpOnly, ia tetap rentan dikirim otomatis → perlu perlindungan ekstra.
Di balik layar: CSRF bergantung pada auto‑send cookie. Simpan JWT di cookie, risiko kembali muncul.
7️⃣ Mitos: “Kalau user hati‑hati tidak klik link aneh, pasti selamat.”
Fakta:
Banyak CSRF tanpa klik: cukup buka halaman yang memuat konten berbahaya (iklan, gambar). Bahkan email yang autoload gambar bisa memicu CSRF.
Di balik layar:
<img src="https://bank.com/transfer?ke=999&jumlah=1">langsung dijalankan saat gambar dimuat, tanpa interaksi pengguna.
🔒 Cara Praktis Mencegah CSRF
-
CSRF Token unik + diverifikasi server.
-
SameSite Cookie (
Lax/Strict) supaya cookie tak ikut permintaan lintas‑situs. -
POST/PUT/DELETE untuk aksi penting; hindari GET.
-
Cek Referer/Origin Header di server.
-
Framework modern (Laravel, Django, Spring) sudah punya proteksi—aktifkan!
✍️ Kesimpulan
-
CSRF itu sederhana tapi mematikan—cukup manfaatkan kebiasaan browser mengirim cookie.
-
Mitos‑mitos di atas sering membuat developer lengah.
-
Perlindungan harus berlapis: token, SameSite, metode HTTP tepat, dan validasi header.
-
Penulis : Muhammad Aditya Alkhawarizmi
-
Nim : 23156201023
-
Jurusan : Sistem Komputer
