Fetch Metadata Mengekspos Konteks Request Browser di Batas Server

Endpoint yang mengubah state dapat menerima dua HTTP request dengan method, path, cookie, dan body yang sama walaupun browser mencapainya melalui konteks yang sangat berbeda. Satu request mungkin berasal dari document milik aplikasi sendiri. Request lain mungkin dipicu foreign site melalui form, image load, navigation, atau mekanisme browser lain yang mengizinkan request tanpa memberi initiating page akses ke response.

Authentication saja tidak memisahkan kedua kasus tersebut. Ambient credential dapat ikut terkirim sesuai aturan cookie dan credential, sedangkan server biasanya baru melihat HTTP message setelah browser membuat keputusan kontekstualnya. Fetch Metadata menambahkan request header yang dibuat browser untuk membawa fakta terpilih mengenai konteks tersebut ke policy boundary server.

Mekanisme ini sengaja lebih sempit daripada caller authentication. Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-Dest, dan Sec-Fetch-User mendeskripsikan properti sebuah fetch. Header tersebut dapat membantu menolak kelas request yang tidak pernah diharapkan aplikasi, terutama cross-site traffic menuju endpoint sensitif. Mereka tidak membuktikan script mana yang menyebabkan request, tidak menggantikan authorization, dan tidak membuat setiap request yang memiliki header tersebut menjadi aman.

Relasi site menjadi request signal yang eksplisit

Sec-Fetch-Site melaporkan hubungan antara request initiator dan target memakai nilai seperti same-origin, same-site, cross-site, dan none. Nilai ini memberi server informasi yang jika tidak tersedia harus disimpulkan dari sinyal yang kurang langsung.

Perbedaan same-origin dan same-site penting bagi keamanan. Sibling origin dapat tetap berada dalam klasifikasi site yang sama. Policy yang menerima semua request same-site berarti mempercayai namespace yang lebih luas dibanding policy yang terbatas pada same-origin. Hal ini mungkin sesuai untuk domain yang dikendalikan ketat, tetapi buruk jika sibling host didelegasikan ke team, tenant, vendor, atau legacy system yang berbeda.

cross-site menandai request yang initiating context-nya berada di luar site target. Untuk endpoint yang seharusnya tidak pernah dicapai dari foreign site, klasifikasi ini dapat mendukung keputusan deny lebih awal sebelum parsing request atau business logic berjalan.

none mencakup request yang tidak diasosiasikan dengan origin lain dengan cara biasa, termasuk action tertentu yang dimulai user. Nilai ini tidak boleh dianggap sama dengan same-origin. Server yang perlu menerima top-level user navigation dapat menangani none secara eksplisit daripada memasukkannya ke trusted bucket umum.

Mode dan destination mempersempit browser path yang diharapkan

Relasi site saja sering terlalu kasar. Public image endpoint secara sah menerima cross-site image request, sedangkan account mutation endpoint biasanya tidak punya alasan untuk berperilaku sebagai image, frame, atau script resource. Fetch Metadata mengekspos perbedaan ini melalui header tambahan.

Sec-Fetch-Mode mencerminkan request mode. Nilainya dapat mencakup navigate, cors, no-cors, same-origin, dan websocket sesuai fetch processing yang berlaku. Server dapat menggunakan nilai tersebut untuk membedakan navigation dari subresource fetch atau API-style request ketika routing contract memang membedakannya.

Sec-Fetch-Dest mengidentifikasi request destination, dengan nilai yang mewakili konteks seperti document, image, script, style, dan empty destination untuk request yang tidak memiliki target category lebih spesifik. Field ini mendeskripsikan tujuan penggunaan response oleh browser, bukan actual media type response.

Bersama-sama, mode dan destination memungkinkan policy mengekspresikan architectural invariant. Endpoint yang dirancang hanya untuk same-origin API call tidak perlu menerima cross-site no-cors request dengan destination image. Menolak bentuk tersebut dapat menghapus browser-driven request path yang tidak memiliki peran sah di aplikasi.

