Cookie dan HTTP: Bagaimana Situs Mengingatmu

Coba pikirkan teka-teki kecil ini. Kamu login ke sebuah situs, klik sana-sini selama sepuluh menit, dan situs itu terus menganggapmu sebagai orang yang sama sepanjang waktu. Padahal HTTP, protokol yang dipakai browser untuk berkomunikasi dengan situs tersebut, sama sekali tidak punya ingatan bawaan. Setiap permintaan yang dikirim browser tiba seolah-olah server belum pernah melihatmu. Lalu bagaimana situs tahu bahwa kamu masih orang yang sama pada klik berikutnya?

Jawabannya, dalam banyak kasus, adalah cookie. Cookie adalah potongan teks mungil yang diberikan server ke browser-mu, lalu server meminta browser menyimpannya. Sejak saat itu, browser-mu diam-diam menempelkan teks tersebut ke setiap permintaan yang dikirim kembali ke situs yang sama. Perjalanan bolak-balik kecil itulah yang membuat protokol “tanpa ingatan” terlihat seakan punya memori. Di artikel ini kita akan melihat persis bagaimana itu bekerja di level HTTP, header apa saja yang terlibat, dan atribut yang mengatur perilaku cookie.

HTTP disebut bersifat stateless. Istilahnya terdengar teknis, tapi idenya sederhana: server tidak otomatis mengingat apa pun antara satu permintaan dan permintaan berikutnya. Tiap permintaan berdiri sendiri. Bayangkan kamu bicara dengan seorang petugas yang ingatannya selalu kosong. Kamu sebutkan namamu, dia membantumu, dan begitu kamu beranjak pergi, dia langsung melupakanmu. Datang lagi dua detik kemudian, kamu harus memperkenalkan diri dari awal.

Desain seperti itu sebenarnya kelebihan, bukan kekurangan. Server jadi lebih sederhana, dan situs besar bisa membagi permintaan ke banyak mesin tanpa setiap mesin harus melacak siapa kamu. Tapi muncul masalah nyata: keranjang belanja, status login, pilihan bahasa, sampai fitur “tetap masuk” semuanya butuh server mengenalimu di banyak permintaan.

Cookie menyelesaikan ini dengan trik ringan yang cerdik. Alih-alih server menyimpan ingatan tentangmu, dia memberi kamu secarik catatan untuk dibawa, dan browser-mu menunjukkan catatan itu setiap kali kembali. Si petugas pelupa tadi memberimu nomor antrean; kamu tunjukkan nomornya pada kunjungan berikutnya, lalu dia mencari semua data yang terkait nomor tersebut.

Cookie sepenuhnya hidup di dalam header HTTP. Hanya ada dua yang perlu kamu tahu, dan keduanya berpasangan.

Server menetapkan cookie lewat header Set-Cookie di dalam respons-nya. Browser mengirim cookie kembali lewat header Cookie di dalam permintaan-nya. Itu saja seluruh mekanismenya.

Header	Arah	Pengirim	Tujuan
`Set-Cookie`	Respons	Server → browser	“Tolong simpan nilai ini untukku.”
`Cookie`	Permintaan	Browser → server	“Ini nilai yang tadi kamu minta kusimpan.”

Mari lihat saat berjalan. Bayangkan kamu mengunjungi acy-partner.com untuk pertama kalinya. Respons server menyertakan header yang menyuruh browser-mu mengingat sebuah nilai:

HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: session_id=abc123

Browser-mu membaca baris Set-Cookie itu, menyimpan cookie-nya (nama session_id dengan nilai abc123), dan sejak saat itu setiap permintaan yang dibuat browser ke acy-partner.com otomatis membawanya kembali:

GET /account HTTP/1.1
Host: acy-partner.com
Cookie: session_id=abc123

Perhatikan, kamu tidak menulis satu pun dari semua ini. Browser yang mengurus semuanya. JavaScript di halaman tidak perlu menempelkan apa-apa, dan tentu saja kamu tidak mengetiknya. Begitu cookie tersimpan, pengirimannya kembali berjalan otomatis.

  ┌──────────┐                                   ┌──────────┐
  │ Browser  │  ── GET / ──────────────────────▶ │  Server  │
  │          │  ◀── 200 OK  Set-Cookie: id=abc ─ │          │
  │ (simpan  │                                   │          │
  │  cookie) │  ── GET /account ──────────────▶  │          │
  │          │      Cookie: id=abc               │ (tahu    │
  │          │  ◀── 200 OK (personal) ────────── │  ini kamu)│
  └──────────┘                                   └──────────┘

Cookie hanyalah teks

