Apa Itu CSRF (Cross-Site Request Forgery)? Panduan Lengkap

"Confused Deputy" di Inti Masalah

Para peneliti keamanan memiliki istilah spesifik dan benar-benar mencerahkan untuk kelemahan struktural mendasar yang memungkinkan CSRF terjadi, yaitu masalah confused deputy atau wakil yang bingung. Dalam kerangka ini, "wakil" adalah program atau sistem apa pun yang telah diberikan wewenang sah untuk melakukan tindakan atas nama seseorang — dalam konteks CSRF, aplikasi web itu sendiri, yang telah diberikan wewenang untuk bertindak atas nama pengguna yang masuk setelah pengguna tersebut melakukan otentikasi. Wakil tersebut menjadi "bingung" ketika ia tertipu untuk menggunakan wewenang sah tersebut untuk melakukan tindakan atas nama pihak lain selain pihak yang seharusnya mengarahkannya.

Kerangka ini memperjelas sesuatu yang mudah terlewatkan ketika CSRF hanya dijelaskan secara mekanis, yaitu kerentanan ini pada dasarnya bukan tentang kredensial yang dicuri atau otentikasi yang rusak sama sekali. Pengguna benar-benar adalah siapa yang mereka klaim. Sesi mereka benar-benar valid. Cookie mereka benar-benar membuktikan bahwa mereka telah masuk. Sistem otentikasi aplikasi, dalam arti teknis yang sempit, berfungsi dengan benar sepenuhnya. Kegagalan terletak satu lapisan di atasnya, yaitu ketidakmampuan aplikasi untuk membedakan antara permintaan yang sebenarnya ingin dibuat pengguna dan permintaan yang hanya sampai membawa kredensial valid pengguna karena browser mereka melampirkannya secara otomatis, tanpa niat atau kesadaran sebenarnya dari pihak pengguna.

Perbedaan ini — antara membuktikan siapa yang membuat permintaan dan membuktikan bahwa permintaan tersebut mencerminkan tindakan yang tulus dan disengaja oleh orang tertentu — adalah inti konseptual yang menjadi dasar setiap pertahanan CSRF yang efektif, mulai dari token CSRF hingga atribut cookie SameSite.

Mengapa Otentikasi Saja Tidak Melindungi Kita

Alasan mengapa otentikasi saja gagal adalah karena CSRF sama sekali tidak mencoba untuk melewati otentikasi — ia sengaja memanfaatkannya. Seluruh serangan bergantung pada korban yang sudah terotentikasi ke situs target pada saat permintaan palsu diluncurkan. Serangan CSRF yang dirancang dengan baik tidak perlu menebak kata sandi, tidak perlu mencuri token sesi secara langsung, dan tidak perlu mengalahkan mekanisme login apa pun. Serangan tersebut hanya membutuhkan korban untuk memiliki sesi aktif dan valid dengan aplikasi target — tepatnya kondisi yang diciptakan oleh aplikasi yang aman dan terotentikasi dengan benar untuk setiap pengguna yang masuk, setiap hari. Dalam konteks ini, semakin mudah dan konsisten suatu situs membuat pengguna tetap masuk (logged in), semakin besar pula potensi kerentanan terhadap CSRF jika tidak ada pertahanan tambahan yang diterapkan, karena sesi yang lebih lama berarti lebih banyak waktu di mana permintaan palsu akan diterima sebagai sah.

Inilah mengapa CSRF membutuhkan kategori pertahanan khusus, yang sepenuhnya terpisah dari kebijakan kata sandi, otentikasi multi-faktor, atau praktik terbaik manajemen sesi. Semua mekanisme tersebut menjawab pertanyaan "apakah ini benar-benar pemilik akun?" Pertahanan CSRF harus menjawab pertanyaan yang benar-benar berbeda: "apakah pemilik akun benar-benar bermaksud membuat permintaan khusus ini?"

