Prefix Cookie __Host- Mempersempit Scope Cookie Sesi

Cookie sesi dapat membawa identifier acak yang kuat tetapi tetap memiliki scope yang terlalu luas. Atribut Domain dapat membuat cookie tersedia di berbagai subdomain, sedangkan cookie dengan path tertentu dapat berdampingan dengan cookie bernama sama. Detail tersebut penting ketika beberapa aplikasi berbagi registrable domain tetapi tidak berbagi security boundary yang sama.

Prefix nama cookie __Host- memberi user agent yang mendukungnya sekumpulan aturan ringkas untuk cookie yang lebih ketat. Cookie dengan nama yang diawali __Host- harus ditetapkan dari secure origin dengan Secure, harus memakai Path=/, dan tidak boleh memiliki Domain. User agent yang menerapkan prefix ini menolak cookie berprefix tersebut jika constraint itu dilanggar.

Prefix ini tidak mengubah cookie menjadi mekanisme keamanan sesi yang lengkap. Fungsinya mempersempit tempat cookie dapat ditetapkan dan scope yang dapat dimilikinya. Autentikasi, rotasi sesi, pertahanan CSRF, kontrol XSS, expiration, dan penanganan sesi di server tetap merupakan persoalan terpisah.

Prefix membuat constraint scope dapat ditegakkan browser

Cookie sesi biasa dapat menyatakan atribut yang diinginkan:

Set-Cookie: session=opaque-value; Secure; HttpOnly; Path=/

Server menginginkan cookie secure dan host-only karena Domain tidak ada. Namun, nama cookie itu sendiri tidak membawa kontrak tersebut.

Dengan __Host-, browser dapat menegakkan kombinasi tertentu:

Set-Cookie: __Host-session=opaque-value; Secure; HttpOnly; Path=/

Bagi user agent yang mendukung prefix, varian berikut tidak valid:

Set-Cookie: __Host-session=opaque-value; HttpOnly; Path=/
Set-Cookie: __Host-session=opaque-value; Secure
Set-Cookie: __Host-session=opaque-value; Secure; Path=/; Domain=example.com

Baris pertama tidak memiliki Secure. Baris kedua tidak memiliki root path yang diwajibkan. Baris ketiga menambahkan Domain, yang dilarang untuk prefix ini.

Enforcement tersebut memindahkan sebagian kontrak cookie dari konvensi aplikasi ke pemrosesan user agent.

Tanpa Domain, scope menjadi host-only

Cookie tanpa Domain bersifat host-only. Jika app.example.com menetapkannya, cookie dikirim kembali ke host tersebut dan tidak diperluas ke sibling host melalui Domain=example.com.

app.example.com
      |
      | Set-Cookie: __Host-session=...; Secure; Path=/
      v
 cookie host-only

api.example.com      tidak berbagi scope Domain
admin.example.com    tidak berbagi scope Domain

Perbedaan ini berguna ketika sibling subdomain memiliki operator, deployment stack, atau exposure kompromi yang berbeda. Cookie domain dengan scope luas menambah jumlah host yang ikut berada dalam security boundary cookie tersebut.

Prefix ini tidak mengisolasi port. Scope cookie HTTP bukan boundary berbasis port. Service pada port berbeda di host yang sama tidak boleh memperlakukan __Host- sebagai isolasi port.

Path=/ meniadakan varian path-specific untuk nama berprefix

Path cookie memengaruhi kapan cookie dikirim, tetapi Path bukan mekanisme authorization. Aturan __Host- mewajibkan Path=/, sehingga cookie berprefix berlaku di seluruh host dan tidak dibuat dengan path yang lebih sempit.

Syarat tersebut juga mencegah cookie __Host- yang valid ditetapkan pada path pesaing seperti /admin:

Set-Cookie: __Host-session=other-value; Secure; Path=/admin

Browser yang mendukung prefix menolak cookie itu karena path bukan /.

Hasilnya adalah invariant yang lebih sederhana untuk nama berprefix: scope yang diterima bersifat host-wide, bukan kumpulan varian path-specific yang dibuat di bawah kontrak prefix yang sama.

__Secure- memiliki boundary berbeda

