Browser dapat mengirim request terautentikasi ke sebuah situs dari dokumen yang di-host di tempat lain. Cookie dapat menyertai request tersebut sesuai atribut cookie, sementara same-origin policy tetap dapat mencegah halaman pemicu membaca respons. Bagi server, perbedaan ini penting: pemblokiran akses terhadap respons tidak selalu menghentikan request lintas situs agar tidak mencapai endpoint.
Fetch Metadata menambahkan konteks request ke batas ini. User agent yang mendukung mekanisme tersebut memasang header request Sec-Fetch-* yang menjelaskan relasi serta properti request agar dapat dievaluasi server sebelum logika aplikasi menjalankan tindakan sensitif. Kebijakan dapat menolak request karena bersifat lintas situs, sekaligus mempertahankan alur navigasi atau resource publik tertentu.
Mekanisme ini berguna sebagai defense in depth, tetapi bukan sistem identitas dan tidak menggantikan otorisasi endpoint. Nilai keamanannya berasal dari penggunaan konteks request yang disediakan browser sebagai input tambahan bagi kebijakan server yang cakupannya ditetapkan secara sempit.
Sec-Fetch-Site menyatakan relasi situs
Sec-Fetch-Site mengklasifikasikan relasi antara pemicu request dan resource yang diminta. Nilainya mencakup same-origin, same-site, cross-site, dan none.
Kosakata tersebut membentuk batas enforcement yang berguna, tetapi same-site tidak boleh diperlakukan setara dengan same-origin. Origin terpisah di bawah situs yang sama dapat memiliki operator, stack deployment, atau paparan kompromi yang berbeda. Aplikasi yang tidak memercayai subdomain saudara dapat mengizinkan same-origin dan menolak same-site untuk route sensitif.
none memiliki semantik tersendiri. Nilai ini dapat muncul pada request yang tidak dipicu oleh situs lain, termasuk navigasi tertentu yang dipicu pengguna. Kebijakan yang langsung mengelompokkan none bersama trafik eksternal arbitrer dapat merusak jalur masuk yang sah. Sebaliknya, menerima setiap request none untuk setiap endpoint memberikan cakupan lebih luas dari yang diperlukan.
Dengan demikian, header ini menyediakan konteks, bukan keputusan lengkap. Endpoint tetap memerlukan kebijakan yang memetakan setiap nilai relevan ke operasi yang diizinkan.
Mode dan destination mempersempit permukaan pengecualian
Aturan menyeluruh yang menolak setiap request cross-site dapat bertentangan dengan perilaku web normal. Halaman publik umumnya menerima navigasi tingkat atas dari tautan situs eksternal. Sejumlah aset memang dirancang untuk disematkan di tempat lain. Sejumlah API sengaja mendukung pemanggil lintas origin.
Sec-Fetch-Mode dan Sec-Fetch-Dest memungkinkan server membedakan sebagian kasus tersebut. Navigasi tingkat atas lintas situs memiliki karakteristik berbeda dari image, script, object, atau API fetch. Kebijakan dapat mengizinkan kasus navigasi yang sempit sambil tetap menolak request subresource lintas situs menuju endpoint terlindungi.
Bentuk kebijakan yang disederhanakan dapat dinyatakan sebagai berikut:
if Sec-Fetch-Site == "same-origin":
allow
if Sec-Fetch-Site == "none" and request is an allowed navigation:
allow
if Sec-Fetch-Site == "cross-site":
if request is an explicitly allowed top-level navigation:
allow
reject
apply endpoint-specific rulesLogika produksi memerlukan detail lebih banyak daripada sketsa ini. Method HTTP, sensitivitas route, perilaku embedding yang dituju, kontrak API lintas origin, serta client yang tidak mengirim Fetch Metadata turut memengaruhi keputusan.
Sec-Fetch-Dest sangat berguna ketika pengecualian terikat pada destination browser. Mengizinkan navigasi dokumen tidak berarti URL yang sama harus dapat digunakan sebagai resource script atau object. Memisahkan kasus tersebut mengurangi kewenangan yang diberikan oleh sebuah pengecualian.
Header yang tidak ada memerlukan kebijakan kompatibilitas eksplisit
Fetch Metadata dibuat oleh user agent yang mendukungnya. Server juga dapat menerima request dari client lama, program command-line, aplikasi native, integrasi layanan, serta perangkat lunak HTTP lain yang tidak menyertakan header tersebut.
Ketiadaan header tidak dapat dianggap sebagai same-origin. Kondisi itu berarti server tidak memiliki sinyal konteks browser ini.
Deployment karena itu memerlukan aturan eksplisit untuk request tanpa Sec-Fetch-Site. Endpoint publik dapat menerimanya. Route administratif yang hanya ditujukan bagi browser dapat menerapkan kontrol tambahan. API dapat mengautentikasi client melalui mekanisme yang tidak berkaitan dengan konteks request browser.
Cabang kompatibilitas ini merupakan bagian dari model keamanan. Kebijakan ketat untuk request yang membawa header Sec-Fetch-* memberi manfaat terbatas jika operasi sensitif yang sama dapat dicapai melalui jalur tanpa header dengan kontrol lebih lemah.
Fetch Metadata dan kontrol CSRF melindungi properti berbeda
Fetch Metadata dapat menolak banyak request browser lintas situs sebelum logika aplikasi yang mengubah state dijalankan. Hal ini menjadikannya lapisan yang berguna terhadap pola cross-site request forgery, tetapi mekanisme ini dan pertahanan CSRF tradisional tidak membuktikan properti yang sama.
Token CSRF dapat mengikat request pengubah state dengan state aplikasi yang tidak dapat direproduksi situs eksternal. Atribut cookie seperti SameSite memengaruhi kapan cookie menyertai request. Pemeriksaan origin dapat membandingkan origin request yang dinyatakan dengan origin yang diharapkan. Fetch Metadata melaporkan konteks request browser melalui keluarga header standar.
Kontrol tersebut dapat dikombinasikan. Pada endpoint pengubah state bernilai tinggi, otorisasi tetap menentukan apakah principal terautentikasi boleh menjalankan tindakan. Mekanisme CSRF dapat memvalidasi intent request atau state yang terikat pada sesi. Fetch Metadata dapat menolak konteks lintas situs yang tidak sesuai lebih awal di jalur request.
Tidak ada satu lapisan yang seharusnya diam-diam memperluas kewenangan lapisan lain. Menerima same-site, misalnya, merupakan keputusan kebijakan deployment dan bukan bukti bahwa origin pemicu dapat dipercaya.
API lintas origin memerlukan pengecualian yang disengaja
Endpoint yang memang ditujukan untuk penggunaan lintas origin yang sah tidak dapat ditempatkan di balik aturan universal yang menolak semua request cross-site. API dengan CORS, resource yang dapat disematkan, alur federasi, dan endpoint callback dapat memerlukan pengecualian.
Unit pengecualian yang aman adalah route dan perilaku spesifik, bukan seluruh aplikasi. Path image publik dapat mengizinkan embedding lintas situs tanpa menyiratkan bahwa endpoint ekspor akun harus melakukan hal yang sama. Route callback dapat memerlukan navigasi eksternal sambil tetap menolak mode subresource lain yang tidak terkait.
CORS dan Fetch Metadata juga memiliki peran berbeda. CORS mengontrol apakah script browser dapat mengakses respons lintas origin berdasarkan aturannya; kebijakan Fetch Metadata menentukan apakah server akan memproses request berdasarkan konteks browser. Mengaktifkan CORS untuk sebuah route bukan alasan untuk menonaktifkan pemeriksaan kontekstual pada seluruh route di sekitarnya.
Proxy dan cache termasuk dalam jalur enforcement
Komponen yang mengevaluasi Fetch Metadata harus menerima header relevan secara utuh. Reverse proxy, gateway, dan framework aplikasi dapat menormalisasi nama header atau mengeksposnya melalui API yang berbeda. Kode kebijakan sebaiknya memakai mekanisme penanganan header yang didokumentasikan framework, bukan mengasumsikan representasi casing tertentu.
Caching juga memerlukan perhatian ketika respons dapat berbeda menurut Fetch Metadata. Jika shared cache dapat menyimpan respons yang bergantung pada kebijakan, cache key dan perilaku Vary harus sesuai dengan desain deployment. Mekanisme W3C mendefinisikan metadata request; mekanisme tersebut tidak otomatis mengonfigurasi cache perantara.
Enforcement sebaiknya terjadi sebelum pemrosesan mahal atau sensitif jika memungkinkan. Menolak request yang tidak sesuai hanya setelah perubahan state terjadi akan menghilangkan fungsi kontrol tersebut. Logging sebelum enforcement juga dapat mengungkap jalur lintas situs sah yang membutuhkan pengecualian dengan cakupan sempit.
Batasnya adalah konteks browser, bukan identitas pemanggil
Fetch Metadata paling kuat ketika aplikasi menetapkan invariant sederhana: route yang hanya ditujukan bagi penggunaan browser same-origin tidak boleh memproses request browser lintas situs yang tidak sesuai. Header tersebut memberi server konteks yang cukup untuk menegakkan invariant itu tanpa bergantung pada pembatasan pembacaan respons.
Batas ini tetap bersyarat. Client non-browser mungkin tidak membawa header, origin same-site mungkin tidak memiliki tingkat kepercayaan yang sama, dan endpoint yang sengaja bersifat lintas origin memerlukan perlakuan eksplisit. Autentikasi dan otorisasi tetap bertanggung jawab atas identitas principal serta izin.
Dengan batasan tersebut, Sec-Fetch-Site, Sec-Fetch-Mode, dan Sec-Fetch-Dest mengubah konteks request browser menjadi gerbang konkret di sisi server. Kebijakan yang dihasilkan paling andal ketika pengecualian bersifat spesifik per route, perilaku saat header tidak ada ditentukan secara sengaja, dan trafik same-site tidak diberi kepercayaan melebihi dukungan arsitektur deployment.