Bagaimana Serangan CSRF Sebenarnya Terjadi

Serangan dimulai dengan penyerang mengidentifikasi tindakan yang mengubah status dalam aplikasi target — yaitu sesuatu yang benar-benar mengubah data atau memicu konsekuensi, seperti mengubah alamat email akun, memulai transfer dana, memodifikasi kata sandi, atau mengubah izin akun — yang diizinkan oleh aplikasi target untuk dipicu melalui struktur permintaan yang dapat diprediksi dan tampak tidak terautentikasi, tanpa perlindungan yang memadai terhadap pengajuan palsu.

Penyerang kemudian membuat halaman berbahaya — biasanya formulir HTML yang secara otomatis mengirimkan dirinya sendiri melalui JavaScript saat halaman dimuat, atau dalam kasus yang lebih sederhana, tidak lebih dari tag yang URL sumbernya mengarah langsung ke tindakan yang rentan — yang, ketika dimuat di browser mana pun, mengirimkan permintaan yang tepat yang dibutuhkan untuk memicu tindakan sensitif tersebut. Yang penting, halaman berbahaya ini dihosting sepenuhnya pada infrastruktur yang dikendalikan penyerang; Tidak perlu sama sekali untuk dihosting di, atau membahayakan, server aplikasi target itu sendiri.

Penyerang kemudian memancing korban untuk mengunjungi halaman berbahaya ini saat korban kebetulan memiliki sesi aktif dan terautentikasi yang terbuka dengan aplikasi target — biasanya dilakukan melalui email phishing, iklan berbahaya, tautan yang diposting di media sosial, atau vektor rekayasa sosial lainnya yang membuat browser korban memuat halaman penyerang. Saat browser korban memuat halaman berbahaya dan menjalankan pengiriman formulir atau permintaan gambar yang disematkan, browser secara otomatis melampirkan cookie sesi valid korban untuk domain target ke permintaan tersebut — yaitu perilaku lampiran cookie otomatis yang sama seperti yang dijelaskan sebelumnya dalam panduan ini — dan mengirimkannya persis seolah-olah korban telah sengaja mengklik tombol di dalam aplikasi yang sah itu sendiri.

Aplikasi target menerima apa yang, dari sudut pandang teknis murni, tampak sebagai permintaan yang sepenuhnya normal dan terautentikasi, dan — tanpa adanya pertahanan — memprosesnya persis seperti memproses permintaan yang benar-benar dan sengaja diajukan oleh pengguna, melakukan tindakan sensitif atas nama penyerang tanpa korban menyadari bahwa sesuatu telah terjadi sama sekali.

Penjelasan Praktis: Transfer Bank Palsu

Bayangkan kita masuk ke website bank kita di satu tab browser untuk memeriksa saldo rekening, dan sesi kita tetap aktif di tab tersebut. Di tab lain, atau mungkin di hari yang sama tanpa pernah menutup browser sepenuhnya, kita mengunjungi website yang sama sekali tidak terkait — mungkin halaman yang dikirimkan kepada kita sebagai bagian dari email promosi, atau tautan yang dibagikan dalam postingan forum — yang kebetulan telah dibuat, atau diretas, oleh penyerang. Tertanam secara tak terlihat di halaman berbahaya tersebut adalah formulir yang terstruktur agar terlihat persis seperti permintaan transfer dana bank itu sendiri, yaitu formulir tersebut mengarah ke endpoint transfer bank yang sebenarnya, dan menentukan rekening tujuan (rekening penyerang sendiri) dan jumlah transfer, dengan setiap kolom diisi sebelumnya oleh penyerang daripada dibiarkan untuk kita masukkan.