Ini adalah request admission control, bukan content validation. Destination yang diizinkan tidak membuktikan body valid, principal memiliki authority, atau operation aman.

User activation adalah navigation signal yang sempit

Sec-Fetch-User memberi signal yang lebih spesifik. Bila hadir dengan nilai ?1, header ini menunjukkan navigation request dipicu user activation sesuai processing rule specification. Ini bukan pernyataan umum bahwa seorang manusia menyetujui application action yang dihasilkan.

Batasan tersebut penting untuk operasi sensitif. User dapat mengaktifkan link menuju halaman yang dikendalikan attacker, lalu halaman tersebut ikut terlibat dalam browser behavior berikutnya. User activation adalah transient browser state dengan propagation dan consumption rule yang terdefinisi; ia tidak sama dengan reauthentication, transaction confirmation, atau intent yang terikat ke operasi server-side tertentu.

Field ini paling berguna ketika server perlu membedakan bentuk navigation dan memiliki alasan eksplisit untuk mewajibkan user activation pada jalur tersebut. Memperlakukan Sec-Fetch-User: ?1 sebagai authorization token akan melampaui bukti yang sebenarnya dibawa header.

Prefix Sec- melindungi channel yang dibuat browser

Field Fetch Metadata memakai prefix Sec-. Dalam model Fetch, nama seperti ini dicadangkan dari kontrol script biasa melalui request-header API. Server dengan demikian mendapat channel yang diisi user agent, bukan arbitrary page JavaScript.

Properti ini memperkuat signal terhadap hostile web origin yang beroperasi melalui browser API. Foreign script tidak dapat sekadar memanggil fetch() lalu menetapkan nilai Sec-Fetch-Site pilihannya sebagai custom header biasa.

Boundary ini tidak meluas ke arbitrary HTTP client. Program command-line, bot, native application, compromised intermediary, atau attacker yang mengendalikan network stack sendiri dapat membentuk HTTP header secara langsung. Karena itu, server policy harus memperlakukan Fetch Metadata sebagai browser-context evidence, bukan cryptographic proof of provenance.

Perbedaan ini juga memengaruhi API ecosystem. Endpoint yang dipakai bersama oleh browser dan non-browser client tidak dapat secara membabi buta mewajibkan browser metadata tanpa memperhitungkan legitimate client yang tidak mengirimkannya. Compatibility policy harus mencerminkan client population sebenarnya.

Metadata yang hilang memerlukan policy branch eksplisit

Deployment tidak dapat mengasumsikan setiap request yang mencapai aplikasi berisi semua field Fetch Metadata. Dukungan client, non-browser traffic, intermediary, unusual request path, dan software lama dapat menghasilkan request tanpa metadata yang diharapkan.

Rollout yang aman membutuhkan outcome terdefinisi untuk kondisi tersebut. Satu service dapat menolak request tanpa metadata pada browser-only mutation endpoint. Service lain mungkin mempertahankan compatibility untuk API client yang sudah ada dan hanya menerapkan Fetch Metadata enforcement ketika client class diketahui browser-based. Branch yang benar mengikuti endpoint contract, bukan aturan universal.

Diam-diam menganggap metadata yang hilang sebagai trusted menghilangkan banyak nilai mekanisme ini jika hostile traffic dapat mencapai endpoint yang sama melalui client yang tidak mengeluarkan field tersebut. Sebaliknya, menolak semua request tanpa field dapat merusak legitimate automation atau native client. Tegangannya bersifat arsitektural: server harus mengetahui client class apa yang memang dimaksudkan memakai endpoint tersebut.

Proxy juga penting. Security policy harus bekerja pada header yang tiba melalui trusted HTTP path deployment. Jika edge component menghapus, menulis ulang, atau mensintesis field, aplikasi tidak lagi melihat browser signal secara langsung. Transformasi tersebut menjadi bagian trust boundary dan harus didokumentasikan.

