Fetch Metadata Headers: Cara Membatasi Request Lintas Situs untuk Mengurangi Risiko CSRF

Serangan Cross-Site Request Forgery (CSRF) memanfaatkan keadaan ketika browser sudah menyimpan sesi pengguna, lalu tanpa disadari mengirim permintaan ke situs yang dipercaya pengguna. Token CSRF dan cookie SameSite tetap penting, tetapi pengembang juga dapat memeriksa konteks asal permintaan melalui Fetch Metadata Headers. Header ini dikirim browser modern untuk menjelaskan hubungan antara halaman pemicu dan tujuan request.

Dengan aturan yang dirancang hati-hati, server dapat menolak permintaan lintas situs yang mencoba mengubah data, sembari tetap mengizinkan navigasi dan integrasi yang memang dibutuhkan. Mekanisme ini bukan pengganti autentikasi atau token CSRF; fungsinya adalah menambah satu lapisan pertahanan yang relatif mudah diaudit.

Apa Itu Fetch Metadata Headers?

Fetch Metadata adalah sekumpulan header HTTP berawalan Sec-Fetch- yang memberi tahu server konteks sebuah permintaan browser. Header ini bukan identitas pengguna dan tidak membuktikan bahwa suatu tindakan sah. Nilainya membantu server membedakan permintaan dari halaman dalam situs yang sama dengan permintaan yang dipicu situs asing.

• Sec-Fetch-Site menjelaskan hubungan situs asal dan tujuan: same-origin, same-site, cross-site, atau none.
• Sec-Fetch-Mode menjelaskan mode pengambilan, misalnya navigate, cors, no-cors, atau same-origin.
• Sec-Fetch-Dest menunjukkan tujuan seperti document, image, script, atau empty pada banyak permintaan fetch.
• Sec-Fetch-User biasanya bernilai ?1 pada navigasi yang dipicu aktivasi pengguna; header ini tidak hadir pada setiap request.

Memahami Nilai Sec-Fetch-Site

Nilai same-origin menunjukkan permintaan berasal dari origin yang sama, termasuk skema, host, dan port yang cocok. Same-site berarti masih berada dalam konteks situs yang sama meskipun origin dapat berbeda, misalnya dua subdomain yang dikelola organisasi yang sama. Cross-site menunjukkan asal dari situs berbeda, sedangkan none lazim ditemukan pada navigasi yang dimulai pengguna seperti membuka alamat atau bookmark.

Perbedaan site dan origin penting untuk mencegah aturan yang terlalu longgar atau terlalu ketat. Sebuah subdomain yang masih satu site belum tentu memiliki tingkat kepercayaan yang sama. Evaluasi struktur domain, pengelolaan subdomain, serta endpoint yang menerima cookie sebelum menentukan kebijakan.

Bagaimana Header Ini Membantu Mengurangi CSRF?

CSRF biasanya menargetkan endpoint yang mengubah keadaan akun, seperti mengganti alamat email, memperbarui profil, atau membuat transaksi. Jika endpoint menerima cookie sesi secara otomatis, browser bisa menyertakan cookie itu pada request yang dipicu halaman asing sesuai kebijakan cookie dan browser. Pemeriksaan Fetch Metadata memberi server sinyal tambahan untuk menolak request lintas situs yang tidak semestinya.

Aturan awal yang praktis adalah memisahkan metode aman dan metode yang mengubah data. GET, HEAD, dan OPTIONS seharusnya tidak mengubah keadaan aplikasi. Untuk POST, PUT, PATCH, dan DELETE, request berlabel cross-site dapat ditolak secara default, kecuali endpoint tertentu memang membutuhkan alur lintas situs yang telah ditinjau. Endpoint yang mengubah data tidak seharusnya memakai GET hanya demi kemudahan.

Merancang Kebijakan Server

Mulailah dengan aturan sederhana: untuk endpoint yang menggunakan sesi browser, tolak permintaan cross-site yang mengubah data kecuali terdapat alasan bisnis yang sah dan terdokumentasi. Jangan membuat daftar pengecualian yang luas seperti mengizinkan seluruh subdomain tanpa peninjauan. Pengecualian sebaiknya menunjuk endpoint tertentu, menjelaskan integrasi yang membutuhkan akses, dan diuji setiap kali alurnya berubah.

Aturan ini harus dilengkapi token CSRF yang divalidasi di server, cookie sesi dengan atribut SameSite yang sesuai, autentikasi, otorisasi, serta validasi input. Header konteks tidak memberi izin kepada pengguna dan tidak membuktikan bahwa isi permintaan aman. Setiap tindakan tetap harus memeriksa apakah pengguna berhak melakukan operasi tersebut.

Strategi Penerapan Tanpa Memutus Fitur

1. Mulai dari pencatatan. Catat nilai Sec-Fetch-Site, metode, dan endpoint pada lingkungan pengujian. Hindari mencatat cookie, token, atau data pribadi.
2. Petakan endpoint sensitif. Identifikasi operasi yang mengubah data, lalu pastikan operasi tersebut tidak menggunakan GET.
3. Uji alur penting. Cakup login, logout, formulir, pembayaran, unggahan, callback OAuth, dan integrasi pihak ketiga. Uji dari beberapa browser serta klien API non-browser.
4. Aktifkan bertahap. Terapkan lebih dahulu pada endpoint sensitif, pantau respons penolakan, lalu perluas cakupan setelah pengecualian tervalidasi.

Integrasi pembayaran, login federasi, unggahan lintas origin, atau API publik mungkin memiliki kebutuhan berbeda. Jangan memblokir semuanya tanpa memahami alur bisnis. Jika suatu callback memang harus datang dari luar situs, validasi tanda tangan, state, nonce, atau mekanisme protokol yang sesuai daripada hanya mengandalkan header konteks.

Batasan dan Kesalahan yang Perlu Dihindari

Header berawalan Sec- dirancang agar JavaScript halaman di browser tidak dapat mengubahnya sesuka hati. Namun, klien non-browser dapat mengirim header buatan sendiri, sementara browser lama mungkin tidak mengirimnya. Jika header tidak ada, jangan otomatis menganggap request aman. Terapkan kontrol yang sesuai dengan jenis klien dan jangan gunakan Fetch Metadata sebagai pengganti autentikasi atau pembatasan akses.

Fetch Metadata juga bukan pengganti token CSRF, autentikasi, otorisasi, atau pemeriksaan origin yang sesuai. Gunakan beberapa lapisan perlindungan dan uji alur aplikasi yang sah, termasuk login, pembayaran, unggahan, dan integrasi pihak ketiga.

Checklist penerapan

• Catat header Fetch Metadata pada request penting.
• Mulai dari pemantauan sebelum memblokir request.
• Terapkan aturan berbeda untuk navigasi, API, webhook, dan klien non-browser.
• Siapkan fallback untuk browser yang tidak mengirim header tersebut.

Kesimpulan

Fetch Metadata membantu server mengenali konteks request dan mengurangi risiko CSRF atau pemuatan lintas situs yang tidak diinginkan. Gunakan sebagai lapisan tambahan, tetapkan kebijakan berdasarkan jenis endpoint, dan pertahankan token CSRF serta pemeriksaan akses yang diperlukan aplikasi.