Jika formulir tersembunyi tersebut diatur untuk mengirimkan dirinya sendiri secara otomatis melalui sepotong kecil JavaScript yang disematkan saat halaman berbahaya dimuat, browser kita mengirimkan permintaan transfer tersebut ke server asli bank kita — dan karena browser kita masih menyimpan cookie sesi yang valid dan aktif untuk bank tersebut dari login kita sebelumnya, browser secara otomatis melampirkan cookie tersebut ke permintaan palsu. Dari perspektif server bank, permintaan transfer dana yang sepenuhnya terautentikasi baru saja tiba, tidak dapat dibedakan di tingkat jaringan dari permintaan yang akan kita kirimkan dengan sengaja mengisi dan mengklik kirim pada formulir transfer bank itu sendiri. Jika aplikasi bank belum menerapkan pertahanan apa pun, transfer akan dieksekusi persis seperti yang diminta — uang meninggalkan akun kita dan berpindah ke penyerang, dan kita mungkin tidak mengetahui apa yang terjadi sampai kita meninjau laporan rekening kita berikutnya.

Inilah mengapa CSRF terkadang secara informal digambarkan sebagai "serangan satu klik", karena seluruh eksploitasi tidak memerlukan apa pun dari korban selain tindakan sederhana dan biasa yaitu memuat halaman berbahaya sambil secara terpisah, dan sepenuhnya kebetulan, memegang sesi aktif dengan aplikasi yang ditargetkan.

GET vs. POST: Mengapa Keduanya Dapat Dieksploitasi

Permintaan GET memang sangat mudah dipalsukan: satu tag , yang disematkan di mana pun penyerang dapat membuat browser korban menampilkannya, akan memicu permintaan tersebut tepat saat halaman dimuat, dengan lampiran cookie otomatis browser melakukan sisanya — tidak ada JavaScript, tidak ada formulir, tidak ada interaksi pengguna apa pun yang diperlukan selain hanya memuat halaman yang berisi tag tersebut. Inilah mengapa panduan keamanan modern secara tegas menyatakan bahwa permintaan GET tidak boleh digunakan untuk memicu tindakan apa pun yang benar-benar mengubah data atau status, dan hanya menggunakan GET untuk operasi baca-saja yang aman dan tidak menimbulkan konsekuensi berarti jika dipicu secara tidak sengaja.

Namun, membatasi tindakan sensitif hanya pada permintaan POST hanya meningkatkan tantangan bagi penyerang — hal itu tidak menghilangkan kerentanan. Formulir HTML yang mengirimkan data secara otomatis, persis seperti yang dijelaskan dalam contoh transfer bank di atas, memalsukan permintaan POST sama andalnya dengan tag gambar yang memalsukan permintaan GET; hanya membutuhkan satu langkah tambahan (dan mudah diotomatisasi dengan skrip) untuk membuat elemen formulir daripada tag gambar. Setiap developer atau tim yang menganggap "kami hanya mengizinkan tindakan ini melalui POST" sebagai pertahanan CSRF yang lengkap hanya mengatasi varian serangan yang paling malas dan tidak canggih, sementara tetap sepenuhnya rentan terhadap versi berbasis formulir yang sedikit lebih canggih, dan hampir tidak lebih sulit untuk dibuat, dari eksploitasi yang sama persis.

Dampak di Dunia Nyata: Apa yang Sebenarnya Dapat Dilakukan CSRF

Pada tingkat akun, CSRF secara historis telah digunakan untuk mengubah alamat email atau kata sandi akun korban — varian yang sangat berbahaya, karena begitu penyerang mengendalikan alamat email atau kata sandi yang terkait dengan suatu akun, mereka biasanya dapat menggunakan alur pengaturan ulang kata sandi aplikasi itu sendiri untuk mengunci pemilik yang sah sepenuhnya dan mengambil kendali penuh dan permanen atas akun tersebut ke depannya, mengubah satu permintaan palsu menjadi pengambilalihan akun yang lengkap dan permanen. Dalam konteks keuangan, CSRF telah digunakan untuk memalsukan transfer dana dan otorisasi pembayaran yang tidak sah, persis seperti yang diilustrasikan dalam contoh bank di atas, dengan kerugian finansial yang dapat diukur secara langsung sebagai konsekuensinya.