Fetch Metadata melengkapi kontrol CSRF, bukan menggantikannya

Cross-site request forgery adalah use case penting karena Fetch Metadata dapat mengidentifikasi banyak request yang berasal dari foreign site sebelum application state berubah. Server dapat menolak bentuk cross-site request yang tidak punya fungsi sah, sehingga mengurangi ketergantungan pada application code untuk mengenali setiap browser trigger.

Mekanisme ini tetap memiliki semantics berbeda dari anti-forgery token. Token dapat mengikat request ke state yang dibuat aplikasi atau session-specific value. Fetch Metadata melaporkan browser context. Keduanya dapat menutup failure mode yang berbeda.

Hostile content pada same-site adalah contoh yang jelas. Jika sibling origin yang vulnerable atau delegated masih berada dalam site yang sama, policy yang mengizinkan traffic same-site akan menerima request dari sibling tersebut. Token yang tidak tersedia bagi sibling dapat mempertahankan application boundary yang lebih sempit. Sebagai alternatif, policy dapat hanya mengizinkan same-origin untuk endpoint jika legitimate traffic aplikasi memungkinkan pembatasan itu.

Fetch Metadata juga tidak memperbaiki server-side authorization defect. Jika authenticated principal diperbolehkan meminta object milik principal lain karena object-level check hilang, same-origin request yang sepenuhnya sah masih dapat mengeksploitasi defect tersebut. Context filtering dan authorization menjawab pertanyaan berbeda.

CORS dan Fetch Metadata mengatur keputusan yang berbeda

CORS sering dibahas berdekatan dengan Fetch Metadata, tetapi kedua mekanisme menjawab pertanyaan policy yang berbeda.

CORS mengontrol apakah script di satu origin dapat mengakses cross-origin response melalui protocol CORS browser. Ia dapat melibatkan preflight dan response header yang memberi akses kepada requesting origin. CORS bukan universal server-side request rejection system: sebagian cross-origin request dapat tetap dikirim walaupun script tidak boleh membaca response.

Fetch Metadata memberi request context yang dapat digunakan server sebelum memutuskan apakah request akan dilayani. Server dapat menolak cross-site request berdasarkan Sec-Fetch-Site bahkan jika CORS tidak akan pernah mengekspos response body. Ini berguna bila concern keamanannya adalah side effect dari pemrosesan request, bukan disclosure response.

Sebaliknya juga benar. Mengizinkan request melalui Fetch Metadata policy tidak memberi foreign script akses ke response. CORS processing tetap bertanggung jawab atas browser access decision tersebut bila CORS berlaku.

Nilai policy berasal dari endpoint contract yang sempit

Deployment terkuat memetakan metadata check ke perilaku endpoint konkret daripada menerapkan satu global rule yang samar. Static public asset, navigational document, cross-origin API, webhook receiver, dan same-origin mutation route memiliki legitimate request shape berbeda.

Public stylesheet dapat dengan sengaja menerima cross-site no-cors traffic dengan destination style. OAuth callback dapat secara sah menerima cross-site top-level navigation. Same-origin JSON mutation endpoint mungkin sama sekali tidak memiliki cross-site browser path yang valid. Memperlakukan semua route secara identik akan menimbulkan breakage yang tidak perlu atau membuat sensitive route lebih permisif daripada seharusnya.

Karena itu, Fetch Metadata paling berguna sebagai architectural filter: server membandingkan request context yang dinyatakan browser dengan peran route yang diharapkan. Mismatch dapat ditolak sebelum parsing mahal, session-sensitive business logic, atau state mutation.

Batasannya juga konkret. Header ini mendeskripsikan context yang diberikan participating user agent; ia tidak membawa authenticated application intent. Nilai keamanannya berasal dari kombinasi context tersebut dengan narrow route contract, authentication dan authorization yang sudah ada, anti-forgery control bila diperlukan, serta deployment model yang memperlakukan proxy handling dan metadata absence sebagai trust decision eksplisit.