Header Fetch Metadata Menyaring Request Cross-Site

Server web sering menerima request yang tampak valid pada lapisan HTTP meski berasal dari situs yang tidak berkaitan. Cookie dapat ikut terkirim, dan endpoint yang mengubah state dapat terekspos jika pertahanannya memperlakukan setiap request browser dengan tingkat kepercayaan yang sama.

Fetch Metadata memberi server konteks tambahan. Browser yang mendukung mekanisme ini memasang header request Sec-Fetch-* yang menjelaskan hubungan antara initiator dan target, mode request, destination, serta apakah navigasi berasal dari aktivasi langsung pengguna. Server dapat memakai konteks tersebut sebagai gerbang awal untuk isolasi resource.

Header ini tidak menggantikan authentication, authorization, token CSRF, atau policy CORS yang cermat. Perannya lebih sempit: aplikasi dapat menolak kelas request cross-site yang memang tidak memiliki fungsi sah dalam model traffic-nya.

Sec-Fetch-Site menjelaskan hubungan request

Sec-Fetch-Site biasanya menjadi sinyal utama dalam policy isolasi resource. Nilainya membedakan request dengan initiator same-origin, same-site, atau cross-site. Nilai none mencakup request yang tidak dipicu origin lain, termasuk sebagian navigasi yang dimulai pengguna.

Perbedaan ini penting karena origin dan site merupakan batas yang berbeda. Dua origin dapat tergolong same-site meski scheme, host, atau port berbeda sesuai perhitungan site oleh browser. Aplikasi yang memerlukan batas setingkat origin tidak boleh begitu saja menyamakan same-site dengan same-origin.

Policy konservatif untuk endpoint sensitif dapat menolak request cross-site sebelum routing mencapai business logic. Aplikasi yang sengaja menerima traffic cross-site memerlukan pengecualian eksplisit, bukan aturan longgar untuk seluruh aplikasi.

Mode dan destination menambah konteks

Sec-Fetch-Mode mencerminkan mode request, dengan nilai seperti navigate, cors, no-cors, dan same-origin. Sec-Fetch-Dest menunjukkan destination yang dituju, misalnya document, image, script, atau empty.

Sinyal tersebut membuat policy lebih presisi. Situs dapat mengizinkan navigasi top-level menuju halaman HTML publik sambil menolak hubungan cross-site yang sama pada endpoint API. Host gambar dapat menerima request gambar cross-site secara sah tetapi tidak memiliki alasan untuk menerima request cross-site menuju route administratif.

Sec-Fetch-User dapat muncul pada request navigasi yang diaktifkan pengguna. Header ini bukan bukti umum tentang niat manusia dan tidak layak dijadikan sinyal authentication. Fungsinya hanya menambahkan fakta lain yang diberikan browser untuk evaluasi policy.

Aturan penolakan memerlukan pengecualian eksplisit

Pola server-side yang sederhana adalah menolak request dengan Sec-Fetch-Site: cross-site kecuali target termasuk surface yang memang menerima akses cross-site. Implementasi persisnya bergantung pada routing dan arsitektur deployment, tetapi keputusan tersebut sebaiknya berada dekat tahap awal pemrosesan request.

request masuk
      |
baca Sec-Fetch-Site
      |
      +-- cross-site --> pengecualian sah? -- tidak --> tolak
      |                                      |
      |                                      ya
      |                                      |
      +--------------------------------------+
      |
lanjutkan authentication,
authorization, CSRF, dan pemeriksaan aplikasi

Pengecualian perlu ditinjau seperti aturan firewall. Webhook, pengiriman asset publik, callback login federasi, redirect pembayaran, dan resource embedded dapat memiliki jalur cross-site yang sah. Pengecualian luas seperti mengizinkan semua GET atau seluruh route di bawah prefix besar dapat menghapus banyak manfaat isolasi.

Method saja bukan batas keamanan lengkap. Sebagian aplikasi masih memiliki handler GET yang mengubah state, sementara perilaku navigasi browser berbeda dari request subresource. Policy resource harus mengikuti semantik endpoint yang sebenarnya.

Header yang tidak ada memerlukan policy kompatibilitas

Fetch Metadata merupakan konteks yang dibuat browser, bukan properti universal semua client HTTP. Client non-browser, client lama, intermediary, test, atau automation dapat mengirim request tanpa header tersebut.

Deployment perlu menetapkan aturan eksplisit untuk kondisi ini. Endpoint publik dapat mempertahankan kompatibilitas ketika metadata tidak tersedia, sedangkan surface administratif yang hanya ditujukan untuk browser dapat menerapkan sikap lebih ketat setelah cakupan client terkonfirmasi. Menganggap ketiadaan metadata selalu berbahaya dapat merusak client sah; menyamakannya dengan request same-origin tepercaya dapat menciptakan bypass yang tidak disengaja.

Telemetry sebelum enforcement berguna untuk rollout. Logging nilai metadata, kelas route, dan keputusan dapat menunjukkan traffic sah yang memerlukan pengecualian sempit. Log tidak perlu mengumpulkan credential atau body request sensitif hanya untuk mendukung policy ini.

Browser mengendalikan namespace header

Prefix Sec- disediakan untuk header yang tidak dapat diatur secara bebas oleh script melalui Fetch API. Sifat ini membuat Fetch Metadata lebih berguna daripada custom header yang nilainya dapat dibuat sendiri oleh script halaman biasa.

Meski begitu, header tersebut bukan credential identitas. Client HTTP non-browser dapat membentuk field header secara langsung, dan origin tepercaya yang sudah disusupi dapat memulai request dari konteks yang memenuhi pemeriksaan hubungan oleh browser. Server tetap harus mengautentikasi caller dan mengotorisasi operasi yang diminta.

Policy ini paling kuat terhadap kelas request cross-site yang dimediasi browser, bukan terhadap penyerang yang sudah memiliki credential valid atau mengendalikan origin yang diizinkan.

Gabungkan policy dengan pertahanan web yang sudah ada

Untuk perubahan state dengan authentication berbasis cookie, token CSRF atau pertahanan setara yang terikat pada request tetap penting. Atribut cookie SameSite dapat mengurangi pengiriman credential ambient dalam konteks cross-site. CORS mengendalikan response cross-origin yang dapat dibaca script browser dan, untuk sebagian request, menambahkan preflight. Tidak satu pun mekanisme tersebut identik dengan penyaringan Fetch Metadata.

Pemakaian bersama menghasilkan pemeriksaan berbeda pada tahap yang berbeda. Cookie membatasi pengiriman credential, pertahanan CSRF mengikat tindakan sensitif ke state request yang diharapkan, CORS mengatur akses script cross-origin, dan Fetch Metadata memasok konteks request untuk penolakan awal.

Deployment yang baik menjaga aturan isolasi resource tetap cukup kecil untuk diaudit. Mulai dari route yang jelas memerlukan same-origin atau same-site, catat entry point cross-site yang memang diperlukan, lalu pertahankan authentication dan authorization secara independen dari keputusan metadata. Dengan struktur itu, Fetch Metadata menjadi batas konteks browser yang sempit, bukan pengganti model keamanan inti aplikasi.