Cookie SameSite Membatasi Pengiriman Sesi Lintas Situs

Cookie sesi merupakan kredensial ambient: setelah tersimpan, browser dapat menyertakannya pada request HTTP yang cocok tanpa kode aplikasi menyalin nilainya ke setiap request. Kemudahan itu sekaligus membentuk batas keamanan. Request yang dimulai dari situs lain dapat mencapai aplikasi sambil membawa sesi terautentikasi milik pengguna jika policy cookie tidak mencegahnya.

Atribut SameSite memberi browser aturan untuk menentukan apakah cookie boleh menyertai request dalam konteks lintas situs. Atribut ini tidak mengubah nilai cookie dan tidak mengautentikasi request dengan sendirinya. Yang diatur adalah kapan browser menyertakan cookie tersebut.

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

Keputusan di sisi browser ini dapat mengurangi paparan terhadap cross-site request forgery, tetapi posisinya tetap berdampingan dengan otorisasi server, validasi request, dan kontrol CSRF lain yang dibutuhkan aplikasi.

Same-site berbeda dari same-origin

Pemrosesan cookie SameSite memakai batas situs, bukan batas origin web yang lebih ketat. Origin mencakup scheme, host, dan port. Perhitungan same-site untuk cookie memakai scheme bersama aturan registrable domain yang ditetapkan spesifikasi cookie.

Akibatnya, dua subdomain dapat berbeda origin tetapi tetap berada dalam konteks situs yang sama.

https://app.example.com
https://api.example.com

origin berbeda
dapat tetap same-site

Perbedaan ini penting ketika deployment memperlakukan subdomain sebagai zona trust yang terpisah. SameSite bukan pengganti isolasi origin, policy CORS, CSP, atau pengelolaan kepemilikan subdomain yang ketat.

SameSite=Strict menerapkan policy pengiriman lintas situs paling sempit dari tiga nilai eksplisit. Browser mengirim cookie pada konteks same-site dan menahannya ketika request bersifat cross-site.

Set-Cookie: admin_session=opaque-value; Secure; HttpOnly; SameSite=Strict

Perilaku tersebut sesuai untuk sesi yang tidak perlu bertahan saat pengguna masuk dari situs eksternal. Dampaknya juga dapat mengenai navigasi biasa. Pengguna yang mengikuti tautan dari situs lain dapat tiba tanpa cookie Strict pada request awal.

Karena itu, pemilihan Strict perlu mengikuti alur navigasi dan sign-in aplikasi, bukan hanya tingkat sensitivitas cookie.

Lax membuka jalur navigasi terbatas

SameSite=Lax mengizinkan pengiriman same-site dan memperbolehkan cookie pada navigasi top-level lintas situs tertentu yang memakai safe method. Cookie umumnya tidak disertakan pada request subresource lintas situs, request iframe, atau form submission dengan unsafe method.

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

Karakteristik ini membuat Lax cocok untuk banyak sesi web biasa. Pengguna tetap dapat mengikuti tautan normal menuju situs, sementara banyak pola request background atau perubahan state dari situs lain tidak menerima cookie sesi.

Konteks request tetap menentukan hasil. Policy keamanan aplikasi tidak sebaiknya menyederhanakan Lax menjadi klaim bahwa seluruh request lintas situs akan diblokir. Lax adalah policy pengiriman cookie dengan pengecualian yang terdefinisi.

None mengizinkan pengiriman lintas situs secara eksplisit

SameSite=None menyatakan bahwa cookie memang ditujukan untuk konteks same-site maupun cross-site. Aturan cookie saat ini mewajibkan Secure ketika SameSite=None digunakan.

Set-Cookie: widget_session=opaque-value; Secure; HttpOnly; SameSite=None

Pengaturan ini dapat diperlukan oleh service yang di-embed di banyak situs atau arsitektur lain yang memang membutuhkan pengiriman cookie lintas situs. Konsekuensinya, perilaku kredensial ambient yang dibatasi Strict dan Lax kembali dibuka.

