Cookie SameSite Membatasi Pengiriman Kredensial Cross-Site

Cookie merupakan kredensial ambient: setelah tersimpan, browser dapat menyertakannya pada request yang cocok tanpa kode aplikasi memasok setiap nilai secara eksplisit. Kemudahan ini sekaligus membentuk boundary keamanan. Halaman pada satu site dapat menyebabkan browser mengirim request ke site lain, dan cookie autentikasi yang ikut terkirim dapat membuat request tersebut berjalan dengan sesi pengguna.

Atribut cookie SameSite mempersempit perilaku itu. Atribut ini memberi browser aturan mengenai kapan cookie layak menyertai request ketika konteks site berbeda dari site yang menetapkan cookie. Kontrol ini berguna terhadap sejumlah pola cross-site request forgery, tetapi bukan mekanisme otorisasi lengkap dan tidak menggantikan token CSRF atau pemeriksaan request di server ketika kontrol tersebut diperlukan.

SameSite memakai konteks site

SameSite dievaluasi memakai konsep site pada browser, bukan hanya kesamaan origin antara dua URL. Pemrosesan schemeful same-site memasukkan scheme sebagai bagian boundary, sedangkan registrable domain menjadi unsur utama dalam perhitungan site.

Perbedaan ini penting bagi arsitektur yang tersebar di beberapa subdomain. Dua origin dapat berbeda tetapi masih same-site. Layanan pada app.example.com dan layanan lain pada api.example.com tidak otomatis terisolasi dari setiap risiko cross-site terkait cookie hanya karena origin keduanya berbeda.

Scope cookie dan kebijakan SameSite juga menjawab pertanyaan berbeda. Domain dan Path memengaruhi request mana yang cocok dengan cookie. SameSite menambahkan konteks mengenai hubungan antara site pemicu dan target request. Cookie tetap harus memenuhi aturan pencocokan yang relevan sebelum kelayakan SameSite berperan.

Strict mempertahankan boundary cross-site paling sempit

Cookie dapat ditetapkan dengan SameSite=Strict:

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

Strict menahan cookie dari request cross-site. Boundary ini cocok untuk cookie yang tidak perlu menyertai navigasi yang datang dari site lain.

Konsekuensi operasionalnya terlihat pada navigasi biasa. Pengguna yang mengikuti tautan eksternal menuju suatu site dapat tiba tanpa cookie sesi Strict pada request awal. Aplikasi yang memerlukan akses terautentikasi tanpa jeda dari site eksternal dapat menganggap Strict terlalu ketat untuk desain sesi tertentu.

Batas kegunaan itu sebaiknya ditangani secara sengaja, bukan dengan melonggarkan seluruh cookie. Aplikasi dapat memisahkan cookie berdasarkan fungsi dan memberi state sensitif kebijakan yang lebih ketat daripada state yang memang memerlukan perilaku navigasi lebih luas.

Lax mengizinkan kasus navigasi terbatas

SameSite=Lax lebih longgar. Kebijakan ini menahan cookie dari banyak subrequest cross-site dan konteks request yang tidak aman, tetapi mengizinkannya pada kasus navigasi top-level tertentu yang memakai metode HTTP aman.

Cookie sesi dapat memakai pola berikut:

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

Kebijakan ini sering sesuai bagi site yang perlu mempertahankan sesi saat pengguna mengikuti tautan biasa dari site lain. Pada saat yang sama, pengiriman kredensial otomatis tetap berkurang pada banyak konteks request cross-site.

Lax tidak menyatakan bahwa setiap request yang diizinkan pasti aman. Endpoint yang mengubah state melalui metode aman sudah melanggar semantik metode HTTP dan tetap dapat rentan walaupun kebijakan cookie tampak ketat. Perubahan state seharusnya memakai metode yang sesuai serta tetap memiliki otorisasi dan, bila relevan, pertahanan CSRF eksplisit.

Default browser juga perlu diperhitungkan. Browser modern umumnya menerapkan default berorientasi Lax ketika SameSite tidak dicantumkan, dengan detail kompatibilitas yang dapat berbeda dari deklarasi SameSite=Lax secara eksplisit. Deployment yang sensitif terhadap keamanan sebaiknya menyatakan atribut yang dimaksud dan tidak bergantung pada default implisit.