Tidak ada yang ajaib dari cookie. Ia cuma pasangan nama=nilai berupa teks biasa, biasanya kecil (paling banter beberapa kilobita). Server yang menentukan isinya, dan tugas browser hanya menyimpan lalu mengirimkannya kembali ke situs yang tepat.

Nilai sebuah cookie bisa berisi hampir apa saja yang diinginkan server, selama muat dalam batas ukuran dan menghindari karakter tertentu. Dalam praktiknya, situs memakai salah satu dari dua gaya.

Gaya pertama menyimpan informasi sungguhan langsung di cookie. Misalnya, preferensi seperti theme=dark atau lang=id bisa berada langsung di nilai cookie, dan server membacanya di setiap permintaan.

Gaya kedua, yang jauh lebih umum untuk apa pun yang sensitif, hanya menyimpan sebuah pengenal yang tak bermakna sendiri. Cookie-nya berisi sesuatu yang kalau dilihat sendirian tidak ada artinya, seperti session_id=abc123, sementara data aslinya tersimpan aman di server dan dicari berdasarkan ID itu. Inilah pola di balik sesi login: cookie cuma karcis pengambilan, dan barang berharganya tetap di balik meja.

Bagaimana server memakai cookie sesi untuk menjagamu tetap login adalah topik tersendiri, dan itu masuk ranah autentikasi, bukan mekanisme HTTP murni. Di sini kita fokus pada pengangkutannya: bagaimana nilai itu berpindah antara browser dan server, bukan apa yang dilakukan server setelah nilai itu tiba.

Sebuah header Set-Cookie bisa membawa lebih dari sekadar nama dan nilai. Setelah nilainya, server boleh menambahkan atribut, dipisah dengan titik koma, yang mengatur berapa lama cookie hidup dan ke mana browser boleh mengirimnya. Di atribut inilah cookie jadi menarik, dan di sinilah banyak aspek keamanan bergantung.

Set-Cookie: session_id=abc123; Expires=Wed, 30 Sep 2026 10:00:00 GMT; Secure; HttpOnly; SameSite=Lax

Mari kita bedah yang paling penting.

Expires (dan Max-Age): berapa lama bertahan

Secara bawaan, cookie tanpa masa berlaku adalah session cookie — ia hidup hanya sampai kamu menutup browser, lalu lenyap. Agar cookie bertahan lebih lama, server menambahkan tanggal kedaluwarsa.

Atribut Expires memberi tanggal dan waktu pasti, setelah itu browser harus membuang cookie tersebut. Saudara dekatnya, Max-Age, melakukan hal sama tapi menghitung dalam detik dari sekarang (misalnya, Max-Age=3600 berarti satu jam). Kalau keduanya ada, Max-Age yang menang.

Set-Cookie: lang=id; Max-Age=31536000

Cookie itu berkata “ingat pilihan bahasa selama setahun.” Begitulah situs bisa mengenalimu beberapa hari atau minggu kemudian tanpa memaksamu login setiap berkunjung.

Secure: hanya lewat HTTPS

Atribut Secure menyuruh browser mengirim cookie hanya melalui koneksi HTTPS yang terenkripsi, tidak pernah lewat HTTP biasa. Ini penting karena cookie yang dikirim lewat koneksi tanpa enkripsi bisa terbaca oleh siapa pun yang mengintai jaringan. Untuk cookie apa pun yang mengidentifikasi pengguna, Secure sebaiknya dianggap wajib.

HttpOnly: tersembunyi dari JavaScript

Biasanya, JavaScript yang berjalan di sebuah halaman bisa membaca cookie lewat document.cookie. Atribut HttpOnly mematikan akses itu: cookie bertanda HttpOnly tak terlihat oleh JavaScript dan hanya dikirim di dalam header HTTP.

Kenapa kamu menginginkannya? Karena kalau penyerang berhasil menyusupkan skrip jahat ke sebuah halaman, hal pertama yang sering dicoba adalah mencuri cookie sesi. Menandai cookie sesi dengan HttpOnly berarti, bahkan ketika penyusupan skrip berhasil, skrip itu tetap tidak bisa membacanya. Cookie-nya masih bekerja sempurna untuk server, ia hanya berada di luar jangkauan kode halaman.

HttpOnly bukan salah ketik

Namanya membingungkan bagi pemula. HttpOnly bukan berarti “hanya lewat HTTP” (itu justru kebalikan dari aman). Artinya “hanya bisa diakses lewat header HTTP, bukan lewat JavaScript.” Pasangkan dengan Secure untuk cookie yang sensitif.

