Header Fetch Metadata Membatasi Request Lintas Situs

Server web sering menerima informasi HTTP yang cukup untuk melakukan routing, tetapi tidak cukup untuk mengetahui konteks browser yang menghasilkan request tersebut. Sebuah GET dapat berupa navigasi top-level, pemuatan gambar, atau JavaScript fetch. Sebuah POST dapat berasal dari halaman aplikasi sendiri atau dari form yang ditempatkan di situs lain.

Fetch Metadata menambahkan header request yang dibuat browser untuk menjelaskan konteks tersebut. Sec-Fetch-Site menunjukkan hubungan antara initiator dan target, sedangkan Sec-Fetch-Mode, Sec-Fetch-Dest, dan pada kondisi tertentu Sec-Fetch-User menjelaskan mode request, destination, dan user activation. Server dapat memakai sinyal itu untuk menolak bentuk request yang memang tidak perlu diterima sebuah endpoint.

Header tersebut merupakan input policy, bukan sistem authorization. Fetch Metadata tidak mengidentifikasi user, memvalidasi token CSRF, atau dengan sendirinya membuat operasi sensitif menjadi aman.

Sec-Fetch-Site menandai hubungan antar-situs

Untuk banyak isolation policy, Sec-Fetch-Site menjadi sinyal pertama yang berguna. Nilai yang umum adalah:

same-origin
same-site
cross-site
none

same-origin berarti initiator dan target memakai origin yang sama. same-site mengizinkan origin berbeda di dalam site yang sama. cross-site menandai request yang dimulai dari site lain. none dipakai untuk request tanpa site initiator, termasuk sejumlah tindakan langsung dari user seperti mengetik URL atau membuka bookmark.

Perbedaan itu memungkinkan server menetapkan aturan yang sempit. Endpoint aplikasi yang mengubah state dan hanya ditujukan untuk origin sendiri dapat menolak request cross-site sebelum application logic menjalankan operasi.

Sec-Fetch-Site: same-origin  --> kandidat untuk pemrosesan normal
Sec-Fetch-Site: cross-site   --> tolak jika policy endpoint melarangnya

Same-site tidak sama dengan same-origin. Aplikasi yang menempatkan tenant yang tidak saling dipercaya atau konten yang dikendalikan user pada sibling subdomain tidak seharusnya otomatis menganggap setiap request same-site sebagai tepercaya. Policy harus mengikuti trust boundary yang sebenarnya.

Mode dan destination menambah bentuk request

Hubungan antar-situs saja belum menjelaskan apa yang sedang dilakukan browser. Sec-Fetch-Mode dan Sec-Fetch-Dest menambahkan konteks yang berguna.

Navigasi dokumen top-level umumnya membawa mode seperti navigate dan destination document. Pemuatan gambar memakai destination image. Request JavaScript fetch() umumnya memakai destination empty, sementara mode-nya ditentukan oleh konfigurasi fetch dan hubungan origin.

Konteks tersebut memungkinkan keputusan khusus per endpoint. Halaman publik dapat sengaja menerima navigasi top-level GET lintas situs, sementara endpoint JSON yang memerlukan autentikasi mungkin tidak memiliki alasan sah untuk dipakai sebagai image, script, atau resource no-CORS lintas situs.

Policy sederhana dapat berbentuk:

jika Sec-Fetch-Site adalah same-origin:
    izinkan pemrosesan normal

jika request adalah navigasi top-level yang aman:
    izinkan navigasi publik

selain itu:
    tolak

Aplikasi nyata memerlukan exception eksplisit untuk resource yang memang dirancang agar dapat di-embed, API lintas origin, webhook, alur federasi, dan entry point lain yang terdokumentasi. Aturan global yang disalin ke seluruh route dapat memutus traffic yang sah atau menghasilkan exception terlalu luas sehingga manfaat policy hilang.

Header yang dikendalikan browser mempersempit pemalsuan lintas situs

Header Fetch Metadata memakai prefix Sec- dan termasuk forbidden request header bagi JavaScript di browser. Front-end code tidak dapat bebas menetapkan nilai arbitrer melalui fetch().

Sifat ini berguna pada boundary server. Halaman attacker dapat memicu beberapa jenis request browser, tetapi JavaScript pada halaman tersebut tidak dapat begitu saja memberi label same-origin pada request lintas situs. Browser memasok metadata berdasarkan konteks request.

Server tetap harus menerapkan policy. Kehadiran Sec-Fetch-Site: cross-site tidak otomatis memblokir request. Fetch Metadata bersifat deskriptif; enforcement berada pada aplikasi, reverse proxy, gateway, atau layer server tepercaya lainnya.

Client non-browser merupakan kasus terpisah. Command-line tool, aplikasi mobile, integrasi service, dan user agent lama dapat tidak mengirim header tersebut. Deployment harus menentukan arti ketiadaan header untuk setiap endpoint, bukan berasumsi bahwa semua request membawa metadata browser.