None mengizinkan penggunaan cross-site dan memerlukan Secure

Sebagian integrasi memang memerlukan cookie dalam konteks cross-site. SameSite=None menyatakan kebutuhan tersebut:

Set-Cookie: integration=opaque-value; Secure; HttpOnly; SameSite=None; Path=/

Browser mensyaratkan Secure bersama SameSite=None, sehingga cookie dibatasi pada transport aman. Kelayakan cross-site yang lebih luas memang disengaja: cookie dapat menyertai request pada konteks yang akan ditahan oleh Lax atau Strict.

Karena itu, None merupakan pilihan kebijakan, bukan sakelar kompatibilitas yang layak diterapkan ke semua cookie. Cookie untuk layanan embedded, alur federasi, atau integrasi cross-site lain mungkin memerlukannya, sedangkan sesi administratif yang tidak terkait mungkin tidak.

Kontrol third-party cookie dapat menambahkan pembatasan lain. SameSite=None tidak menjamin browser akan mengirim cookie pada setiap konteks pihak ketiga. Pengaturan pengguna, mekanisme privasi browser, partitioning, dan kebijakan cookie lain tetap menjadi lapisan terpisah.

SameSite mengurangi paparan CSRF tanpa membuktikan intent request

Serangan CSRF mengandalkan browser yang membuat request dengan authority yang tidak dapat dibaca langsung oleh penyerang. Membatasi penyertaan cookie otomatis menghilangkan authority tersebut dari banyak request cross-site sehingga jalur serangan dapat terputus.

Perlindungan ini bersyarat. Penyerang yang berada pada konteks same-site, layanan sibling yang terkompromi, alur aplikasi yang sengaja memakai SameSite=None, serta endpoint yang dapat dicapai melalui pola navigasi yang diizinkan dapat berada di luar boundary SameSite. Server juga tidak dapat menyimpulkan intent pengguna yang sah hanya dari keberadaan cookie.

Untuk perubahan state sensitif, mekanisme anti-CSRF eksplisit tetap bernilai. Server dapat meminta token yang terikat pada sesi pengguna atau properti request lain yang tidak dapat dipasok site yang tidak terkait. Metadata request terkait origin dapat menjadi sinyal tambahan. Otorisasi tetap harus memastikan principal yang terautentikasi memang boleh menjalankan operasi yang diminta.

Kontrol tersebut saling melengkapi. SameSite mengubah kapan kredensial ambient dikirim. Token CSRF dapat mengikat request pada state yang dibuat aplikasi. Otorisasi menentukan apakah operasi diizinkan. Tugas tersebut tidak seharusnya diam-diam dialihkan ke lapisan lain.

Setiap peran cookie layak memiliki kebijakan sendiri

Aplikasi sering mengumpulkan beberapa cookie dengan kebutuhan keamanan berbeda: sesi utama, refresh state, preferensi, nilai anti-CSRF, state layanan embedded, dan penanda transaksi berumur pendek. Memberikan atribut identik pada semuanya dapat memperluas paparan tanpa kebutuhan.

Review yang berguna dimulai dari fungsi setiap cookie. Jika cookie tidak pernah memerlukan pengiriman cross-site, Strict dapat sesuai. Jika navigasi melalui tautan top-level perlu mempertahankan sesi, Lax dapat sesuai. Jika integrasi cross-site tertentu membutuhkan pengiriman kredensial, None; Secure dapat dibenarkan hanya untuk cookie tersebut.

Atribut lain tetap penting. Secure membatasi transport ke HTTPS. HttpOnly mencegah akses JavaScript melalui document.cookie, sehingga mengurangi paparan pada sebagian jalur pencurian berbasis script tetapi tidak menghentikan browser mengirim cookie. Scope host-only, path yang sempit ketika sesuai, masa berlaku pendek, dan prefix nama cookie dapat memperketat penggunaan lebih jauh.

Kebijakan akhirnya paling kuat ketika setiap atribut memiliki tugas yang jelas. SameSite adalah aturan yang ditegakkan browser untuk pengiriman cookie cross-site. Kontrol ini lebih efektif ketika aplikasi menjaga semantik route yang mengubah state, menerapkan pertahanan request eksplisit saat diperlukan, dan tidak memberi scope cookie lebih luas daripada kebutuhan fitur.