Dalam konteks administratif dan hak akses istimewa, kerentanan CSRF pada aplikasi yang digunakan oleh administrator dapat jauh lebih berdampak daripada kelas kerentanan yang sama pada aplikasi yang digunakan oleh konsumen, karena permintaan palsu yang dieksekusi dengan kredensial sesi administratif dapat memberikan penyerang hak akses yang lebih tinggi, sehingga membuat akun istimewa baru di bawah kendali penyerang, atau memodifikasi pengaturan konfigurasi yang penting bagi keamanan — mengubah apa yang mungkin hanya menjadi ketidaknyamanan bagi satu pengguna menjadi kompromi di seluruh organisasi. Platform yang berfokus pada konten dan reputasi telah melihat CSRF digunakan untuk memalsukan unggahan media sosial, pesan forum, atau perubahan profil publik atas nama korban, menyebabkan kerugian reputasi yang tidak pernah diizinkan atau dimaksudkan oleh korban.

Benang merah yang menyatukan semua contoh ini adalah bahwa tingkat keparahan kerentanan CSRF sepenuhnya bergantung pada apa yang diizinkan oleh tindakan yang dikompromikan — itulah sebabnya penilaian keamanan memperlakukan kerentanan CSRF pada titik akhir dengan hak akses tinggi atau yang berdampak finansial sebagai sesuatu yang jauh lebih mendesak untuk diperbaiki daripada kelemahan mendasar yang sama pada pengaturan akun yang berdampak rendah.

Mengapa API dan Single-Page Application Tidak Secara Otomatis Aman

Kesalahpahaman yang terus-menerus terjadi di antara para developer yang membangun aplikasi modern berbasis API — seperti API REST, backend GraphQL, dan single-page application yang menggunakannya — adalah asumsi bahwa karena arsitektur ini tidak bergantung pada pengiriman formulir HTML tradisional, maka secara inheren kebal terhadap CSRF. Asumsi ini salah, dan telah menyebabkan kerentanan nyata yang dapat dieksploitasi dalam sistem produksi.

Faktor penentunya bukanlah apakah suatu aplikasi menggunakan formulir tradisional atau API berbasis JSON modern — melainkan apakah aplikasi tersebut bergantung pada cookie untuk otentikasi sama sekali. Setiap API REST atau GraphQL yang mengotentikasi permintaan menggunakan cookie sesi tetap sama rentannya terhadap CSRF seperti aplikasi web yang dirender server tradisional, justru karena browser secara otomatis melampirkan cookie ke permintaan lintas asal terlepas dari apakah permintaan tersebut berasal dari formulir HTML klasik atau dari JavaScript yang dieksekusi pada halaman yang dikendalikan penyerang yang mengeluarkan panggilan fetch atau XMLHttpRequest. Tanpa pengamanan tambahan yang disengaja — seperti token CSRF, atribut cookie SameSite, atau persyaratan header khusus — API yang diautentikasi dengan cookie benar-benar sama rentannya dengan aplikasi web berbasis formulir klasik, terlepas dari penampilan yang menunjukkan sebaliknya.

Aplikasi yang mengautentikasi setiap permintaan menggunakan token bearer yang disimpan dalam penyimpanan lokal atau memori, dan secara eksplisit dilampirkan ke setiap permintaan melalui header Otorisasi yang sengaja diatur oleh JavaScript aplikasi itu sendiri daripada dilampirkan secara otomatis oleh browser, secara struktural jauh lebih tahan terhadap CSRF klasik, karena halaman berbahaya penyerang tidak memiliki mekanisme otomatis untuk membaca token yang tersimpan tersebut dan tidak dapat menyebabkan browser korban melampirkannya ke permintaan palsu seperti halnya melampirkan cookie secara otomatis. Perbedaan arsitektur inilah yang menjadi alasan mengapa banyak single-page application modern yang dibangun di sekitar autentikasi berbasis token daripada berbasis cookie memiliki paparan CSRF bawaan yang jauh lebih rendah — meskipun ini adalah properti yang muncul secara khusus dari arsitektur autentikasi yang dipilih, bukan konsekuensi otomatis dari sekadar menjadi aplikasi modern yang digerakkan oleh JavaScript.