SameSite: mengatur pengiriman lintas situs

Atribut SameSite menentukan apakah sebuah cookie boleh dikirim ketika permintaan datang dari situs yang berbeda. Misalnya kamu sedang login di acy-partner.com, lalu kamu klik sebuah tautan di situs lain yang mengarah balik ke sana. Apakah cookie-mu ikut menumpang di permintaan itu? SameSite menjawab pertanyaan tersebut.

Nilai	Perilaku
`Strict`	Cookie hanya dikirim ketika permintaan berasal dari situs yang sama. Perlindungan maksimal, tapi bisa membuatmu seperti keluar (logout) saat tiba dari tautan eksternal.
`Lax`	Cookie dikirim untuk permintaan satu situs dan untuk navigasi tingkat atas (seperti mengklik tautan), tapi tidak untuk kebanyakan permintaan latar lintas situs. Default yang masuk akal.
`None`	Cookie dikirim di semua permintaan, termasuk yang lintas situs. Wajib digabung dengan `Secure`.

SameSite ada terutama untuk mengurangi sejenis serangan ketika situs jahat menipu browser-mu agar membuat permintaan ke situs tempat kamu login, sambil menumpangi cookie-mu. Dengan membatasi pengiriman lintas situs, browser menutup sebagian besar celah itu. Browser modern memperlakukan Lax sebagai default ketika SameSite tidak disetel.

Dua atribut lagi menentukan cakupan sebuah cookie. Domain mengatur host mana saja yang akan menerima cookie, dan Path mengatur URL mana saja di dalam host itu.

Secara bawaan, cookie milik host persis yang menetapkannya. Kalau acy-partner.com menetapkan cookie tanpa atribut Domain, browser hanya mengirimnya kembali ke acy-partner.com, tidak ke blog.acy-partner.com. Menyetel Domain=acy-partner.com secara eksplisit memperluasnya hingga mencakup subdomain juga.

Atribut Path mempersempit dari arah berbeda. Path=/account berarti cookie hanya ditempelkan ke permintaan yang URL-nya diawali /account. Kalau tidak disetel, biasanya ia mengikuti path halaman yang menetapkannya, dan kebanyakan situs cukup memakai Path=/ agar mencakup seluruh situs.

Satu Set-Cookie per cookie

Kalau server ingin menetapkan beberapa cookie dalam satu respons, dia mengirim header Set-Cookie terpisah untuk masing-masing. Ia tidak menjejalkan semuanya ke satu baris. Sebaliknya, browser membungkus semua cookie yang dikirim balik ke dalam satu header Cookie, dipisah dengan titik koma.

Kamu tidak butuh alat khusus untuk menyaksikan ini terjadi. Buka developer tools di browser-mu (sering kali dengan menekan F12), masuk ke tab Network, lalu muat ulang halaman. Klik permintaan mana pun dan kamu bisa membaca header permintaan dan responsnya — termasuk Cookie yang keluar dan Set-Cookie yang masuk. Biasanya ada juga tab Application atau Storage yang menampilkan setiap cookie yang disimpan situs, lengkap dengan masa berlaku, tanda Secure, tanda HttpOnly, dan nilai SameSite-nya. Inilah cara paling jelas mengubah artikel ini dari sekadar kata-kata menjadi sesuatu yang bisa kamu utak-atik.

Rangkuman

Cookie adalah jawaban standar atas celah nyata di HTTP: protokolnya melupakanmu di antara permintaan, dan cookie memberinya cara untuk mengingat. Mekanismenya kecil dan elegan. Server mengirim header Set-Cookie di sebuah respons, browser menyimpan nilainya, lalu sejak itu browser otomatis mengembalikannya lewat header Cookie di setiap permintaan yang cocok.

Di sekitar inti itu ada atribut-atribut yang membuat cookie aman dan praktis: Expires dan Max-Age menentukan berapa lama cookie hidup, Secure menjaganya tetap di HTTPS, HttpOnly menyembunyikannya dari JavaScript, SameSite membatasi pengiriman lintas situs, sementara Domain dan Path menentukan cakupannya. Memahami fungsi masing-masing mengubah gagasan samar (“situs mengingatku”) menjadi gambaran konkret tentang header yang berpindah bolak-balik.

Dari sini, langkah berikutnya yang wajar adalah melihat bagaimana sesi dan autentikasi dibangun di atas fondasi ini — bagaimana cookie session_id kecil itu menjadi login yang aman. Tapi itu bagian dari sisi server. Bagian HTTP-nya, yang baru saja kamu pelajari, adalah jabat tangan sederhana yang sama yang mendasari semuanya.