Digital Transformation
Sec-Fetch Headers (Fetch Metadata)
TL;DR: Sec-Fetch Headers adalah set header HTTP (
Sec-Fetch-Site,Sec-Fetch-Mode,Sec-Fetch-Dest,Sec-Fetch-User) yang dikirim otomatis oleh browser modern untuk memberitahu server konteks dari request. Server bisa menolak request lintas-situs yang mencurigakan tanpa bergantung pada CSRF token tradisional. Didukung Chrome, Firefox, dan Safari sejak 2023.
Apa itu Sec-Fetch Headers?
Sec-Fetch Headers adalah implementasi spesifikasi Fetch Metadata Request Headers dari W3C. Browser secara otomatis menambahkan header ini di setiap request HTTP, memberi server informasi tentang konteks asal request: apakah dari situs yang sama, apakah hasil navigasi, apakah dipicu user, dan jenis resource yang diminta. Header ini tidak bisa di-set atau dipalsukan dari JavaScript karena namanya diawali Sec-, yang termasuk header terlindungi.
Ada empat header utama. Sec-Fetch-Site menunjukkan hubungan asal (same-origin, same-site, cross-site, none). Sec-Fetch-Mode menunjukkan mode request (navigate, cors, no-cors). Sec-Fetch-Dest menunjukkan tujuan resource (document, script, image, dst). Sec-Fetch-User bernilai ?1 kalau request dipicu interaksi user.
Cara Kerja Sebagai Pertahanan
| Skenario | Sec-Fetch-Site | Aksi Server |
|---|---|---|
| Navigasi dari halaman lain di domain | same-origin | Allow |
| Form submit dari subdomain | same-site | Allow |
| Request dari situs eksternal | cross-site | Block (kalau bukan endpoint publik) |
| Diketik langsung di address bar | none | Allow |
Pola middleware Next.js sederhana: kalau endpoint /api/checkout menerima request dengan Sec-Fetch-Site: cross-site, langsung tolak dengan status 403. Ini menutup vector CSRF tanpa perlu CSRF token di form. Tetap kombinasikan dengan Content Security Policy untuk pertahanan berlapis.
Kenapa Penting?
Sec-Fetch Headers mengurangi kompleksitas keamanan tanpa memperberat aplikasi. Untuk situs Indonesia yang sering jadi target SPAM form submission dari bot lintas-domain, satu baris check di middleware bisa menggantikan logic CSRF token yang error-prone. Dari pengalaman beberapa project, false positive di bawah 0,5% kalau diterapkan dengan whitelist yang benar untuk endpoint webhook seperti payment gateway dan Meta Conversion API.
Pertanyaan Umum
Apakah Sec-Fetch Headers menggantikan CSRF token?
Untuk sebagian besar kasus, ya, asal browser pengguna mendukungnya (Chrome, Firefox, Safari modern). Tapi untuk endpoint yang melayani user dengan browser lama atau klien non-browser, CSRF token tradisional tetap dipasang sebagai fallback.
Bagaimana cara test Sec-Fetch Headers di local?
Gunakan curl dengan flag -H "Sec-Fetch-Site: cross-site" untuk simulasi request lintas situs. Atau buka DevTools Network tab dan lihat Request Headers di setiap request asli dari browser.
Istilah Terkait