Pola Token Sinkronisasi

Pertahanan CSRF yang paling mapan dan paling banyak digunakan adalah pola token sinkronisasi, yang umumnya disingkat menjadi token CSRF atau token anti-CSRF.

Ide intinya adalah bahwa server menghasilkan token unik, tidak terduga, dan acak secara kriptografis, lalu menyematkannya di setiap halaman yang berisi formulir yang mampu memicu tindakan sensitif yang mengubah status — biasanya sebagai bidang tersembunyi di dalam formulir itu sendiri. Ketika pengguna benar-benar mengirimkan formulir tersebut, token tersebut akan dikirim bersama dengan data formulir lainnya kembali ke server, yang kemudian memvalidasi token yang dikirimkan terhadap nilai yang awalnya dikeluarkan untuk sesi pengguna tertentu sebelum menyetujui untuk memproses permintaan tersebut. Karena penyerang yang membuat permintaan palsu dari halaman yang sepenuhnya terpisah dan dikendalikan penyerang tidak memiliki cara yang sah untuk mengetahui atau memprediksi nilai token apa yang terakhir kali dikeluarkan server untuk sesi korban tertentu, mereka tidak dapat membuat permintaan yang akan lolos pemeriksaan validasi ini — permintaan palsu tiba tanpa token yang valid, atau tanpa token sama sekali, dan server langsung menolaknya sebelum tindakan sensitif tersebut dieksekusi.

Inilah mengapa pola token sinkronisasi dianggap sangat efektif jika diimplementasikan dengan benar: pola ini secara langsung menjawab pertanyaan "apakah pengguna benar-benar bermaksud melakukan ini?" yang tidak dapat dijawab oleh otentikasi saja, dengan mensyaratkan bukti nilai yang hanya dapat diperoleh dengan benar-benar memuat halaman yang sah terlebih dahulu. Sebagian besar framework web modern — seperti Django, Ruby on Rails, Spring, ASP.NET, dan banyak lainnya — menyediakan perlindungan ini secara bawaan dan sebagian besar otomatis untuk formulir yang dirender server tradisional, menghasilkan dan memvalidasi token tanpa mengharuskan developer untuk membuat mekanisme tersebut sendiri, yang merupakan bagian penting mengapa CSRF berbasis formulir klasik menjadi jauh lebih jarang terjadi pada aplikasi yang dibangun dengan framework modern daripada satu dekade yang lalu.

Pola ini memang mengharuskan server untuk mempertahankan status — yaitu melacak nilai token mana yang paling baru dikeluarkan untuk sesi mana — yang justru merupakan keterbatasan yang ingin diatasi oleh pola cookie pengiriman ganda, yang akan dijelaskan selanjutnya, untuk arsitektur yang secara khusus ingin menghindari ketergantungan status di sisi server tersebut.

Cookie Pengiriman Ganda: Alternatif Tanpa Status

Untuk aplikasi yang dibangun di sekitar arsitektur tanpa status — yang umumnya terjadi pada banyak aplikasi berbasis API dan single-page application modern, di mana server sengaja menghindari pemeliharaan status sesi sisi server karena alasan skalabilitas — pola cookie pengiriman ganda menyediakan pertahanan CSRF yang mencapai perlindungan yang secara luas serupa tanpa mengharuskan server untuk melacak dan menyimpan token yang diterbitkan di sisi servernya sendiri.

