Prefix Cookie Mengikat Batas yang Ditegakkan Browser pada Nama Cookie

HTTP cookie membawa atribut keamanan seperti Secure, HttpOnly, Domain, dan Path. Prefix cookie menambahkan lapisan lain: pola khusus pada nama cookie memberi tahu browser yang mendukungnya bahwa atribut tertentu wajib menyertai cookie tersebut. Jika header Set-Cookie melanggar kontrak itu, browser menolak cookie alih-alih menyimpannya dengan konfigurasi yang lebih lemah.

Mekanisme ini berguna karena maksud konfigurasi terlihat langsung pada nama. Cookie sesi dengan prefix yang terikat ke host tidak dapat diam-diam berubah menjadi cookie dengan cakupan domain tanpa gagal pada pemeriksaan prefix oleh browser.

__Secure- mewajibkan transport aman

Cookie dengan nama yang diawali __Secure- harus ditetapkan dari konteks HTTPS yang aman dan harus membawa atribut Secure.

Set-Cookie: __Secure-session=VALUE; Secure; HttpOnly; SameSite=Lax

Prefix tersebut tidak mewajibkan HttpOnly, SameSite, nilai Path tertentu, atau ketiadaan Domain. Kontrol itu tetap merupakan pilihan terpisah. Prefix ini menetapkan invariant yang lebih sempit: cookie harus memenuhi syarat penetapan melalui konteks aman.

Header yang tidak menyertakan Secure tidak memenuhi kontrak:

Set-Cookie: __Secure-session=VALUE; HttpOnly

Pada user agent yang menegakkan prefix cookie, cookie ditolak dan tidak diterima sebagai cookie biasa dengan konfigurasi tidak aman.

__Host- juga menghapus cakupan domain

Prefix __Host- memiliki syarat yang lebih ketat. Cookie harus ditetapkan dari konteks HTTPS yang aman, menyertakan Secure, tidak memiliki atribut Domain, dan menggunakan Path=/.

Set-Cookie: __Host-session=VALUE; Secure; HttpOnly; Path=/; SameSite=Lax

Tanpa Domain, cookie menjadi host-only. Respons dari app.example.com tidak dapat memakai cookie __Host- sambil mendeklarasikan Domain=example.com untuk membagikannya ke host lain dalam domain tersebut.

Kewajiban root path juga mencegah nama dengan prefix yang sama sengaja dibatasi ke path URL yang lebih sempit. Hasilnya adalah cookie yang terikat pada host yang menetapkannya dan tersedia di seluruh path pada host itu.

Header berikut melanggar kontrak prefix:

Set-Cookie: __Host-session=VALUE; Secure; Path=/; Domain=example.com
Set-Cookie: __Host-session=VALUE; Secure; Path=/account
Set-Cookie: __Host-session=VALUE; Path=/

Baris pertama menambahkan cakupan domain, baris kedua mempersempit path, dan baris ketiga tidak menyertakan Secure.

Prefix bukan singkatan yang membuat browser menambahkan atribut yang hilang. __Host- tidak otomatis menambahkan Secure atau Path=/; server tetap harus mengirim atribut yang diwajibkan. __Secure- juga tidak menambahkan Secure pada header yang tidak valid.

Perbedaan ini membuat pemeriksaan prefix berguna sebagai invariant. Kode aplikasi, default framework, reverse proxy, dan middleware autentikasi dapat sama-sama terlibat dalam pembentukan cookie. Jika perubahan berikutnya menghapus atribut yang diwajibkan prefix, browser yang mendukung mekanisme ini menolak cookie tersebut dan tidak diam-diam menerima bentuk yang lebih lemah.

Kegagalan itu dapat memutus alur sesi, sehingga deployment tetap memerlukan pengujian. Cookie yang ditolak dapat terlihat sebagai login berulang, state yang hilang, atau request yang tidak pernah membawa identifier sesi yang diharapkan.

HttpOnly tetap menjadi batas terpisah

HttpOnly mencegah API script seperti Document.cookie membaca atau mengubah cookie. Baik __Secure- maupun __Host- tidak menyiratkan HttpOnly.

Untuk cookie sesi yang dikelola server, kombinasi yang umum adalah:

Set-Cookie: __Host-session=VALUE; Secure; HttpOnly; Path=/; SameSite=Lax

Setiap bagian memiliki peran berbeda. __Host- membatasi properti host, path, dan penetapan aman. HttpOnly membatasi akses script. SameSite mengendalikan pengiriman cross-site sesuai mode yang dipilih. Kontrol tersebut dapat digabungkan, tetapi tidak saling menggantikan.