Header yang tidak ada memerlukan aturan kompatibilitas

Policy ketat yang menolak setiap request tanpa Fetch Metadata dapat mengganggu client yang sah. Policy longgar yang menganggap ketiadaan header sebagai tanda tepercaya dapat membuat traffic lama berada di luar pemeriksaan isolasi.

Migrasi karena itu memerlukan fallback yang jelas. Untuk route yang mengubah state dan ditujukan bagi browser, server dapat menggabungkan Fetch Metadata dengan kontrol CSRF serta pemeriksaan origin yang sudah ada. Untuk machine API, authentication dan authorization khusus protokol tetap menjadi boundary utama.

Hal pentingnya adalah tidak mengartikan ketiadaan header sebagai bukti konteks same-origin. Metadata yang tidak ada tetap berarti metadata tidak tersedia.

Selama rollout, telemetry dapat mencatat route, method, nilai Fetch Metadata yang relevan, dan keputusan policy. Data tersebut membantu menemukan celah kompatibilitas sebelum enforcement diperluas. Log sebaiknya tidak menyimpan data request sensitif yang tidak diperlukan.

Token CSRF membuktikan kepemilikan nilai yang semestinya tidak dimiliki situs attacker. Atribut cookie SameSite memengaruhi kapan browser menyertakan cookie pada request lintas situs. Fetch Metadata memberi server konteks request. Ketiganya bekerja pada titik yang berbeda.

Untuk endpoint sensitif yang menggunakan autentikasi cookie, desain berlapis dapat mencakup:

policy session cookie
        +
validasi token CSRF
        +
validasi Origin atau Referer bila sesuai
        +
isolation policy Fetch Metadata

Fetch Metadata dapat menolak traffic lintas situs yang jelas tidak kompatibel sejak awal, sebelum pemrosesan request yang lebih dalam. Mekanisme ini tidak seharusnya diam-diam menggantikan kontrol CSRF yang sudah ada kecuali dukungan browser, populasi client, semantik endpoint, dan perilaku fallback aplikasi telah dievaluasi sebagai satu sistem.

Kehati-hatian yang sama berlaku untuk CORS. CORS mengatur apakah JavaScript browser dapat membaca response lintas origin tertentu dan, untuk beberapa request, apakah preflight mengizinkan operasi. CORS bukan pengganti umum untuk authorization request di server. Fetch Metadata memberi sinyal berbeda dan dapat diberlakukan pada bentuk request yang tidak bergantung pada response yang dapat dibaca.

Resource publik memerlukan exception yang disengaja

Sebagian resource memang ditujukan untuk dipakai dari situs lain. Gambar dapat di-embed, script dapat didistribusikan melalui endpoint publik, dan API dapat sengaja mendukung caller lintas origin tertentu.

Isolation policy sebaiknya mengklasifikasikan route tersebut, bukan menambahkan izin cross-site secara menyeluruh. Contohnya:

/public-images/*      izinkan pemuatan gambar yang sesuai
/public-docs/*        izinkan navigasi top-level
/api/private/*        wajib mengikuti policy API aplikasi
/account/*            tolak request lintas situs yang tidak sesuai

Sec-Fetch-Dest dapat membantu membedakan request dokumen dari image atau script, tetapi nilainya tetap merupakan sinyal kontekstual. Server harus menentukan apakah destination tersebut sesuai dengan resource.

Caching juga perlu diperhatikan ketika perilaku response berubah berdasarkan nilai Fetch Metadata. Shared cache memerlukan konfigurasi yang tidak memakai ulang response pada konteks request lain dengan cara yang melanggar policy server. Jika pemilihan response bergantung pada header tersebut, cache key atau penanganan Vary harus tetap selaras dengan keputusan itu.

Terapkan policy sebelum pekerjaan sensitif

Pemeriksaan isolasi paling berguna di dekat request boundary. Menolak request yang tidak sesuai setelah database transaction, parsing body yang mahal, atau perubahan state sudah dimulai berarti pemeriksaan dilakukan terlambat.

Urutan praktis dapat berbentuk:

request masuk
    |
validasi konteks request
    |
tolak bentuk lintas situs yang tidak sesuai
    |
authentication dan authorization
    |
validasi CSRF dan input aplikasi
    |
jalankan operasi

Urutan tepatnya dapat berbeda mengikuti framework dan kebutuhan endpoint, tetapi pemeriksaan metadata tidak boleh dianggap sebagai authorization user. Request same-origin tetap dapat berasal dari halaman yang telah dikompromikan, extension berbahaya, jalur XSS, atau user terautentikasi yang tidak memiliki izin atas object yang diminta.

Fetch Metadata mempersempit satu attack surface: request browser dengan konteks lintas situs yang tidak sesuai dengan resource yang diminta. Nilainya berasal dari boundary yang presisi, exception yang terdokumentasi, serta kontrol lain yang tetap menjaga identity, object access, dan perubahan state.

Referensi

Keamanan Siber Keamanan Web Fetch Metadata CSRF