Cookie vs Session: Cara Website Menyimpan Identitas Pengguna
Kamu login ke sebuah website, pindah halaman, lalu status login tetap bertahan. Browser ditutup dan dibuka lagi, kadang kamu masih tetap login. Shopping cart juga masih ada meskipun kamu sudah membuka beberapa halaman berbeda.
Padahal HTTP pada dasarnya tidak otomatis mengingat bahwa request sekarang berasal dari pengguna yang sama dengan request sebelumnya.
Untuk mempertahankan keadaan atau state tersebut, website biasanya menggunakan mekanisme seperti cookie dan session.
Keduanya sering disebut bersamaan, tetapi sebenarnya cookie dan session bukan hal yang sama. Cookie disimpan dan dikirim oleh browser, sedangkan session biasanya merupakan data yang dikelola di sisi server dan sering dihubungkan ke browser melalui sebuah session ID.
Memahami perbedaannya penting untuk troubleshooting login, authentication, web application, API, testing browser, proxy, load balancing, maupun keamanan aplikasi.
Kenapa Website Membutuhkan Cookie atau Session?
HTTP bersifat stateless secara desain dasar.
Bayangkan request pertama:
kemudian request berikutnya:
Tanpa mekanisme state tambahan, server perlu cara untuk mengetahui apakah kedua request tersebut berasal dari pengguna yang sama dan apakah pengguna sudah berhasil login.
Di sinilah cookie dan session sering digunakan.
Apa Itu Cookie?
Cookie adalah data kecil berbentuk pasangan nama dan nilai yang disimpan oleh user agent seperti browser dan dikirim kembali pada request yang sesuai.
Contohnya:
Server dapat meminta browser menyimpan cookie melalui response header:
Pada request berikutnya browser dapat mengirim:
Dengan begitu server dapat mengenali state yang berkaitan dengan browser tersebut.
Bagaimana Alur Cookie Bekerja?
Login
session_id=abc123
Cookie: abc123
Apa Itu Session?
Session adalah state sementara yang biasanya dikelola server untuk menyimpan informasi mengenai interaksi pengguna.
Contohnya server menyimpan:
Browser tidak harus menyimpan seluruh data tersebut.
Browser biasanya hanya menyimpan identifier:
Server kemudian memakai ID tersebut untuk mencari data session.
Cookie dan Session Bekerja Bersama
Ini bagian yang sering membuat bingung.
Cookie dan session bukan dua mekanisme yang selalu berdiri sendiri.
Sering kali session menggunakan cookie sebagai penghubung.
Cookie session_id
Session Store
Contoh Login dengan Session
Misalnya pengguna login.
1. Browser Mengirim Credential
2. Server Memverifikasi Login
Jika benar, server membuat session:
3. Server Menyimpan Session
4. Browser Mendapat Cookie
5. Request Berikutnya
Server membaca ID tersebut lalu mengetahui pengguna mana yang sedang login.
Cookie vs Session Apa Bedanya?
| Aspek | Cookie | Session |
|---|---|---|
| Lokasi utama | Browser/client | Server/session store |
| Isi | Nama dan nilai | State aplikasi |
| Dikirim setiap request | Cookie yang cocok bisa dikirim | Data session tidak dikirim seluruhnya |
| Identifikasi | Bisa menyimpan identifier | Sering dicari melalui session ID |
| Ukuran | Relatif kecil | Dapat menyimpan state lebih kompleks di server |
Apakah Session Selalu Menggunakan Cookie?
Tidak harus.
Session identifier secara teori dapat dibawa melalui mekanisme lain.
Tetapi pada aplikasi web browser modern, cookie merupakan salah satu cara paling umum untuk membawa session ID.
Apa Itu Session ID?
Session ID adalah identifier yang menghubungkan client dengan session tertentu di server.
Contohnya:
Server kemudian mempunyai mapping:
Session ID harus dibuat cukup sulit ditebak jika digunakan untuk authentication.
Apakah Data User Sebaiknya Disimpan Langsung di Cookie?
Untuk data sensitif, biasanya lebih aman menyimpan identifier session daripada seluruh informasi sensitif langsung di cookie.
Contoh yang lebih baik:
daripada:
Data cookie berada di sisi client dan pengguna dapat melihat atau memodifikasi data tertentu jika aplikasi tidak melindunginya dengan benar.
Apa Itu Set-Cookie?
Set-Cookie adalah response header yang digunakan server untuk meminta browser menyimpan cookie.
Set-Cookie juga dapat mempunyai atribut:
Apa Itu Cookie Header?
Browser mengirim cookie kembali melalui request header:
Kalau ada beberapa cookie:
Apa Itu Session Cookie?
Session cookie biasanya merujuk pada cookie yang tidak memiliki expiration persisten seperti Expires atau Max-Age.
Contoh:
Secara umum cookie tersebut ditujukan bertahan selama browser session.
Namun browser dapat mempunyai session restore behavior, sehingga detail masa hidup sebenarnya dapat berbeda.
Apa Itu Persistent Cookie?
Persistent cookie mempunyai waktu expiration.
Contoh:
Nilai tersebut membuat cookie dapat bertahan lebih lama daripada satu browser session.
Expires vs Max-Age
Ada dua atribut umum untuk masa hidup cookie.
| Atribut | Fungsi |
|---|---|
| Expires | Menentukan tanggal expiration absolut. |
| Max-Age | Menentukan masa hidup relatif dalam detik. |
MDN merekomendasikan Max-Age sebagai pilihan yang lebih sederhana pada banyak kasus dan menjelaskan bahwa Max-Age memiliki precedence jika keduanya digunakan. :chatgpt-content-reference{index="1"}
Contoh Max-Age
86400 detik sama dengan sekitar satu hari.
Cara Menghapus Cookie
Server dapat mengirim cookie dengan nama, domain, dan path yang sesuai lalu membuat expiration-nya habis.
Contoh:
Browser kemudian menghapus cookie tersebut sesuai rule-nya.
Apa Itu Domain Attribute?
Domain menentukan host mana yang dapat menerima cookie.
Contohnya:
Scope domain perlu dibuat sesempit yang memang diperlukan.
Apa Itu Path Attribute?
Path membatasi path URL tempat cookie dikirim.
Contoh:
Cookie tersebut terkait dengan path tertentu sesuai aturan cookie.
Apa Itu Secure Cookie?
Atribut Secure meminta browser mengirim cookie melalui koneksi secure seperti HTTPS.
Untuk session authentication, penggunaan Secure sangat penting saat aplikasi berjalan melalui HTTPS.
MDN merekomendasikan penggunaan Secure untuk cookie sensitif agar cookie tidak dikirim melalui koneksi HTTP biasa. :chatgpt-content-reference{index="2"}
Apa Itu HttpOnly?
HttpOnly membatasi akses JavaScript seperti:
terhadap cookie tersebut.
Contohnya:
Ini sangat berguna untuk session identifier karena dapat mengurangi risiko pencurian session ID melalui JavaScript ketika terjadi XSS.
Secure vs HttpOnly
| Atribut | Melindungi dari |
|---|---|
| Secure | Mencegah pengiriman cookie melalui HTTP biasa. |
| HttpOnly | Mencegah akses cookie melalui JavaScript tertentu. |
Keduanya mempunyai fungsi berbeda dan sering digunakan bersama.
Apa Itu SameSite?
SameSite mengontrol apakah cookie dikirim pada request cross-site tertentu.
Nilainya antara lain:
Atribut ini membantu mengurangi risiko tertentu seperti CSRF dan mengontrol penggunaan cookie lintas site. :chatgpt-content-reference{index="3"}
Apa Itu SameSite=Strict?
Strict merupakan opsi paling ketat.
Cookie hanya dikirim pada kondisi same-site yang memenuhi aturan browser.
Ini cocok untuk cookie yang tidak perlu dikirim saat navigasi berasal dari site lain.
Apa Itu SameSite=Lax?
Lax lebih fleksibel.
Browser masih dapat mengirim cookie dalam beberapa top-level navigation yang berasal dari site lain.
Apa Itu SameSite=None?
None digunakan ketika cookie memang perlu dikirim pada cross-site context.
Pada browser modern, SameSite=None perlu dipasangkan dengan Secure. :chatgpt-content-reference{index="4"}
Menguji Session dari Jalur Proxy Berbeda?
GudangProxy menyediakan daftar proxy gratis berdasarkan negara, protokol, tingkat anonimitas, dan status koneksi. Kamu dapat memakai endpoint yang sesuai untuk testing website atau aplikasi yang memang kamu kelola sambil memperhatikan bahwa cookie, session, dan IP merupakan state yang berbeda.
Lihat Daftar Proxy Gratis →Apa Hubungan Cookie dengan Login?
Website sering menggunakan cookie untuk menyimpan session ID setelah login.
Contoh:
Karena itu menghapus cookie session sering membuat pengguna logout.
Kenapa Menghapus Cookie Bisa Membuat Logout?
Misalnya server mempunyai:
Browser sebelumnya menyimpan:
Setelah cookie dihapus, browser tidak lagi mengirim session ID.
Server kemudian tidak mempunyai identifier untuk menghubungkan request dengan session sebelumnya.
Apakah Session Server Langsung Hilang Saat Cookie Dihapus?
Belum tentu.
Browser hanya kehilangan identifier.
Data session di server mungkin masih ada sampai:
- expired,
- logout diproses,
- session store dibersihkan,
- administrator menghapusnya.
Logout yang Baik Harus Bagaimana?
Logout idealnya tidak hanya menghapus cookie di browser.
Server juga sebaiknya menginvalidasi session yang berkaitan.
Dengan begitu session ID lama tidak bisa digunakan kembali.
Apa Itu Session Expiration?
Session server biasanya mempunyai batas waktu.
Contohnya:
atau:
Application dapat mempunyai policy berbeda sesuai kebutuhan keamanan.
Idle Timeout vs Absolute Timeout
| Jenis | Arti |
|---|---|
| Idle Timeout | Session expired setelah tidak aktif selama periode tertentu. |
| Absolute Timeout | Session expired setelah umur maksimum tercapai. |
Apa Itu Remember Me?
Fitur Remember Me biasanya membuat authentication bertahan lebih lama dibanding session login biasa.
Implementasinya dapat menggunakan:
- persistent token,
- cookie jangka panjang,
- server-side token store.
Jangan sekadar membuat session ID biasa hidup selamanya.
Apa Itu Session Fixation?
Session fixation adalah kondisi ketika attacker berusaha membuat korban menggunakan session identifier yang sudah diketahui attacker.
Karena itu setelah authentication berhasil, aplikasi sebaiknya membuat atau melakukan regenerasi session identifier.
MDN juga merekomendasikan regenerasi session cookie saat user melakukan authentication untuk membantu mencegah session fixation. :chatgpt-content-reference{index="5"}
Apa Itu Session Hijacking?
Session hijacking terjadi ketika pihak lain memperoleh session identifier yang valid lalu menggunakannya untuk menyamar sebagai session pengguna tersebut.
Risikonya meningkat jika:
- session ID bocor,
- cookie tidak memakai Secure,
- XSS mencuri cookie tanpa HttpOnly,
- session terlalu lama hidup,
- logout tidak menginvalidasi session.
Apakah Cookie Dienkripsi?
Tidak otomatis.
Cookie merupakan data.
HTTPS melindungi transport ketika cookie dikirim melalui koneksi TLS, tetapi nilai cookie itu sendiri tidak otomatis terenkripsi hanya karena disebut cookie.
Aplikasi dapat menggunakan signing atau encryption tambahan jika diperlukan.
Apakah Cookie Bisa Diubah Pengguna?
Secara umum pengguna mempunyai kontrol terhadap data pada browser mereka sendiri.
Karena itu aplikasi tidak boleh mempercayai nilai client-side secara buta.
Contoh buruk:
lalu server langsung mempercayai nilai tersebut tanpa validasi.
Cookie Sebaiknya Menyimpan Apa?
Contoh penggunaan yang umum:
- session identifier,
- language preference,
- theme,
- consent preference,
- shopping cart identifier.
Hindari menyimpan data sensitif mentah tanpa alasan.
Cookie vs Local Storage
Browser juga memiliki Web Storage seperti localStorage.
Keduanya berbeda.
| Aspek | Cookie | localStorage |
|---|---|---|
| Dikirim otomatis ke server | Bisa, jika scope cocok | Tidak |
| Diakses JavaScript | Bisa kecuali HttpOnly | Ya |
| Umum untuk session ID | Ya | Perlu pertimbangan keamanan khusus |
Apa Hubungan Cookie dengan HTTP Header?
Cookie bekerja melalui HTTP header:
Jadi artikel kemarin tentang HTTP Header merupakan fondasi untuk memahami bagaimana cookie berpindah antara browser dan server.
Proxy Mengubah Cookie?
Proxy biasa tidak otomatis menghapus atau mengganti cookie.
Alurnya bisa tetap:
Kecuali proxy memang dikonfigurasi untuk memodifikasi header atau content tertentu.
Ganti Proxy Apakah Session Ikut Berubah?
Tidak otomatis.
Misalnya:
Kalau browser yang sama tetap membawa cookie abc123, website masih dapat menghubungkan request dengan session yang sama.
IP Berubah tetapi Cookie Tetap Sama
Contohnya:
IP: Indonesia
Cookie: session=abc123
Request 2
IP: Singapore
Cookie: session=abc123
Server dapat melihat bahwa IP berubah tetapi session identifier tetap sama.
Bagaimana server memperlakukan kondisi tersebut tergantung security policy aplikasi.
Website Bisa Mengikat Session ke IP?
Bisa, tetapi tidak selalu.
Beberapa aplikasi dapat menggunakan perubahan IP sebagai sinyal keamanan.
Namun mengikat session secara terlalu ketat ke satu IP juga bisa menyebabkan masalah untuk pengguna yang:
- berpindah WiFi/mobile,
- menggunakan CGNAT,
- mempunyai dynamic IP,
- berada pada jaringan yang exit IP-nya berubah.
Proxy Rotating dan Session
Rotating proxy dapat mengubah exit IP antarrequest.
Kalau website mempertahankan session melalui cookie, session browser masih bisa sama meskipun IP berubah.
Tetapi website dapat mempunyai security rule yang menganggap perubahan IP terlalu sering sebagai aktivitas tidak biasa.
Sticky Proxy dan Login Session
Untuk testing alur yang membutuhkan konsistensi network, sticky session proxy dapat mempertahankan exit IP untuk beberapa waktu.
Hal ini berbeda dari session aplikasi, tetapi keduanya sama-sama menggunakan istilah “session”.
Proxy Session vs Website Session
| Jenis | Fungsi |
|---|---|
| Proxy Sticky Session | Mempertahankan exit proxy/IP tertentu. |
| Web Session | Mempertahankan state pengguna pada aplikasi. |
Cookie dan Geo Testing
Cookie dapat memengaruhi hasil geo testing.
Misalnya website menyimpan:
Kamu kemudian mengganti proxy ke Singapura.
Website dapat tetap menggunakan preference dari cookie dan menampilkan versi Indonesia.
Karena itu untuk pengujian lokasi, jangan hanya melihat exit IP.
Baca juga Proxy Geolocation.
Kenapa Incognito Berguna untuk Testing?
Incognito/private window biasanya memulai storage yang lebih terpisah dari browser session normal.
Ini membantu mengurangi pengaruh:
- cookie lama,
- session lama,
- local storage tertentu.
Tetapi incognito tidak otomatis mengubah:
- public IP,
- timezone,
- DNS,
- User-Agent.
Cookie dan Browser Profile
Browser profile berbeda dapat mempunyai cookie store berbeda.
Contohnya:
Ini sering lebih rapi daripada terus menghapus cookie satu per satu saat testing.
Session dan Load Balancer
Pada aplikasi dengan banyak backend server:
Session harus tetap dapat diakses meskipun request berikutnya masuk ke backend berbeda.
Masalah Session Jika Disimpan Lokal di Satu Server
Misalnya:
Pengguna bisa terlihat logout secara acak.
Solusi Shared Session Store
Application dapat menggunakan central session store seperti:
- Redis,
- database,
- distributed cache.
Dengan begitu semua backend dapat membaca session yang sama.
Apa Itu Sticky Session Load Balancer?
Load balancer dapat mengarahkan satu pengguna ke backend yang sama selama periode tertentu.
Contohnya:
Ini disebut session persistence atau sticky session dalam konteks load balancing.
Lagi-lagi ini berbeda dari cookie/session browser itu sendiri, walaupun cookie bisa dipakai sebagai mekanisme routing.
Cookie Bisa Digunakan Load Balancer?
Bisa.
Load balancer tertentu dapat menggunakan cookie untuk mempertahankan affinity ke backend tertentu.
Contoh konseptual:
Request berikutnya diarahkan kembali ke Server A.
Session pada API
API tidak selalu menggunakan browser session.
Banyak API menggunakan token seperti:
Tetapi API berbasis browser masih dapat menggunakan cookie session.
Cookie Authentication vs Bearer Token
| Aspek | Cookie Session | Bearer Token |
|---|---|---|
| Transport umum | Cookie header | Authorization header |
| Browser otomatis kirim | Ya, sesuai scope | Biasanya aplikasi menambahkan sendiri |
| CSRF concern | Perlu diperhatikan | Berbeda tergantung storage/implementation |
Apa Itu CSRF?
Cross-Site Request Forgery terjadi ketika browser yang sudah login dibuat mengirim request yang tidak diinginkan ke website lain dengan credential yang otomatis terbawa.
SameSite membantu mengurangi sebagian risiko tersebut.
Aplikasi juga dapat menggunakan anti-CSRF token sesuai arsitekturnya.
Apa Itu XSS dan Hubungannya dengan Cookie?
Cross-Site Scripting memungkinkan script berbahaya berjalan dalam konteks website jika aplikasi mempunyai vulnerability.
Kalau cookie session dapat diakses JavaScript:
script bisa mencoba membacanya.
Karena itu session cookie biasanya sebaiknya menggunakan HttpOnly.
Cookie yang Lebih Aman
Contoh konfigurasi session cookie:
Konfigurasi ideal tetap harus disesuaikan dengan kebutuhan aplikasi.
Apa Itu __Secure- Prefix?
Browser modern mendukung prefix tertentu untuk menambahkan requirement keamanan pada cookie.
Contoh:
Cookie dengan prefix tersebut perlu mengikuti requirement seperti penggunaan Secure pada secure origin yang mendukung mekanisme ini. :chatgpt-content-reference{index="6"}
Apa Itu __Host- Prefix?
__Host- memberikan constraint lebih ketat.
Contohnya:
Cookie jenis ini tidak menggunakan Domain dan scope-nya dibatasi ke host yang menetapkannya sesuai aturan browser yang mendukung prefix tersebut. :chatgpt-content-reference{index="7"}
Third-Party Cookie
Third-party cookie berkaitan dengan cookie yang digunakan pada cross-site context.
Contohnya sebuah website memuat content dari domain lain:
Kebijakan browser modern semakin membatasi third-party cookie karena alasan privacy. :chatgpt-content-reference{index="8"}
First-Party vs Third-Party Cookie
| Jenis | Konteks |
|---|---|
| First-party | Cookie berkaitan dengan site yang sedang dikunjungi. |
| Third-party | Cookie digunakan pada cross-site embedded/request context. |
Kenapa Cookie Tidak Muncul?
Beberapa penyebab umum:
- Domain salah,
- Path tidak cocok,
- cookie sudah expired,
- Secure cookie digunakan lewat HTTP,
- SameSite memblokir cross-site request,
- browser privacy policy,
- third-party cookie diblokir.
Kenapa Session Sering Hilang?
Penyebabnya bisa:
- cookie session hilang,
- session expired,
- session store restart,
- load balancer salah konfigurasi,
- domain cookie salah,
- Path salah,
- HTTPS/Secure mismatch,
- session ID tidak diregenerasi dengan benar.
Troubleshooting Cookie dan Session
1. Buka Developer Tools
Lihat apakah cookie memang tersimpan.
2. Cek Network Request
Pastikan browser benar-benar mengirim cookie.
3. Cek Response
Pastikan server mengirim cookie dengan atribut yang sesuai.
4. Cek Expiration
Pastikan cookie belum expired.
5. Cek Domain dan Path
Cookie mungkin tersimpan tetapi tidak cocok dengan URL yang sedang dibuka.
6. Cek Session Store
Pastikan session ID masih ada di server.
Cara Melihat Cookie dengan cURL
Response header dapat dilihat dengan:
Atau verbose:
Menyimpan Cookie dengan cURL
Gunakan cookie jar:
File tersebut dapat menyimpan cookie yang diterima.
Mengirim Cookie Kembali
Dengan pola ini kamu bisa melakukan debugging flow session secara lebih terkontrol.
Cookie dan Proxy dengan cURL
Kamu juga bisa menggabungkan proxy dan cookie jar:
Ini membantu membedakan:
- masalah session,
- masalah cookie,
- masalah proxy,
- masalah IP.
Ganti Proxy tapi Gunakan Cookie Lama?
Bisa secara teknis jika aplikasi memperbolehkannya.
Namun hasilnya tergantung policy server.
Server bisa:
- menerima session,
- meminta login ulang,
- melakukan verification tambahan,
- menandai perubahan IP sebagai risk signal.
Cookie dan Browser Fingerprinting Berbeda
Cookie adalah state eksplisit yang disimpan browser.
Fingerprinting menggunakan kombinasi karakteristik browser/device untuk mencoba membedakan client.
Jadi menghapus cookie tidak otomatis menghapus semua signal lain yang dapat digunakan website.
Topik browser fingerprinting sebaiknya dibahas terpisah karena intent-nya berbeda.
Cookie dan Cache Juga Berbeda
Cookie menyimpan state.
Cache menyimpan salinan resource untuk mengurangi transfer ulang.
| Fitur | Cookie | Cache |
|---|---|---|
| Tujuan utama | Menyimpan state/identifier | Menyimpan response/resource |
| Contoh | session_id | CSS, JS, image, response |
Kesalahan Umum Tentang Cookie dan Session
- menganggap cookie dan session adalah hal yang sama,
- menganggap session selalu disimpan di browser,
- menyimpan data sensitif mentah di cookie,
- menganggap Secure sama dengan HttpOnly,
- menganggap SameSite=None tidak membutuhkan Secure,
- tidak menginvalidasi session saat logout,
- menggunakan session ID yang terlalu mudah ditebak,
- menganggap ganti proxy otomatis membuat session baru,
- menganggap IP dan session adalah identitas yang sama,
- mengabaikan expiration cookie.
Checklist Session Cookie yang Baik
| Bagian | Yang Dicek |
|---|---|
| Session ID | Random dan sulit ditebak. |
| Secure | Aktif pada HTTPS. |
| HttpOnly | Aktif jika JavaScript tidak perlu mengakses cookie. |
| SameSite | Disesuaikan dengan flow aplikasi. |
| Path | Dibuat sesempit yang diperlukan. |
| Domain | Tidak dibuat terlalu luas. |
| Expiration | Tidak terlalu panjang. |
| Logout | Session server diinvalidasi. |
| Login | Session identifier diregenerasi. |
FAQ Cookie vs Session
Apa beda cookie dan session?
Cookie disimpan pada browser/client dan dapat dikirim pada HTTP request, sedangkan session biasanya merupakan state yang disimpan di sisi server dan dihubungkan ke client melalui session identifier.
Apakah session disimpan di cookie?
Biasanya yang disimpan di cookie adalah session ID, bukan seluruh data session. Data session utamanya tetap berada di server.
Apa fungsi Set-Cookie?
Set-Cookie adalah response header yang digunakan server untuk meminta browser menyimpan cookie.
Apa fungsi Cookie header?
Cookie header digunakan browser untuk mengirim kembali cookie yang berlaku kepada server.
Apa fungsi Secure?
Secure membatasi cookie agar dikirim melalui koneksi secure seperti HTTPS.
Apa fungsi HttpOnly?
HttpOnly mencegah JavaScript biasa seperti document.cookie mengakses cookie tersebut.
Apa fungsi SameSite?
SameSite mengontrol kapan cookie dikirim pada request cross-site dan dapat membantu mengurangi risiko CSRF serta kebocoran cookie lintas site.
Apakah mengganti proxy membuat session baru?
Tidak otomatis. Jika browser masih membawa session cookie yang sama, website masih dapat mengenali session yang sama meskipun exit IP berubah.
Kenapa saya logout setelah menghapus cookie?
Karena browser kehilangan session identifier yang digunakan server untuk menghubungkan request dengan session login sebelumnya.
Apakah session ID harus dirahasiakan?
Ya. Session ID authentication harus diperlakukan seperti credential sementara karena pihak yang memperoleh session ID valid bisa berpotensi menyalahgunakannya.