CSRF untuk Pemula: Ketika Browser Anda Sendiri Jadi Senjata...

Bayangkan Anda sedang login di aplikasi perbankan Anda, lalu tanpa logout, Anda membuka tab baru dan mengunjungi sebuah forum. Di forum itu ada satu gambar kecil yang tampak biasa saja. Yang tidak Anda sadari: begitu gambar itu dimuat, browser Anda diam-diam mengirim permintaan transfer dana — dan karena Anda masih login, permintaan itu dianggap sah oleh server bank.

Itulah CSRF (Cross-Site Request Forgery). Kita sudah membahas XSS dan CORS di artikel sebelumnya; CSRF melengkapi trio konsep yang wajib dipahami setiap developer web, karena ketiganya sering tertukar padahal mekanismenya sangat berbeda.

Kunci untuk Memahami CSRF: Browser Itu "Setia"

Untuk memahami CSRF, Anda perlu tahu satu kebiasaan bawaan browser: setiap kali browser mengirim request ke sebuah domain, ia otomatis menyertakan cookie yang tersimpan untuk domain itu — tidak peduli halaman mana yang memicu request tersebut.

Cookie sesi login Anda tidak tahu bahwa request datang dari halaman jahat. Ia hanya tahu tujuan requestnya adalah bank.com, dan karena ada cookie sesi yang valid untuk bank.com, browser mengirimkannya dengan patuh.

Penyerang memanfaatkan kesetiaan ini. Ia tidak perlu mencuri cookie Anda, tidak perlu tahu password Anda, dan tidak perlu membobol apa pun. Ia cukup membuat browser Anda mengirim request yang tampak sah, lalu meminjam sesi login Anda yang sedang aktif.

Anatomi Serangan CSRF

Skenario paling klasik: ubah email akun korban tanpa sepengetahuannya.

Misalkan aplikasi punya endpoint ubah email seperti ini:

GET /akun/ubah-email?email=baru@contoh.com

Karena memakai method GET dan tidak memvalidasi asal request, endpoint ini rentan. Penyerang tinggal menyisipkan tag gambar di situs yang ia kendalikan:

<img src="https://bank.com/akun/ubah-email?email=penyerang@jahat.com" width="0" height="0">

Ketika korban yang sedang login membuka halaman itu, browser mencoba memuat "gambar" tersebut. Padahal itu bukan gambar — itu adalah request GET lengkap dengan cookie sesi korban. Email akun korban pun berubah, tanpa satu klik pun dari korban.

Untuk endpoint yang memakai POST, penyerang memakai form tersembunyi yang otomatis submit sendiri:

<form action="https://bank.com/transfer" method="POST" id="formJahat">
  <input type="hidden" name="tujuan" value="rekening-penyerang">
  <input type="hidden" name="jumlah" value="5000000">
</form>
<script>document.getElementById('formJahat').submit();</script>

Korban hanya perlu membuka halaman ini sekali. Tidak ada peringatan, tidak ada dialog konfirmasi — form terkirim otomatis di latar belakang.

Perhatikan: pada kedua contoh, penyerang tidak pernah bisa membaca hasil responsnya. Ia hanya mengirim perintah secara membabi buta. Inilah perbedaan mendasar yang akan kita bahas berikutnya.

CSRF vs XSS vs CORS: Jangan Sampai Tertukar

Ini adalah bagian yang paling sering membingungkan pemula, karena ketiganya beririsan di area yang sama.

XSS — penyerang menyisipkan skrip ke dalam halaman Anda. Karena skrip itu berjalan seolah bagian dari situs Anda, ia bisa membaca apa saja: cookie, isi halaman, data yang diketik pengguna.

CSRF — penyerang tidak pernah masuk ke situs Anda. Ia memicu browser korban mengirim request dari luar. Karena berasal dari origin lain, browser tidak mengizinkan penyerang membaca hasilnya — ia hanya bisa menembak dan berharap efeknya terjadi.

CORS — sama sekali bukan serangan. CORS adalah aturan yang menentukan apakah JavaScript di satu origin boleh membaca respons dari origin lain. Ada kaitannya dengan CSRF, tetapi CORS tidak dirancang untuk mencegah CSRF — CORS mengatur akses baca lintas origin lewat JavaScript, sedangkan form HTML biasa mengirim request tanpa peduli aturan CORS sama sekali.

Ringkasnya: XSS itu membaca dari dalam, CSRF itu menembak dari luar tanpa bisa melihat hasilnya, dan CORS mengatur siapa yang boleh membaca respons lintas origin.

Catatan penting: jika aplikasi Anda punya celah XSS, maka pertahanan CSRF apa pun jadi tidak berguna. Skrip yang berjalan lewat XSS bisa membaca token CSRF Anda sendiri lalu memakainya. Karena itu XSS selalu jadi prioritas nomor satu.

