Apa itu CSRF? Melindungi tindakan pengguna di website

Mengapa sudah login belum cukup?

Cross-site request forgery (CSRF) terjadi ketika browser pengguna dipicu mengirim tindakan ke aplikasi yang mempercayai kredensial yang ikut terkirim. Risiko ini penting pada aplikasi yang memakai cookie sesi, karena browser dapat menyertakannya secara otomatis sesuai aturan cookie.

Login membuktikan identitas sesi. Ia belum membuktikan bahwa setiap permintaan perubahan memang berasal dari alur yang dimaksud pengguna. Periksa perubahan email, alamat, izin, dan pengaturan akun, bukan hanya transaksi bernilai uang.

Contoh: mengganti alamat pengiriman

Pada toko fiktif, pelanggan masuk ke akun lalu mengunjungi halaman lain. Tim menguji apakah halaman luar dapat memicu perubahan alamat di toko tanpa melalui formulir yang sah.

Di lingkungan uji, aplikasi harus menolak perubahan yang tidak memenuhi pemeriksaan CSRF. Tim memastikan alamat sebelum dan sesudah pengujian tetap sama. Memeriksa pesan penolakan di browser saja tidak cukup jika database ternyata sudah berubah.

Susun perlindungan sesuai autentikasi

1. Periksa mekanisme CSRF bawaan framework dan aktifkan sesuai dokumentasinya.
2. Untuk pola token, server memeriksa token yang valid dan terkait sesi pada permintaan perubahan. Jangan mengandalkan cookie token yang dikirim otomatis tanpa pembuktian tambahan.
3. Terapkan pemeriksaan asal permintaan atau Fetch Metadata sesuai dukungan platform, dengan penanganan yang jelas saat informasi tidak tersedia.
4. Atur cookie sesi, termasuk SameSite, sebagai bagian dari desain. Jangan menganggapnya satu-satunya perlindungan pada semua alur.
5. Hindari operasi perubahan melalui GET; perubahan perlu metode dan pemeriksaan server yang sesuai.

Untuk API yang memakai kredensial yang ditambahkan sendiri oleh aplikasi klien, analisis jalurnya dapat berbeda. Jangan menghapus perlindungan hanya karena endpoint disebut “API”. Catat apakah cookie, autentikasi browser, atau cara lain tetap digunakan.

Hal yang perlu diuji

Kasus	Hasil yang diharapkan
Formulir sah dan sesi yang benar	Perubahan yang diizinkan berhasil
Token hilang, salah, atau berasal dari sesi lain	Perubahan ditolak pada server
Permintaan dari asal yang tidak diizinkan	Tidak mengubah data
Tombol kembali atau sesi berakhir	Pengguna mendapat jalur pemulihan yang jelas tanpa perubahan diam-diam

Gunakan akun dan data buatan. Catat respons serta keadaan data setelah permintaan. Sesuaikan kasus dengan pertahanan yang dipilih; tabel ini bukan daftar uji lengkap untuk semua framework.

CSRF, CORS, dan XSS berbeda

CORS mengatur kapan browser boleh membagikan respons lintas origin; bukan pengganti pertahanan CSRF. XSS dapat merusak perlindungan CSRF dengan menjalankan kode dalam konteks aplikasi. Keduanya perlu ditangani.