Mekanisme ini bekerja dengan cara server menghasilkan token acak dan mengirimkannya ke klien dua kali, melalui dua saluran yang benar-benar berbeda, yaitu sekali ditetapkan sebagai cookie, dan sekali disematkan di suatu tempat yang dapat dibaca oleh JavaScript sisi klien dan kemudian dilampirkan ke permintaan keluar — biasanya sebagai header permintaan khusus. Ketika klien membuat permintaan yang mengubah status, klien menyertakan token tersebut secara otomatis, melalui cookie yang dilampirkan oleh browser, dan secara sengaja, melalui nilai header yang secara eksplisit ditetapkan oleh JavaScript aplikasi. Server kemudian hanya memeriksa bahwa kedua nilai yang ditransmisikan secara independen ini cocok, tanpa perlu menyimpan apa pun secara terpisah; Ketidakcocokan, atau ketiadaan nilai yang dikirim melalui header, menunjukkan bahwa permintaan tersebut tidak berasal dari JavaScript aplikasi yang sah yang berjalan pada origin yang benar, karena permintaan palsu penyerang — yang tidak memiliki kemampuan untuk membaca nilai cookie karena pembatasan akses cookie dari JavaScript lintas origin pada browser — tidak dapat membuat nilai header yang cocok untuk menyertainya.

Implementasi modern dari pola ini biasanya mengatur cookie CSRF tanpa flag HttpOnly secara khusus agar JavaScript sisi klien aplikasi dapat membacanya dan mengembalikannya dalam header yang diperlukan — pengecualian yang disengaja terhadap praktik terbaik umum untuk menandai cookie dengan HttpOnly di mana pun memungkinkan, yang dibenarkan secara khusus karena pola ini bergantung pada kemampuan baca JavaScript tersebut untuk berfungsi, dan biasanya dipasangkan dengan pembatasan SameSite=Lax atau SameSite=Strict pada cookie yang sama sebagai lapisan perlindungan tambahan.

Atribut Cookie SameSite: Pertahanan Browser Sendiri

Jika pola token sinkronisasi dan cookie pengiriman ganda adalah pertahanan yang harus diimplementasikan secara sengaja oleh developer dalam kode aplikasi mereka sendiri, atribut cookie SameSite mewakili kategori perlindungan yang sangat berbeda, yaitu mekanisme keamanan tingkat browser, yang dibangun langsung ke dalam cara kerja cookie itu sendiri, yang tidak memerlukan logika aplikasi khusus untuk diaktifkan sama sekali — hanya satu atribut yang ditambahkan ke cara cookie diatur.

SameSite mengatur secara tepat kapan browser akan menyertakan cookie tertentu dalam permintaan yang berasal dari situs yang berbeda dari situs tempat cookie tersebut berada, dan mendukung tiga pengaturan berbeda yang menyeimbangkan keketatan keamanan dengan fungsionalitas lintas situs. Strict adalah pengaturan yang paling ketat, yaitu cookie yang ditandai SameSite=Strict hanya akan dikirim dengan permintaan yang benar-benar berasal dari situs yang sama dengan cookie tersebut, artinya cookie tersebut bahkan tidak akan dilampirkan ketika pengguna mengklik tautan yang sah dari situs eksternal langsung ke aplikasi — konfigurasi paling aman yang tersedia, sesuai untuk cookie sesi yang sangat sensitif yang melindungi operasi seperti perbankan, tetapi dapat menciptakan pengalaman pengguna yang benar-benar canggung dalam skenario di mana navigasi lintas situs yang sah ke area yang diautentikasi diharapkan. Lax, pengaturan tengah dan default yang diterapkan browser secara otomatis pada cookie yang tidak secara eksplisit menentukan nilai SameSite sejak Chrome mulai menerapkannya secara default pada tahun 2021, sehingga memungkinkan cookie dikirim dengan permintaan situs yang sama dan dengan navigasi lintas situs tingkat atas — artinya mengklik tautan biasa masih berfungsi seperti yang diharapkan — sambil tetap memblokir cookie agar tidak dilampirkan ke jenis permintaan tersemat non-navigasi (formulir yang dikirim otomatis dalam iframe tersembunyi, permintaan gambar latar belakang dan skrip) yang menjadi andalan serangan CSRF klasik. Opsi `None` menonaktifkan perlindungan ini sepenuhnya, mengirimkan cookie dengan setiap permintaan lintas situs tanpa memperhatikan konteks, dan secara khusus dikhususkan untuk sejumlah kecil kasus penggunaan lintas situs yang sah — seperti widget pihak ketiga tertentu yang benar-benar membutuhkannya, dan harus secara eksplisit dipasangkan dengan atribut `Secure` yang mewajibkan HTTPS setiap kali digunakan.

