Digital Transformation
CSRF (Cross-Site Request Forgery)
TL;DR: CSRF (Cross-Site Request Forgery) memanfaatkan kondisi pengguna yang masih login di sebuah situs untuk memicu aksi tertentu, seperti transfer dana, ubah email, atau hapus data, lewat permintaan yang berasal dari situs lain. Pertahanan modern bertumpu pada CSRF token, atribut cookie SameSite, dan verifikasi origin/referer di server.
Apa itu CSRF?
CSRF mengeksploitasi kepercayaan aplikasi terhadap browser pengguna. Saat seseorang sudah login di situs A, browser menyimpan session cookie. Jika pengguna membuka situs B yang berbahaya, situs B bisa memicu permintaan ke situs A (lewat form submit, image tag, atau fetch), dan browser otomatis menyertakan cookie sesi tersebut. Server situs A melihat permintaan itu sah karena cookie valid, lalu mengeksekusi aksi yang sebenarnya tidak pernah diinginkan pengguna.
Berbeda dengan XSS yang menjalankan skrip di domain target, CSRF tidak perlu mengakses skrip situs target. Ia hanya butuh kemampuan memicu request HTTP dari konteks lain.
Pola Serangan dan Pertahanan
| Vektor | Cara kerja | Pertahanan utama |
|---|---|---|
| Form auto-submit di situs penyerang | <form action="bank.com/transfer" method="POST"> jalan otomatis | CSRF token rotatif per session/form |
| Image tag GET | <img src="bank.com/transfer?to=..."> | Hindari aksi mengubah state lewat GET |
| Fetch lintas situs | Permintaan asynchronous dengan credential | SameSite=Lax atau Strict pada cookie sensitif |
Praktik standar industri menempatkan CSRF token tersembunyi di setiap form penting dan memvalidasi token tersebut di server sebelum aksi dijalankan. OWASP Cheat Sheet merekomendasikan kombinasi token plus SameSite sebagai pertahanan berlapis.
Kenapa Penting?
Untuk aplikasi web bisnis di Indonesia yang melibatkan akun pengguna, dari LMS, dashboard klien, hingga toko online, CSRF bisa berakibat dana berpindah, profil diubah, atau tindakan moderasi yang tidak diinginkan. Dalam audit keamanan beberapa proyek klien, Vito Atmo menemukan endpoint admin tanpa proteksi CSRF tetap aktif di production karena tim mengandalkan asumsi "kan butuh login dulu".
Pertanyaan Umum
Apakah JWT di header otomatis kebal CSRF?
Iya, jika token dikirim manual lewat Authorization header dan tidak disimpan di cookie. Tapi banyak implementasi tetap memakai cookie untuk JWT karena kemudahan, dan ini mengembalikan permukaan serangan CSRF.
SameSite=Lax sudah cukup?
Untuk banyak kasus ya, tapi tidak menutup celah lintas-tab dari form submission tertentu. Untuk endpoint sensitif (transfer, hapus, ubah kredensial), gabung dengan CSRF token dan validasi origin.