Karena itu, sebuah cookie dapat memenuhi kontrak __Host- dan tetap dapat dibaca JavaScript jika HttpOnly tidak ada. Validasi prefix tidak tepat diperlakukan sebagai kebijakan cookie sesi yang lengkap.

Prefix HTTP-bound menambahkan kontrak lain

Dokumentasi browser saat ini juga menjelaskan __Http- dan __Host-Http-. Bentuk ini mewajibkan Secure dan HttpOnly, yang menyatakan bahwa cookie harus dibuat melalui header HTTP Set-Cookie, bukan melalui API cookie di sisi klien. __Host-Http- juga membawa batas host-only dan root path yang terkait dengan __Host-.

Set-Cookie: __Host-Http-session=VALUE; Secure; HttpOnly; Path=/; SameSite=Lax

Dukungan untuk tiap bentuk prefix dapat berbeda antar-user agent. Deployment yang bergantung pada prefix yang lebih baru perlu memeriksa kompatibilitas pada populasi klien yang benar-benar digunakan. Sintaks prefix sebaiknya memperkuat kebijakan server, bukan menjadi satu-satunya kontrol untuk melindungi cookie sensitif.

Subdomain membuat host binding penting secara operasional

Pertimbangkan aplikasi yang terbagi pada host berikut:

app.example.com
static.example.com
support.example.com

Cookie domain untuk example.com dapat dikirim ke beberapa subdomain. Hal itu mungkin memang diperlukan untuk state tertentu, tetapi juga memperluas kumpulan host yang berada dalam boundary cookie.

Cookie __Host- yang ditetapkan oleh app.example.com tidak dapat mendeklarasikan Domain=example.com. Batas ini mencegah cookie dengan prefix tersebut diperluas ke sibling host melalui atributnya. Untuk state autentikasi yang hanya menjadi milik host aplikasi, batas itu membuat cakupan yang dimaksud menjadi eksplisit.

Mekanisme ini tidak membuat setiap subdomain aman dan tidak mengisolasi seluruh state browser dengan sendirinya. Cookie lain, storage API, redirect, eksekusi script, dan hubungan kepercayaan aplikasi tetap memerlukan pemeriksaan terpisah.

Prefix tidak menyelesaikan XSS atau CSRF

Prefix cookie membatasi pembuatan dan cakupan cookie. Mekanisme ini tidak melakukan sanitasi HTML, memblokir script yang diinjeksi, memvalidasi maksud request, atau membuat identifier sesi tidak berbahaya setelah dicuri.

HttpOnly dapat mengurangi akses langsung script ke cookie sesi, tetapi celah XSS masih dapat mengirim request terautentikasi dari halaman korban. SameSite dapat membatasi sebagian pengiriman cookie cross-site, tetapi semantiknya terpisah dari penegakan prefix. Pertahanan CSRF masih dapat memerlukan request token, pemeriksaan origin, atau kontrol lain yang sesuai dengan aplikasi.

Properti prefix yang relevan lebih sempit: browser dapat menolak cookie ketika nama cookie dan atribut keamanannya tidak konsisten.

Perlakukan penolakan sebagai sinyal konfigurasi

Konfigurasi cookie sering berubah pada beberapa lapisan. Upgrade framework dapat mengubah default, proxy dapat melakukan terminasi TLS, dan route yang berbeda dapat mengirim header Set-Cookie yang berbeda. Prefix mengubah sebagian pelemahan yang tidak disengaja menjadi kegagalan yang terlihat.

Pengujian dapat memeriksa header lengkap, termasuk kapitalisasi prefix yang tepat dan atribut wajib. Integration test pada browser juga dapat memastikan varian yang tidak valid tidak tersimpan.

Untuk cookie sesi yang terikat host, daftar pemeriksaan ringkas dapat dibuat secara konkret:

nama diawali __Host-
respons menggunakan HTTPS
Secure tersedia
Domain tidak ada
Path=/
HttpOnly tersedia jika akses script tidak diperlukan
SameSite sesuai dengan model request aplikasi

Dua baris terakhir merupakan pilihan kebijakan di luar kontrak dasar __Host-, tetapi keduanya relevan bagi banyak desain sesi.

Prefix cookie paling efektif sebagai kontrak penamaan yang dapat ditegakkan. Mekanisme ini tidak menggantikan desain sesi yang cermat, tetapi membuat invariant cookie tertentu lebih sulit dilemahkan secara tidak sengaja. Ketika nama menyatakan __Host-, browser yang mendukungnya mengharapkan atribut tetap mempertahankan boundary yang terikat pada host tersebut.

Referensi

Keamanan Siber HTTP Cookie Keamanan Web Keamanan Sesi