Karena perilaku `Lax` default yang sekarang diterapkan secara otomatis oleh browser modern sudah memblokir pola permintaan spesifik yang menjadi andalan sebagian besar serangan CSRF klasik, `SameSite` telah menjadi, secara praktis, pertahanan CSRF utama dan paling berdampak bagi sebagian besar aplikasi modern — sebuah perubahan signifikan dari satu dekade lalu, ketika token CSRF dianggap sebagai pertahanan dasar yang penting dan tidak dapat dinegosiasikan yang tidak dapat digantikan oleh mekanisme lain.

Mengapa SameSite Saja Tidak Cukup

Celah yang paling penting adalah cakupan browser dan keandalan konfigurasi, yaitu meskipun penegakan Lax-by-default Chrome sejak 2021 telah mendorong adopsi luas perlindungan dasar ini di seluruh ekosistem browser, sebuah aplikasi tidak dapat sepenuhnya mengontrol versi browser spesifik mana, vendor browser spesifik mana, atau konfigurasi spesifik mana yang sebenarnya dijalankan oleh setiap penggunanya, dan mengandalkan sepenuhnya pada default sisi klien yang tidak secara langsung diberlakukan atau diverifikasi oleh aplikasi itu sendiri meninggalkan celah residual untuk kasus-kasus khusus, perangkat lunak lama, dan konfigurasi klien non-standar yang akan ditutup dengan lebih andal oleh pertahanan sisi server.

Celah yang lebih signifikan secara teknis melibatkan apa yang oleh para peneliti keamanan digambarkan sebagai varian CSRF sisi klien, yaitu kategori serangan yang sangat penting justru karena dapat melewati beberapa tindakan pencegahan anti-CSRF yang paling umum, termasuk mitigasi berbasis token dan pembatasan cookie SameSite secara bersamaan. Masalah mendasarnya adalah ketika token sinkronisasi atau header khusus diimplementasikan, JavaScript sisi klien aplikasi itu sendiri, yang berjalan di dalam halaman yang sah, bertanggung jawab untuk membaca dan melampirkan nilai-nilai pelindung tersebut ke permintaan keluar — dan browser menyertakan cookie dalam konteks permintaan same-site yang diinisiasi oleh JavaScript tersebut terlepas dari kebijakan SameSite, karena permintaan tersebut secara teknis berasal dari skrip situs yang benar. Jika penyerang dapat memanipulasi perilaku JavaScript yang sah tersebut melalui kelemahan lain — skrip pihak ketiga yang rentan yang disertakan pada halaman, manipulasi berbasis DOM, atau kerentanan yang berdekatan di tempat lain dalam kode sisi klien — mereka berpotensi menyebabkan skrip aplikasi yang sah tersebut membuat dan mengirimkan permintaan palsu dari dalam asal yang benar, sehingga melewati validasi token dan batasan SameSite sekaligus, karena permintaan tersebut benar-benar berasal dari situs yang sama dari perspektif browser.

