Sebuah aplikasi di https://accounts.example.com memakai session cookie bertanda SameSite=Strict. Service terpisah di https://reports.example.com dikelola tim lain dan memiliki origin berbeda. Kedua host dipisahkan oleh model origin browser untuk banyak kemampuan web, tetapi request dari salah satunya masih dapat diklasifikasikan sebagai same-site terhadap yang lain. Atribut cookie tersebut menegakkan batas site, bukan menduplikasi same-origin policy.
Perbedaan ini merupakan inti nilai keamanan SameSite. Atribut tersebut dapat menahan ambient cookie credential pada request yang diklasifikasikan sebagai cross-site, sehingga mengurangi paparan terhadap cross-site request forgery dan attachment credential yang tidak diinginkan. Namun, atribut ini tidak menjadikan setiap sibling hostname sebagai requester eksternal. Deployment yang memperlakukan pemisahan subdomain sebagai trust boundary pada tingkat origin dapat menganggap SameSite memberikan perlindungan lebih besar daripada yang sebenarnya disediakan mekanisme tersebut.
Pengiriman cookie menggunakan klasifikasi site
Spesifikasi cookie saat ini mendefinisikan pemrosesan same-site request melalui konsep site, bukan sekadar kesamaan hostname. Perhitungannya memasukkan request context dan site for cookies milik client. Pemrosesan schemeful same-site modern juga membedakan scheme, sehingga http://example.com dan https://example.com tidak otomatis berada dalam site yang sama hanya karena registrable domain-nya cocok.
Klasifikasi ini lebih luas daripada origin. Web origin mencakup scheme, host, dan port. Dua aplikasi HTTPS pada sibling host dapat bersifat cross-origin tetapi tetap same-site. Demikian pula, perubahan port mengubah origin tetapi tidak dengan sendirinya menciptakan site berbeda untuk penerapan cookie.
Batas tersebut memiliki dampak operasional yang konkret. SameSite=Strict mencegah cookie dikirim bersama cross-site request, tetapi tidak menahan cookie hanya karena document yang memulai request berasal dari origin berbeda. Jika origin tersebut tetap berada dalam klasifikasi site yang sama, gerbang SameSite tidak menyediakan isolasi origin.
Strict dan Lax mengubah kondisi attachment
Cookie bertanda SameSite=Strict dibatasi pada same-site request sesuai aturan pemrosesan user agent yang berlaku. Ini merupakan mode SameSite standar yang paling ketat dan dapat mengganggu flow yang sengaja datang dari site lain, termasuk beberapa jalur kembali federated sign-in.
SameSite=Lax mengizinkan pengiriman same-site dan juga selected cross-site top-level navigation sesuai aturan retrieval dalam spesifikasi. Karena itu, mode ini lebih longgar daripada Strict untuk flow berbasis navigation. Request method dan navigation context yang tepat tetap penting; memperlakukan Lax sebagai sinonim dari “tidak pernah dikirim cross-site” menghasilkan model keamanan yang keliru.
SameSite=None mengizinkan pengiriman cookie dalam konteks same-site maupun cross-site, dengan tetap tunduk pada aturan pencocokan cookie lainnya. Pemrosesan modern mengharuskan cookie yang menyatakan SameSite=None memenuhi secure-cookie requirement terkait. Atribut ini tidak mengesampingkan batasan domain, path, expiry, atau secure transport.
Mode-mode tersebut mengontrol attachment state cookie oleh browser. Mode ini tidak membuktikan bahwa request sengaja dibuat oleh aplikasi dan tidak membawa pernyataan terautentikasi tentang JavaScript principal yang memulai request.
Sibling origin dapat berada di dalam batas credential
Pertimbangkan app.example.com dan uploads.example.com. Keduanya mungkin memiliki codebase, deployment pipeline, administrator, dan exposure terhadap vulnerability yang berbeda. Isolasi origin browser mencerminkan perbedaan host tersebut. Namun, klasifikasi site masih dapat menempatkan keduanya di bawah registrable-domain site yang sama ketika scheme yang relevan sesuai.
Jika uploads.example.com dikuasai attacker akibat service misconfiguration, target DNS yang ditinggalkan, atau kompromi aplikasi, request yang dimulainya menuju app.example.com dapat berada dalam posisi keamanan berbeda dari request yang berasal dari domain tidak terkait. Session cookie SameSite=Strict bukan pertahanan umum terhadap content berbahaya yang sudah beroperasi di dalam site yang sama.
Hal ini menjadikan tata kelola subdomain bagian dari arsitektur keamanan cookie. Parent namespace yang memuat tenant tidak tepercaya, delegated service, host campaign sementara, atau aplikasi yang dikelola pihak eksternal tidak seharusnya dimodelkan sebagai satu aplikasi tepercaya hanya karena cookie sensitifnya memakai SameSite.
Masalahnya bukan karena atribut tersebut gagal memenuhi kontraknya. Kontraknya memang lebih sempit: membatasi pengiriman cookie cross-site. Kegagalan muncul ketika arsitektur menggantikan kontrak itu dengan batas origin yang tidak pernah disediakan mekanisme tersebut.
Domain scope dan SameSite menyelesaikan masalah berbeda
Atribut Domain mengontrol host mana yang dapat menerima cookie. Host-only cookie, yang dibuat tanpa Domain, hanya dikirim ke host yang menetapkannya sesuai aturan pencocokan cookie. Domain cookie juga dapat memenuhi syarat untuk subordinate host.
SameSite menerapkan filter berbeda. Host-only session cookie untuk app.example.com tidak dikirim ke uploads.example.com, tetapi request yang dimulai dari uploads.example.com menuju app.example.com masih dapat bersifat same-site. Karena itu, destination host dapat menerima host-only cookie miliknya sendiri pada request tersebut jika semua kondisi lain mengizinkan pengiriman.
Perbedaan ini mudah terlewat karena kedua mekanisme melibatkan nama domain. Cookie domain matching menentukan destination host yang memenuhi syarat menerima state tersimpan. Pemrosesan same-site mengevaluasi request context sebagai pembatas pengiriman tambahan. Mempersempit Domain tidak memaksa sibling initiator menjadi cross-site, dan SameSite tidak mempersempit host scope cookie.
Nested context dapat kehilangan status same-site
Pemrosesan same-site juga sensitif terhadap embedding context. Spesifikasi cookie menghitung site for cookies sebuah document menggunakan top-level origin dan ancestor chain. Jika hierarki document yang relevan melintasi batas site, site for cookies yang dihitung dapat menjadi opaque, sehingga memengaruhi request yang dikeluarkan dari context tersebut.
Karena itu, same-site iframe tidak dapat dianalisis hanya dari URL iframe dan destination URL. Ancestor context dapat mengubah klasifikasinya. Hal ini penting untuk widget, embedded administration surface, dan aplikasi yang mengasumsikan sibling hostname selalu mendapat perlakuan cookie yang sama terlepas dari tempat sibling tersebut di-embed.
Request berbasis worker memiliki pemrosesan site-for-cookies tersendiri dalam spesifikasi. Inti yang lebih luas tetap sama: SameSite adalah contextual request policy, bukan perbandingan statis antara dua string host yang terlihat.
Pertahanan CSRF tetap membutuhkan trust model aplikasi yang sebenarnya
SameSite dapat menghilangkan kelas besar attachment credential cross-site sebelum request mencapai server code. Ini membuatnya bernilai sebagai lapisan pertahanan yang ditegakkan browser. Namun, cakupannya mengikuti model site browser dan mode atribut yang dipilih.
Aplikasi dengan perubahan state sensitif sering membutuhkan kontrol yang mencerminkan trust boundary yang lebih sempit. Anti-forgery token dapat mengikat request ke application state yang tidak dapat begitu saja dibuat oleh foreign context agar dilampirkan browser. Origin-aware request validation juga dapat membedakan sibling origin ketika kebijakan deployment membutuhkan pemisahan tersebut, asalkan aplikasi menangani ketersediaan header dan kelas request yang diharapkan dengan benar.
Kontrol tersebut menangani bukti yang berbeda dari SameSite. Menggabungkannya tidak redundan ketika threat model mencakup sibling origin yang tidak tepercaya atau dikelola secara independen. Satu mekanisme membatasi ambient cookie delivery antar-site; mekanisme lain dapat menegakkan authorization spesifik aplikasi untuk state-changing request.
Karena itu, desain yang aman memperlakukan SameSite sebagai request-context filter dengan scope eksplisit. Perlindungannya paling kuat ketika batas administratif site selaras dengan trust boundary aplikasi. Ketika sebuah registrable domain memuat principal dengan security posture berbeda, kesenjangan antara site dan origin menjadi properti arsitektural yang harus diperhitungkan oleh server-side request authorization.