Fetch Metadata Menambahkan Konteks Request ke Kebijakan Server

Server sering menerima cookie autentikasi yang sama dari request yang dibuat melalui aksi browser yang sangat berbeda. Form dari situs lain, panggilan API same-origin, pemuatan gambar, dan navigasi tingkat atas dapat menuju host yang sama. Cookie saja tidak menjelaskan konteks request tersebut.

Fetch Metadata menambahkan header request buatan browser yang menjelaskan asal request dan cara browser akan memakai response. Server dapat memasukkan sinyal tersebut ke kebijakan isolasi sebelum logika aplikasi menangani route sensitif.

Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: no-cors
Sec-Fetch-Dest: image

Header ini tidak memberikan otorisasi kepada principal. Fungsinya adalah menyediakan konteks bagi keputusan server yang terpisah.

Empat header inti membawa dimensi yang berbeda

Header request Fetch Metadata terdiri dari Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-Dest, dan Sec-Fetch-User.

Sec-Fetch-Site menjelaskan hubungan antara initiator dan target. Nilai yang umum adalah same-origin, same-site, cross-site, dan none. Nilai none mencakup request tanpa situs peminta, seperti beberapa navigasi langsung oleh pengguna.

Sec-Fetch-Mode melaporkan mode request, termasuk nilai seperti navigate, cors, no-cors, same-origin, dan websocket.

Sec-Fetch-Dest menjelaskan tujuan penggunaan response. Nilai seperti document, image, script, dan empty membantu server membedakan navigasi dokumen dari subresource atau fetch bergaya API.

Sec-Fetch-User hadir dengan nilai ?1 ketika navigasi berkaitan dengan aktivasi pengguna. Ketiadaannya bukan tanda autentikasi gagal; sinyal itu hanya tidak hadir pada request tersebut.

Karena nama header memakai prefiks Sec-, script halaman browser tidak dapat bebas menetapkan atau mengubahnya seperti header request biasa.

Kebijakan dimulai dari tujuan endpoint

Kebijakan yang berguna mengikuti jenis traffic yang memang ditujukan untuk sebuah endpoint. Pertimbangkan route JSON terautentikasi yang hanya dipanggil kode aplikasi same-origin. Pemuatan gambar cross-site tidak memiliki alasan sah untuk menuju route itu, meskipun browser menyertakan cookie.

Aturan ringkas dapat menolak ketidakcocokan tersebut:

if Sec-Fetch-Site == cross-site
and route is not explicitly cross-site:
    reject

Aturan produksi biasanya memerlukan detail tambahan. Resource publik, callback login federasi, endpoint webhook, API CORS, dan link tingkat atas dapat secara sengaja menerima traffic dari luar situs. Penolakan menyeluruh terhadap semua request cross-site akan merusak alur yang valid.

Karena itu, kebijakan sebaiknya berdampingan dengan inventaris endpoint, bukan sekadar menjadi sakelar middleware terpisah.

Same-site tidak selalu berarti batas kepercayaan yang sama

same-site lebih luas daripada same-origin. Dua subdomain saudara dapat termasuk same-site meski menjalankan software dengan operator, kontrol deployment, atau paparan yang berbeda.

Aplikasi yang mempercayai setiap request same-site secara efektif menempatkan origin saudara tersebut dalam satu batas kepercayaan browser. Pilihan ini dapat tepat untuk infrastruktur yang dikendalikan ketat, tetapi harus dibuat secara sengaja.

Untuk route sensitif, mengizinkan same-origin dan menilai same-site secara terpisah menghasilkan default yang lebih sempit.

Navigasi memerlukan aturan tersendiri

Navigasi cross-site adalah perilaku web yang normal. Pengguna dapat mengeklik link di satu situs dan tiba di situs lain. Kebijakan yang menolak seluruh request cross-site akan memblokir jalur dasar ini.

Untuk route yang memang menyajikan halaman, kebijakan dapat membedakan navigasi tingkat atas dari request subresource dengan menggabungkan beberapa field metadata. Sebagai contoh, request GET dengan Sec-Fetch-Mode: navigate dan Sec-Fetch-Dest: document memiliki tujuan berbeda dari request gambar no-cors ke URL yang sama.

