Kookie HTTP Cara Membangun dan Membaca Mereka Secara Tepat

Kookie HTTP terse di mana-mana. Setiap sesi login, keranjang belanja, dan alat analitik mengandalkan mereka. Namun sebagian besar pengembang menyalin dan menempelkan sebuah Set-Cookie header dan melanjutkan tanpa memahami apa yang sebenarnya dilakukan oleh atribut-atribut tersebut — atau apa yang terjadi ketika mereka salah.

Panduan ini membahas anatomi kookie, setiap atribut yang bermakna, cara memarsing string kookie, dan mengapa SameSite adalah pertahanan Anda terhadap CSRF. Jika Anda ingin langsung berlatih, coba IO Tools Parser Kookie atau Pembuat Kookie.

Apa Kookie Sebenarnya Terlihat Seperti

Ketika server ingin menetapkan kookie, ia mengirimkan sebuah Set-Cookie header respons:

Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=86400

Browser menyimpan ini dan mengirimkannya kembali pada permintaan berikutnya sebagai:

Cookie: sessionId=abc123

Itu adalah mekanisme keseluruhan. Kompleksitasnya terletak pada atribut-atribut tersebut.

Anatomi Kookie: Memecah String Ini

String kookie mengikuti format yang konsisten:

name=value; attribute1; attribute2=attributeValue; ...

Itu name=value pasangan muncul terlebih dahulu. Semua yang ada setelah tanda koma pertama adalah direktif untuk browser — server tidak melihat atribut-atribut ini dalam Cookie header yang diterimanya.

Atribut Keamanan yang Harus Diperoleh dengan Benar

HttpOnly

HttpOnly mencegah JavaScript membaca kookie melalui document.cookie. Ini merupakan pertahanan langsung terhadap serangan XSS yang mencuri token sesi.

Set-Cookie: sessionId=abc123; HttpOnly

Setiap kookie yang mengautentikasi pengguna harus memiliki HttpOnly. Tidak ada alasan yang baik untuk tidak melakukannya.

Aman

Secure berarti browser hanya mengirim kookie melalui koneksi HTTPS. Tanpa itu, kookie bergerak dalam bentuk teks terbuka melalui HTTP dan dapat diintersepsi. Di produksi, kookie sesi selalu perlu Secure. Di pengembangan lokal pada http://localhost, Anda dapat mengabaikannya — browser membuat pengecualian untuk localhost.

SamaSite

SameSite mengendalikan kapan browser mencantumkan kookie dalam permintaan lintas situs. Ini merupakan pertahanan utama terhadap serangan CSRF. Tiga nilai:

• Strict — kookie tidak dikirimkan dalam permintaan lintas situs. Paling aman, tetapi pengguna yang mengklik tautan dari email akan keluar login (kookie tidak dikirimkan saat navigasi awal tersebut).
• Lax — kookie dikirimkan dalam navigasi tingkat atas (permintaan GET) dari situs eksternal, tetapi tidak dikirimkan dalam permintaan terkandung lintas situs atau permintaan POST lintas situs. Ini adalah default browser untuk kookie tanpa atribut eksplisit SameSite .
• None — kookie dikirimkan dalam semua permintaan lintas situs. Diperlukan untuk kookie pihak ketiga (alur OAuth, widget terkandung). Harus disertai dengan Secure.

# Third-party / cross-site cookie (e.g., OAuth callback)
Set-Cookie: token=xyz; SameSite=None; Secure

Jika Anda mengirim SameSite=None tanpa Secure, browser modern menolak kookie secara keseluruhan. Untuk kebanyakan kookie sesi, gunakan SameSite=Lax — ini menyeimbangkan keamanan dengan pengalaman login yang dapat digunakan.

Lingkup: Domain dan Path

Domai

Itu Domain atribut menentukan host mana yang menerima kookie.

Set-Cookie: user=alice; Domain=example.com

Dengan Domain=example.com, kookie dikirimkan ke example.com dan semua subdomain (api.example.com, app.example.com). Tanpa atribut Domain , kookie hanya dikirimkan ke asal yang tepat yang menetapkannya — bukan ke subdomain.

Pemahaman umum: mengatur Domain=example.com tidak bukan mengurangi kookie hanya ke example.com. Ini memperluas lingkup untuk mencakup subdomain. Hapus atribut jika Anda ingin kookie berbasis satu host.

Jalur

Path mengatur URL path mana yang memicu kookie dikirimkan.

Set-Cookie: adminToken=xyz; Path=/admin