Pemilihan None sebaiknya terikat pada kebutuhan lintas situs yang konkret. Jika hanya satu endpoint memerlukan integrasi cross-site, memperluas cookie sesi utama dapat menjadi perubahan trust yang lebih besar daripada memakai mekanisme integrasi dengan scope lebih sempit.

Domain, Path, Secure, HttpOnly, dan SameSite mengatur properti yang berbeda. Menggabungkannya tidak membuat atribut tersebut saling menggantikan.

Domain / host-only -> host yang cocok
Path               -> path request yang cocok
Secure             -> syarat transport HTTPS
HttpOnly           -> pembatasan akses script
SameSite           -> policy pengiriman lintas situs

Cookie host-only tetap dapat memerlukan perlindungan SameSite. Cookie Secure tetap dapat dikirim pada request HTTPS lintas situs jika policy SameSite mengizinkan konteks tersebut. HttpOnly mencegah API script seperti Document.cookie membaca cookie, tetapi atribut itu sendiri tidak menghentikan browser menyertakan cookie pada request.

Review keamanan perlu menilai seluruh tuple cookie, bukan memperlakukan satu atribut sebagai pengganti atribut lainnya.

SameSite mengurangi paparan CSRF tanpa menetapkan otorisasi

Serangan CSRF bergantung pada browser yang mengirim kredensial ke target sementara attacker mengendalikan konteks awal request. Menahan cookie sesi dari request lintas situs yang relevan dapat memutus prasyarat tersebut.

Kontrol ini tetap bukan keputusan otorisasi. Aplikasi dapat memiliki endpoint yang dapat dicapai tanpa cookie, kredensial alternatif, konten yang dikendalikan attacker tetapi masih same-site, atau flow yang sengaja mengizinkan navigasi lintas situs. Kasus tersebut berada di luar model sederhana berupa cookie sesi yang ditahan.

Endpoint yang mengubah state tetap perlu menegakkan persyaratan otorisasi dan integritas request. Jika CSRF token, validasi origin, atau kontrol eksplisit lain termasuk dalam threat model aplikasi, SameSite sebaiknya diperlakukan sebagai lapisan tambahan yang ditegakkan browser, bukan alasan untuk menghapus kontrol tersebut tanpa analisis.

Redirect chain perlu diuji secara eksplisit

Flow autentikasi dan pembayaran sering melintasi batas situs melalui redirect. Keputusan cookie browser bergantung pada konteks request yang terbentuk, sehingga konfigurasi yang tampak benar pada request langsung dapat berperilaku berbeda setelah melewati identity provider eksternal atau hop lintas situs lain.

Pengujian sebaiknya mencakup flow browser yang nyata: navigasi masuk, callback request, submission yang mengubah state, konteks embedded bila ada, dan logout. Kehadiran cookie yang diharapkan dapat dicatat untuk setiap tahap.

konteks request                  cookie sesi yang diharapkan
navigasi same-site               ya
subresource cross-site           tergantung policy
navigasi top-level cross-site    tergantung policy
POST cross-site                  tergantung policy

Cara ini lebih andal daripada menyimpulkan perilaku hanya dari URL endpoint.

Tetapkan atribut secara eksplisit

Atribut cookie yang eksplisit membuat maksud deployment terlihat pada konfigurasi dan mengurangi ketergantungan pada default user agent. Browser modern umumnya menerapkan perilaku menyerupai Lax ketika SameSite tidak ditentukan, tetapi detail kompatibilitas dan penanganan default telah berubah seiring waktu.

Sesi yang sensitif terhadap keamanan sebaiknya menyatakan nilai yang dimaksud:

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

Nilai yang dipilih perlu sesuai dengan kebutuhan cross-site aplikasi yang nyata. Memperketat pengaturan tanpa pengujian dapat merusak flow federation atau embedding yang sah; melonggarkannya dapat memperluas tempat kredensial sesi ambient dikirim.

Referensi

Cybersecurity HTTP Cookie CSRF