Pemeriksaan method tetap penting. Menganggap setiap navigasi aman menjadi kesalahan bila aplikasi melakukan perubahan state melalui GET. Semantik HTTP yang aman tetap menjadi bagian dari batas tersebut.

Header yang tidak hadir memerlukan pilihan kompatibilitas

Tidak setiap client adalah browser yang mengirim Fetch Metadata. Client command-line, integrasi server-to-server, client lama, dan user agent khusus dapat tidak menyertakan header ini.

Deployment harus menetapkan arti dari ketiadaan tersebut. Satu layanan dapat mengizinkan metadata yang tidak hadir hanya pada endpoint mesin yang terdokumentasi. Layanan lain dapat mengizinkannya sementara selama mengukur cakupan browser. Route browser berisiko tinggi dapat memilih fallback yang lebih ketat.

Sifat pentingnya adalah penanganan yang disengaja. Menganggap header yang tidak hadir sebagai same-origin mengubah fallback kompatibilitas menjadi pemberian kepercayaan.

Fetch Metadata melengkapi kontrol CSRF

Fetch Metadata dapat menolak banyak request ketika konteks browser bertentangan dengan penggunaan endpoint, termasuk request cross-site dalam pola CSRF. Mekanisme ini bukan pengganti semua kontrol CSRF.

Aplikasi masih dapat memerlukan pengaturan cookie SameSite, token anti-CSRF, validasi Origin atau Referer, autentikasi ulang untuk aksi sensitif, serta otorisasi yang benar. Kombinasi tepatnya bergantung pada model request.

Fetch Metadata berguna sebagai gerbang server tambahan karena keputusan dapat dibuat sebelum parsing body berukuran besar atau pemanggilan logika aplikasi sensitif.

Perilaku cache harus sesuai dengan kebijakan

Jika response dapat berbeda berdasarkan metadata request dan terdapat shared cache di depan aplikasi, perilaku cache perlu ditinjau. Cache yang mengabaikan header request relevan dapat memakai ulang response dalam konteks yang seharusnya diperlakukan berbeda oleh origin server.

Ketika response bervariasi berdasarkan Fetch Metadata, cache key atau perilaku Vary harus sesuai dengan arsitektur deployment. Ini bukan alasan untuk menambahkan setiap header metadata ke setiap response. Konfigurasi cache cukup diselaraskan dengan field yang benar-benar memengaruhi pemilihan response.

Rollout lebih aman dimulai dengan observasi

Aturan isolasi baru dapat menampakkan integrasi yang sebelumnya tersembunyi. Sebelum penolakan diberlakukan, catat tuple metadata, route, method, keputusan, dan konteks diagnostik dalam batas yang wajar. Jangan mencatat secret sesi atau kredensial otorisasi lengkap.

Masa observasi dapat menunjukkan endpoint yang secara sah menerima navigasi cross-site, traffic CORS, resource tertanam, atau client non-browser. Pengecualian tersebut kemudian dapat dibuat eksplisit.

Setelah enforcement dimulai, request yang ditolak tetap perlu dapat diamati. Kenaikan penolakan secara tiba-tiba dapat menandakan pola serangan, regresi client, atau inventaris route yang belum lengkap; status code saja tidak dapat membedakannya.

Konteks request adalah gerbang, bukan identitas

Fetch Metadata memberi server konteks buatan browser mengenai sebuah request. Mekanisme ini tidak membuktikan pengguna mana yang berhak atas suatu object, apakah sesi masih valid, atau apakah transisi state diizinkan.

Pemisahan itu menjaga fungsi kontrol tetap presisi. Autentikasi menetapkan identitas. Otorisasi mengatur akses. Pertahanan CSRF melindungi request browser yang mengubah state. Fetch Metadata memungkinkan server menolak konteks browser yang semestinya tidak pernah mencapai route tertentu.

Deployment yang kuat memisahkan peran tersebut, mendokumentasikan jalur cross-site yang memang disengaja, memperlakukan same-site sebagai keputusan kepercayaan yang sadar, dan menetapkan fallback aman bagi client yang tidak mengirim header.