Kookie ini hanya mengikuti permintaan ke /admin dan jalur di bawahnya. Permintaan ke / atau /api tidak akan mencakupnya. Defaultnya adalah /, yang berarti semua jalur.

Max-Age vs Expires

Kedua atribut ini mengontrol kapan kookie berakhir. Lebih disarankan menggunakan Max-Age.

• Expires mengambil tanggal absolut dalam format tanggal HTTP. Ini relatif terhadap jam klien yang tidak Anda kendalikan.
• Max-Age mengambil jumlah detik dari sekarang: Max-Age=86400 untuk 24 jam. Relatif terhadap niat server, bukan jam klien.

Ketika keduanya hadir, Max-Age mengambil keunggulan. Kookie dengan tidak ada atribut ini adalah kookie sesi — ia hilang saat browser ditutup.

Referensi Atribut Kookie

Atribut	Apa yang Dilakukan	Bawaan	Rekomendasi
HttpOnly	Menghalangi akses JavaScript terhadap kookie	Tidak diatur	Selalu diatur untuk kookie autentikasi
Secure	Pengiriman hanya melalui HTTPS	Tidak diatur	Selalu diatur di produksi
SameSite	Mengendalikan pengiriman lintas situs	Lax (pada browser modern)	Lax untuk sesi; None + Secure untuk kookie pihak ketiga
Domain	Menetapkan lingkup host	Hanya host saat ini	Hapus kecuali akses lintas subdomain diperlukan
Path	Menetapkan lingkup path	/	Biarkan sebagai / kecuali untuk mengisolasi token admin
Max-Age	Detik hingga kedaluwarsa	Kookie sesi	Lebih disarankan daripada Expires
Expires	Tanggal kedaluwarsa absolut	Kookie sesi	Gunakan Max-Age sebagai gantinya

Pengaturan Kookie dalam Kode

Node.js (Express)

app.post('/login', (req, res) => {
  // ... verify credentials ...

  res.cookie('sessionId', token, {
    httpOnly: true,
    secure: process.env.NODE_ENV === 'production',
    sameSite: 'lax',
    maxAge: 86400 * 1000, // milliseconds in Express
    path: '/',
  });

  res.json({ ok: true });
});

Python (FastAPI)

from fastapi import FastAPI, Response

app = FastAPI()

@app.post("/login")
def login(response: Response):
    # ... verify credentials ...

    response.set_cookie(
        key="sessionId",
        value=token,
        httponly=True,
        secure=True,
        samesite="lax",
        max_age=86400,
        path="/",
    )
    return {"ok": True}

Menguraikan Header Kookie Secara Manual

Itu Cookie header yang diterima oleh server hanya mengandung name=value pasangan, dipisahkan oleh ; :

Cookie: sessionId=abc123; theme=dark; lang=en

Untuk menguraikannya secara manual: bagi pada ; (koma + spasi), lalu bagi setiap pasangan pada pertama = hanya. Kasus-kasus ekstrem yang perlu diketahui:

• Nilai dapat mengandung = (string base64 yang umum) — bagi selalu pada = hanya
• Nama kookie bersifat case-sensitive
• Spasi di sekitar pemisah dapat bervariasi — potong dari kedua sisi secara defensif

Alangkah baiknya tidak menulis logika pembagian sendiri, gunakan IO Tools Parser Kookie untuk mendekodekan setiap Cookie header dan memeriksa nilai masing-masing, atau IO Tools Pembuat Kookie untuk membuat header yang valid dengan atribut yang tepat. Set-Cookie Kookie dan CSRF

Cross-Site Request Forgery memanfaatkan fakta bahwa browser secara otomatis mencantumkan kookie dalam permintaan ke domain, bahkan ketika dimulai oleh situs yang berbeda. Halaman jahat di

dapat mengirimkan formulir ke evil.com , dan jika pengguna sudah login, browser akan mengirimkan token sesi mereka bersama permintaan palsu tersebut. bank.com/transfermenangkal kebanyakan vektor CSRF karena permintaan POST lintas situs — pola serangan khas — tidak mencantumkan kookie.

SameSite=Lax lebih menyeluruh tetapi dapat memengaruhi kenyamanan pengguna. SameSite=Strict Token CSRF tetap valid sebagai pertahanan tambahan, terutama untuk operasi penting dan ketika

diperlukan untuk konteks pihak ketiga. Kedua pertahanan saling melengkapi. SameSite=None diperlukan untuk konteks pihak ketiga. Dua pertahanan saling melengkapi.

Anda mungkin juga menyukai