Inilah mengapa panduan OWASP saat ini menganggap SameSite sebagai lapisan mitigasi yang penting dan sangat efektif, bukan sebagai pertahanan yang cukup dengan sendirinya, dan secara konsisten merekomendasikan penerapan setidaknya satu mitigasi tambahan dari strategi pertahanan berlapis yang lebih luas di sampingnya, daripada mengandalkan satu mekanisme tunggal — termasuk SameSite — secara terpisah.

Request Header Kustom dan Fetch Metadata

Khusus untuk aplikasi berbasis API, mewajibkan header permintaan kustom pada setiap permintaan yang mengubah status memberikan pertahanan yang bekerja melalui mekanisme yang benar-benar berbeda dari perlindungan berbasis cookie, dan sangat cocok untuk aplikasi yang sama sekali tidak dapat mengandalkan pengiriman formulir HTML tradisional.

Logikanya bergantung pada batasan browser tertentu, yaitu meskipun browser akan secara otomatis melampirkan cookie ke permintaan lintas asal secara default (tergantung pada kebijakan SameSite), mereka tidak akan secara otomatis melampirkan header kustom sembarangan ke permintaan lintas asal yang dimulai dari JavaScript situs yang berbeda — dan lebih spesifiknya, halaman berbahaya penyerang, yang berjalan di asal yang berbeda, sama sekali tidak dapat mengatur header kustom pada pengiriman formulir lintas asal, dan setiap upaya untuk melakukannya melalui API fetch atau XMLHttpRequest JavaScript akan memicu mekanisme pra-penerbangan Cross-Origin Resource Sharing browser, yang dapat ditolak oleh server target. Dengan mewajibkan setiap permintaan perubahan status yang sah untuk menyertakan header khusus tertentu — biasanya sesuatu yang sederhana seperti X-Requested-With: XMLHttpRequest, meskipun nama header khusus CSRF lebih disukai — dan menolak setiap permintaan yang tidak memilikinya, sebuah aplikasi dapat secara andal membedakan permintaan yang diinisiasi JavaScript asli dari asal yang sama dari upaya pemalsuan lintas asal, karena serangan CSRF berbasis formulir klasik sama sekali tidak memiliki mekanisme untuk melampirkan header khusus ke pengajuan palsunya.

Mekanisme pelengkap yang lebih baru dan semakin direkomendasikan adalah Fetch Metadata, serangkaian header permintaan — seperti Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-Dest, dan header terkait — yang sekarang secara otomatis dilampirkan oleh browser modern ke setiap permintaan, yang menjelaskan konteks sebenarnya dari mana permintaan tersebut berasal: apakah berasal dari situs yang sama, situs yang berbeda, atau diketik langsung oleh pengguna, dan jenis sumber daya apa yang dimintanya. Pedoman OWASP saat ini mencatat bahwa untuk aplikasi yang hanya menargetkan browser modern yang mendukung Fetch Metadata, header ini dapat diandalkan bersama dengan perlindungan cadangan untuk memblokir permintaan perubahan status lintas situs secara andal, sehingga menawarkan developer sisi server sinyal yang benar-benar andal tentang asal permintaan tanpa memerlukan pembuatan token atau logika validasi sama sekali — pertahanan dengan biaya operasional yang jauh lebih rendah bagi tim yang membangun aplikasi khusus untuk lingkungan browser saat ini.

Jadi, Cross-Site Request Forgery (CSRF) tetap menjadi perhatian keamanan web yang signifikan justru karena serangan ini tidak menyerang kelemahan spesifik apa pun dalam sistem otentikasi aplikasi target — serangan ini mengeksploitasi perilaku biasa, yang diharapkan, dan sepenuhnya sesuai desain tentang bagaimana browser menangani cookie, mengubah bagian arsitektur web yang mendasar dan benar-benar berguna menjadi vektor serangan setiap kali aplikasi gagal memverifikasi secara terpisah bahwa permintaan tersebut mencerminkan niat pengguna yang sebenarnya dan disengaja, bukan hanya sekadar datang dengan kredensial yang valid.