Pencegahan Utama: CSRF Token

Pertahanan paling mapan adalah synchronizer token pattern. Idenya: setiap form atau request yang mengubah data harus menyertakan token acak yang hanya diketahui oleh halaman asli aplikasi.

Alurnya:

1. Server membuat token acak unik saat pengguna memuat halaman form.
2. Token disisipkan sebagai field tersembunyi di form.
3. Saat form dikirim, server mencocokkan token dari request dengan token yang tersimpan di sesi.
4. Jika cocok, request diproses. Jika tidak cocok atau tidak ada, request ditolak.

Penyerang tidak bisa menebak token ini, dan karena SOP mencegahnya membaca halaman asli aplikasi, ia tidak punya cara mendapatkan token yang valid.

Contoh implementasi (Express dengan csurf-style middleware):

app.use(csrfProtection);

app.get('/akun/ubah-email', (req, res) => {
  res.render('form-email', { csrfToken: req.csrfToken() });
});

app.post('/akun/ubah-email', (req, res) => {
  // Middleware otomatis menolak jika token tidak valid
  // Kode di sini hanya berjalan jika token cocok
});

Di sisi HTML:

<form action="/akun/ubah-email" method="POST">
  <input type="hidden" name="_csrf" value="{{csrfToken}}">
  <input type="email" name="email">
  <button type="submit">Simpan</button>
</form>

Kebanyakan framework modern — Laravel, Django, Rails — sudah menyediakan proteksi CSRF token secara bawaan. Tugas developer biasanya hanya memastikan fitur ini tidak dimatikan demi kepraktisan saat development.

Lapisan Pertahanan Tambahan

Cookie SameSite. Ini adalah pertahanan modern yang bekerja di level browser:

Set-Cookie: session=abc123; SameSite=Lax; Secure; HttpOnly

• SameSite=Strict — cookie sama sekali tidak dikirim pada request lintas situs. Paling aman, tapi bisa mengganggu alur seperti klik dari email.
• SameSite=Lax — cookie tetap dikirim untuk navigasi biasa (klik link), tapi diblokir untuk request dari form atau script lintas situs. Ini nilai default di browser modern saat ini.
• SameSite=None — perilaku lama, cookie selalu dikirim. Hanya dipakai jika memang dibutuhkan, dan wajib disertai Secure.

SameSite adalah lapisan pertahanan yang kuat, tetapi jangan jadikan satu-satunya andalan. Sebagian browser lama belum mendukungnya penuh, dan beberapa skenario legit (widget pihak ketiga, pembayaran) tetap membutuhkan SameSite=None.

Gunakan method yang sesuai fungsinya. Aksi yang mengubah data — ubah email, hapus akun, transfer dana — tidak boleh memakai GET. Selain soal CSRF, ini juga mencegah request tersimpan tanpa sengaja di riwayat browser, proxy, atau cache.

Konfirmasi ulang untuk aksi sensitif. Meminta password ulang sebelum mengubah email atau melakukan transfer besar menambah lapisan pertahanan meskipun token CSRF entah bagaimana berhasil dilewati.

Periksa header Origin atau Referer. Sebagai lapisan tambahan (bukan pengganti token), server bisa menolak request POST yang header Origin-nya tidak cocok dengan domain aplikasi sendiri.

Kesalahan yang Sering Terjadi

• Mengecualikan API dari proteksi CSRF dengan asumsi "API kan dipakai lewat token JWT, bukan cookie" — padahal jika token disimpan di cookie (bukan header Authorization), API tersebut tetap rentan.
• Mematikan middleware CSRF saat development karena dianggap mengganggu, lalu lupa menyalakannya kembali sebelum deploy ke produksi.
• Memakai GET untuk aksi yang mengubah data demi kepraktisan link, tanpa sadar ini membuka pintu CSRF paling sederhana.
• Menaruh token CSRF di localStorage alih-alih di form tersembunyi atau cookie yang dikelola server — ini membuka celah baru lewat XSS.

Penutup

CSRF mengandalkan satu hal yang sebenarnya adalah fitur, bukan bug: browser yang setia mengirim cookie ke domain tujuannya. Yang membuatnya berbahaya bukan kecanggihan teknik, melainkan betapa mudahnya dilupakan — cukup satu endpoint pengubah data yang tidak dilindungi token, dan penyerang punya jalan masuk tanpa perlu mencuri apa pun dari korban.

Kabar baiknya, sebagian besar framework modern sudah menyalakan proteksi ini secara default. Tugas Anda sebagai developer sederhana: jangan pernah mematikannya demi kemudahan sesaat, pastikan aksi yang mengubah data memakai method yang tepat, dan tambahkan SameSite sebagai lapisan pengaman kedua.