Prefix terkait, __Secure-, mewajibkan secure origin dan atribut Secure, tetapi tidak memberlakukan batasan __Host- terhadap Domain dan Path.

Contoh berikut dapat valid:

Set-Cookie: __Secure-session=opaque-value; Secure; Domain=example.com; Path=/

Cookie tersebut dapat sengaja mencakup subdomain sesuai aturan domain cookie biasa. Pilihan antara kedua prefix karena itu mengikuti kebutuhan scope, bukan urutan bahwa satu nama selalu lebih tepat.

Cookie domain-wide mungkin memang diperlukan pada arsitektur yang sengaja berbagi state antarhost. Dalam kondisi itu, __Host- tidak kompatibel dengan scope yang dimaksud.

HttpOnly dan SameSite tetap merupakan atribut terpisah

__Host- tidak menyiratkan HttpOnly. Jika identifier sesi tidak memerlukan akses script, HttpOnly tetap merupakan atribut terpisah yang mencegah akses melalui interface seperti Document.cookie.

Demikian pula, __Host- tidak memilih policy SameSite. Server tetap menentukan perilaku pengiriman cross-site yang sesuai dengan aplikasi:

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

SameSite, HttpOnly, dan prefix menangani boundary yang berbeda:

__Host-   -> secure origin + host-only + Path=/
HttpOnly  -> memblokir akses script melalui API cookie
SameSite  -> membatasi pengiriman cookie cross-site

Menggabungkannya dapat tepat, tetapi efek masing-masing tidak seharusnya dilebur menjadi satu klaim bahwa sebuah cookie aman.

Enforcement prefix bergantung pada dukungan user agent

Constraint tambahan hanya berlaku pada user agent yang menerapkan cookie prefix. Client tanpa dukungan prefix dapat memperlakukan nama tersebut sebagai nama cookie biasa.

Boundary kompatibilitas ini penting untuk aplikasi dengan client non-browser, embedded stack, software lama, atau implementasi HTTP khusus. Server tidak boleh menganggap prefix sebagai bukti bahwa setiap client telah menegakkan seluruh aturan.

Policy di sisi server tetap perlu mengirim atribut yang dimaksud secara konsisten dan memvalidasi state sesi secara independen. Prefix merupakan defense in depth pada boundary user agent, bukan bukti integritas setiap HTTP client.

Prefix tidak memperbaiki desain sesi

Cookie dengan scope satu host masih dapat membawa token yang dapat diprediksi, berlaku terlalu lama, tetap sama setelah perubahan privilege, atau menunjuk ke state server dengan kontrol revocation yang lemah. Nama cookie tidak memperbaiki sifat-sifat tersebut.

Desain sesi yang kuat dapat memasangkan cookie __Host- dengan kontrol seperti:

identifier sesi opaque dengan entropy tinggi
expiration dan revocation di sisi server
rotasi setelah autentikasi atau perubahan privilege
Secure dan HttpOnly bila sesuai
policy SameSite yang eksplisit
proteksi CSRF sesuai model request
pencegahan XSS dan penanganan output

Prefix memberi satu jaminan yang sempit pada browser yang mendukungnya: cookie __Host- yang diterima telah ditetapkan sesuai constraint transport dan scope milik prefix.

Scope host merupakan default yang berguna untuk aplikasi terisolasi

Aplikasi sering hanya memerlukan sesi untuk satu host, bukan setiap sibling di bawah parent domain. Dalam layout tersebut, cookie host-only menjaga boundary sesi tetap sejajar dengan endpoint aplikasi.

Prefix __Host- membuat intent itu terlihat pada nama cookie dan dapat ditegakkan oleh browser yang kompatibel. Nilainya bukan kriptografi yang lebih kuat atau protokol autentikasi baru. Prefix ini membentuk namespace cookie yang lebih ketat, dengan atribut yang diterima tidak mengizinkan domain sharing maupun scope path-specific.

Boundary yang lebih kecil mengurangi coupling tidak disengaja antara sibling application sambil mempertahankan aspek keamanan sesi lain sebagai kontrol yang eksplisit.

Referensi

Keamanan Siber HTTP Cookie Keamanan Sesi