Parser Set-Cookie

Set-Cookie Parser

Tempel header respons Set-Cookie multi-baris untuk memeriksa atribut dan menandai kombinasi SameSite / Secure yang berisiko.

Kartu Atribut Cookie

2 Set-Cookie

#1sessionabc123

path/

httponly(flag)

secure(flag)

samesiteLax

Tidak ditemukan masalah atribut yang jelas

#2preview1

max-age600 (10m 0s)

setCookieParser.attr.maxAgeHint

samesiteNone

secure(flag)

setCookieParser.warn.missingHttpOnlysetCookieParser.warn.missingPath

Pratinjau JSON

[
  {
    "index": 0,
    "raw": "session=abc123; Path=/; HttpOnly; Secure; SameSite=Lax",
    "name": "session",
    "value": "abc123",
    "decodedValue": "abc123",
    "attributes": [
      {
        "key": "path",
        "value": "/"
      },
      {
        "key": "httponly",
        "value": null
      },
      {
        "key": "secure",
        "value": null
      },
      {
        "key": "samesite",
        "value": "Lax"
      }
    ],
    "attributeMap": {
      "path": "/",
      "httponly": true,
      "secure": true,
      "samesite": "Lax"
    },
    "warnings": []
  },
  {
    "index": 1,
    "raw": "preview=1; Max-Age=600; SameSite=None; Secure",
    "name": "preview",
    "value": "1",
    "decodedValue": "1",
    "attributes": [
      {
        "key": "max-age",
        "value": "600"
      },
      {
        "key": "samesite",
        "value": "None"
      },
      {
        "key": "secure",
        "value": null
      }
    ],
    "attributeMap": {
      "max-age": "600",
      "samesite": "None",
      "secure": true
    },
    "warnings": [
      "warn.missingHttpOnly",
      "warn.missingPath"
    ]
  }
]

Tempelkan header Set-Cookie, Anda akan langsung mendapatkan jawaban mengapa browser tidak menerima Cookie.

Rekomendasi Terkait

Parser Cookie HTTP

Pemeriksa CORS Cross-Origin

Generator CSP

Security.txt Generator

Pemeriksa Rantai Pengalihan

Kasus penggunaan

Saat browser menolak menulis Cookie, cepat mengidentifikasi apakah itu masalah kebijakan SameSite, kurang tanda Secure, atau Path/Domain tidak cocok
Saat Cookie diblokir browser dalam skenario login pihak ketiga/SSO/iframe tersemat, periksa apakah SameSite=None dipasangkan dengan Secure dengan benar
Saat audit keamanan, periksa secara massal apakah Cookie yang dikembalikan antarmuka telah menyetel HttpOnly untuk mencegah pencurian XSS, apakah telah menyetel Secure untuk mencegah transmisi teks jelas HTTP
Saat menggunakan Cookie awalan __Host-/__Secure-, verifikasi apakah memenuhi persyaratan wajib RFC 6265bis untuk menghindari dibuang secara diam-diam oleh browser
Saat debugging solusi partisi Cookie pihak ketiga CHIPS (Partitioned Cookie), konfirmasikan bahwa Partitioned dan Secure dideklarasikan secara bersamaan
Saat server menyetel Max-Age/Expires, konfirmasikan nilai valid, hindari Cookie kedaluwarsa segera karena penyimpangan jam atau Max-Age=0
Bandingkan perbedaan header Set-Cookie antara lingkungan yang berbeda (pengembangan/pengujian/produksi), pecahkan masalah aneh Cookie hilang di lingkungan produksi padahal lingkungan pengembangan normal
Salin seluruh bagian header respons dari DevTools atau curl, tidak perlu menghapus awalan Set-Cookie: secara manual, alat akan otomatis mengenali dan menghapusnya
Saat menulis dokumentasi antarmuka atau bug terkait permintaan WASM/WebWorker, tempelkan langsung hasil JSON yang telah diparse ke dalam dokumen untuk mengilustrasikan struktur Cookie

Fitur

Parsing independen banyak Cookie: Setiap baris Set-Cookie menjadi kartu terpisah, menampilkan nomor urut, nama, nilai dan nilai URL-decode, langsung terlihat Cookie mana yang bermasalah
Pemeriksaan keamanan 14 atribut: Otomatis mengidentifikasi kesalahan umum seperti SameSite=None tanpa Secure, nilai SameSite tidak valid, Partitioned tanpa Secure, kurang HttpOnly, kurang Path, kurang SameSite, pelanggaran awalan __Host-, __Secure- tanpa Secure, Max-Age tidak valid/=0, Domain dimulai dengan titik, Expires tanpa Max-Age, dll.
Pembongkaran lengkap semua atribut: Mencantumkan setiap item SameSite, Secure, HttpOnly, Path, Domain, Expires, Max-Age, Partitioned, atribut tipe flag dan atribut bernilai terlihat jelas
Konversi otomatis Max-Age: Otomatis mengonversi detik menjadi waktu mudah dibaca dalam hari/jam/menit/detik, misalnya Max-Age=2592000 akan ditampilkan sebagai 30d
Tampilan otomatis nilai URL-decode: Saat nilai Cookie berisi encoding %XX, otomatis menampilkan teks asli setelah didekode (misalnya sessionID%3Dabc → sessionID=abc), ditandai dengan panah hijau
Pemeriksaan awalan RFC 6265bis: Memverifikasi secara ketat persyaratan kepatuhan Cookie awalan __Host- dan __Secure-, termasuk Path=/, larangan Domain, harus menyetel Secure
Salin satu klik header asli: Menggabungkan dan menyalin semua baris Set-Cookie asli yang telah diparse, memudahkan untuk menempel ke email, Issue, dokumen untuk dibagikan dengan tim
Pratinjau JSON terstruktur: Hasil parsing mendukung output format JSON, mencakup bidang lengkap name/value/decodedValue/attributes/attributeMap/warnings, dapat digunakan langsung untuk skrip dan kasus uji
Pemrosesan sepenuhnya lokal: Konten Set-Cookie diparse secara lokal di browser, tidak diunggah ke server mana pun, menghindari kebocoran informasi sensitif seperti Session, Token
Lencana peringatan cerdas: Setiap masalah ditandai dengan lencana peringatan oranye dengan alasan spesifik, tidak perlu memeriksa dokumen RFC satu per satu
Input massal banyak baris: Tempelkan seluruh bagian header respons sekaligus (misalnya disalin dari panel Network Chrome DevTools), otomatis menghapus awalan Set-Cookie: dan parsing per baris
Mendukung nilai dengan tanda kutip dan titik koma: Menangani dengan benar nilai Cookie dengan tanda kutip ganda menurut standar RFC dan titik koma dalam tanggal Expires, tidak salah memisahkan

Cara Penggunaan

Buka panel Network DevTools browser, temukan permintaan target, salin konten Set-Cookie di area Response Headers (mendukung banyak baris, salin semua Cookie sekaligus)
Tempelkan header respons Set-Cookie yang disalin ke area input, satu Cookie per baris (tidak perlu menghapus awalan Set-Cookie: secara manual, alat akan otomatis menghapusnya)
Alat memparse secara real-time, bagian atas menampilkan jumlah Set-Cookie yang dikenali, di bawah setiap Cookie independen menjadi satu kartu atribut
Bagian kepala kartu menampilkan nomor urut, nama Cookie, nilai asli; jika nilai berisi encoding URL, nilai setelah didekode akan ditampilkan setelah panah hijau
Bagian utama kartu menampilkan setiap atribut menurut SameSite, Secure, HttpOnly, Path, Domain, Max-Age, Expires, Partitioned, dll., Max-Age akan otomatis disertai tanda kurung konversi waktu mudah dibaca
Bagian bawah kartu menampilkan hasil pemeriksaan: Lencana peringatan oranye menandai masalah spesifik (setiap masalah memiliki penjelasan bahasa Indonesia yang jelas), lencana hijau menunjukkan tidak ditemukan masalah yang jelas
Saat perlu membandingkan konfigurasi server, klik「Salin header asli」untuk menyalin semua baris Set-Cookie asli; saat perlu pemrosesan terprogram, lihat「Pratinjau JSON」

Pertanyaan Umum

Mengapa header Set-Cookie berhasil disetel tetapi browser tidak menyimpan Cookie saya?

Ini adalah masalah paling umum, browser tidak akan secara aktif melaporkan kesalahan melainkan membuang Cookie yang tidak patuh secara diam-diam. Alasan umum meliputi: SameSite=None tanpa Secure, Cookie Secure disetel di halaman HTTP (kecuali localhost), awalan __Host-/__Secure- tidak memenuhi batasan, Domain/Path tidak cocok, melebihi batas ukuran 4KB, Max-Age nol atau negatif. Disarankan tempelkan Set-Cookie terlebih dahulu ke alat ini, lihat lencana peringatan untuk mengidentifikasi penyebab spesifik, kemudian buka Chrome DevTools → Application → Cookies, lihat di bawah nama domain yang sesuai apakah ada segitiga peringatan kuning, arahkan kursor dapat melihat alasan penolakan spesifik.

Apa perbedaan sebenarnya antara Strict, Lax, None dari SameSite? Kapan menggunakan yang mana?

Strict sepenuhnya tidak mengizinkan pengiriman lintas situs, paling aman tetapi pengguna yang mengklik dari tautan luar akan tampak belum login, cocok untuk Cookie operasi sensitif seperti pembayaran/ubah kata sandi. Lax adalah nilai default Chrome 80+, mengizinkan membawa saat menavigasi kembali melalui navigasi GET tingkat atas (mengklik tautan luar kembali ke situs Anda), tetapi tidak membawa dalam sumber daya anak seperti iframe/img/script/XHR/formulir POST, adalah nilai yang disarankan untuk sebagian besar skenario. None mengizinkan pengiriman di semua skenario lintas situs (digunakan untuk login tunggal SSO, iframe tersemat pihak ketiga, panggilan API lintas situs), tetapi harus menyetel Secure secara bersamaan, jika tidak browser akan menolak langsung.

Mengapa SameSite=None harus dipasangkan dengan Secure?

Ini adalah aturan yang diberlakukan wajib oleh Chrome sejak versi 80 (Februari 2020), Firefox, Edge, Safari juga telah mengikuti. Karena SameSite=None secara eksplisit mengizinkan pengiriman Cookie lintas situs, penyerang lebih mudah melakukan serangan CSRF atau penyadapan dalam skenario lintas situs, harus dipasangkan dengan Secure (transmisi terenkripsi HTTPS) untuk mengurangi risiko. Jika Cookie SameSite=None Anda disetel di bawah HTTP, browser akan membuangnya langsung tanpa menyimpan. Alat ini akan mendeteksi kombinasi SameSite=None tanpa Secure dan memberi peringatan merah.

Menggunakan Max-Age atau Expires? Apa perbedaannya?

Utamakan menggunakan Max-Age. Max-Age adalah waktu relatif (kedaluwarsa setelah berapa detik), tidak bergantung pada jam klien, browser mulai menghitung mundur setelah diterima; Expires adalah titik waktu absolut, bergantung pada waktu lokal komputer pengguna (pengguna mengubah jam ke 1970 maka Cookie kedaluwarsa segera). Ketika keduanya ada secara bersamaan, Max-Age memiliki prioritas lebih tinggi (RFC 6265 menetapkan secara eksplisit). Jika keduanya tidak disetel, Cookie menjadi「Cookie Sesi」, kedaluwarsa saat browser ditutup. Alat ini akan memberikan saran untuk kasus yang telah menyetel Expires tetapi tidak menyetel Max-Age, menyarankan untuk menambahkan Max-Age. Perhatikan satuan Max-Age adalah detik bukan milidetik.

Apa perbedaan antara Path=/ dan tidak menyetel Path?

Path menentukan di permintaan jalur URL mana browser akan membawa Cookie ini. Saat tidak menyetel Path, browser secara default menggunakan「jalur setelah menghapus segmen terakhir dari URL respons」, misalnya menyetel Cookie dari /api/user/login, Path default adalah /api/user/, maka permintaan di bawah jalur / dan /order/ tidak akan membawa Cookie ini. Menyetel Path=/ secara eksplisit dapat membuat Cookie berlaku untuk seluruh situs. Perhatikan pencocokan Path adalah pencocokan awalan, Path=/api juga akan cocok dengan /api/, /api/user, /api/v2/abc, dll. Cookie awalan __Host- wajib mensyaratkan Path=/.

Apa perbedaan antara Domain dimulai dengan titik (misalnya .example.com) dan tanpa titik?

Di browser modern (versi terbaru Chrome, Firefox, Edge, Safari), keduanya telah setara, keduanya membuat Cookie berlaku untuk example.com dan semua subdomain-nya (a.example.com, b.c.example.com). Titik di awal adalah cara penulisan lama dari era RFC 2109, RFC 6265 telah menetapkan secara eksplisit mengabaikan titik di awal. Namun, untuk keterbacaan disarankan menulis bentuk tanpa titik. Alat ini akan memberikan saran untuk kasus Domain dengan titik di awal (bukan kesalahan, tetapi merupakan cara penulisan warisan sejarah). Perhatikan: Saat tidak menyetel Domain, Cookie hanya berlaku untuk host saat ini (subdomain tidak membawa), setelah menyetel Domain akan berlaku untuk subdomain.

Apa itu awalan Host- dan Secure-? Bisakah tidak menulis awalan?

Ini adalah awalan keamanan nama Cookie yang diperkenalkan oleh RFC 6265bis, digunakan untuk menambahkan batasan keras pada Cookie keamanan tinggi: ketika browser melihat nama Cookie dimulai dengan __Host-, akan secara wajib mensyaratkan harus secara bersamaan menyetel Secure, Path=/, tidak boleh menyetel Domain, salah satu syarat tidak terpenuhi akan menolak penyimpanan langsung; awalan __Secure- mensyaratkan harus menyetel Secure, atribut lain dapat dikonfigurasi. Tidak menulis awalan juga dapat berfungsi (sebagian besar Cookie tidak menggunakan awalan), tetapi untuk Cookie keamanan tinggi seperti pengidentifikasi sesi, Token otorisasi, sangat disarankan menggunakan awalan __Host-, karena dapat mencegah serangan injeksi Cookie di tingkat subdomain/jalur. Alat ini akan otomatis memeriksa kepatuhan kedua jenis awalan.

Apakah HttpOnly Cookie benar-benar aman? Mencegah XSS dan CSRF?

HttpOnly dapat mencegah JavaScript membaca nilai Cookie melalui document.cookie, adalah garis pertahanan penting untuk <strong>mengurangi pencurian sesi XSS</strong>, tetapi tidak mahakuasa: penyerang XSS masih dapat mengirim permintaan (permintaan otomatis membawa Cookie) di browser pengguna untuk melakukan operasi (ini adalah cakupan CSRF); HttpOnly juga tidak dapat bertahan dari serangan CSRF (perlu kombinasi SameSite atau CSRF Token). Hanya ketika menggunakan tiga serangkai HttpOnly+Secure+SameSite=Lax/Strict secara bersamaan baru mencapai tingkat keamanan dasar. Cookie sensitif (session, JWT, access_token) harus HttpOnly, tidak perlu jangan biarkan JS depan membaca. Alat ini akan memberi peringatan pada Cookie yang kurang HttpOnly.

Apa itu Partitioned (CHIPS) Cookie? Kapan perlu menggunakannya?

Partitioned adalah atribut baru yang diperkenalkan Chrome untuk menghadapi penghentian Cookie pihak ketiga, nama lengkapnya adalah Cookies Having Independent Partitioned State (CHIPS). Cookie pihak ketiga tradisional (misalnya Cookie yang disetel oleh layanan iklan/penyematan di banyak situs) dibagikan secara global, akan digunakan untuk melacak pengguna lintas situs. Setelah menambahkan Partitioned, browser akan menyimpan secara terpisah Cookie pihak ketiga tersebut menurut situs tingkat atas: Cookie pihak ketiga yang dilihat pengguna di situs A dan situs B sepenuhnya independen, tidak dapat berbagi identitas lintas situs. Skenario penggunaan: komponen video/peta/pembayaran tersemat, plugin layanan pelanggan pihak ketiga, iframe SSO lintas situs tersemat. Menggunakan Partitioned harus menyetel Secure secara bersamaan, disarankan dipasangkan dengan awalan __Host-.

Berapa maksimal satu Cookie dapat menyimpan data? Berapa banyak yang dapat diletakkan per nama domain?

Menurut RFC 6265, browser setidaknya mendukung 4096 byte per Cookie (termasuk nama, nilai, dan atribut), browser utama (Chrome/Firefox/Safari/Edge) semua menjalankan batas ini, bagian yang melebihi akan dipotong atau dibuang secara diam-diam. Batasan jumlah berbeda-beda menurut browser: Chrome sekitar 180 per nama domain, Firefox sekitar 150, Safari sekitar 600 (dan terpengaruh oleh kebijakan pembersihan tujuh hari ITP), setelah melebihi browser akan membuang Cookie tertua menurut strategi LRU. Disarankan Cookie hanya menyimpan pengidentifikasi sesi, jangan meletakkan data bisnis besar ke dalam Cookie (data bisnis letakkan di localStorage atau Session server).

Apakah mendukung penyalinan Set-Cookie langsung dari Chrome DevTools untuk di-parse? Perlu menghapus awalan secara manual?

Sepenuhnya mendukung, tidak perlu pemrosesan manual. Anda dapat di Chrome DevTools → panel Network klik permintaan target, salin langsung nilai Set-Cookie dengan mengklik kanan di area Response Headers (saat banyak baris, Ctrl/⌘+klik untuk memilih banyak atau salin seluruh bagian), tempelkan ke area input alat ini saja. Alat akan otomatis menghapus awalan Set-Cookie: di awal setiap baris (tidak sensitif huruf besar-kecil), otomatis memproses spasi awal dan akhir baris, menangani dengan benar karakter khusus seperti koma, titik koma yang terkandung dalam tanggal Expires, juga dapat menangani dengan benar nilai Cookie dengan tanda kutip ganda.

Mengapa karakter non-ASCII atau karakter khusus dalam nilai Cookie menjadi bentuk %XX?

RFC 6265 mensyaratkan nilai Cookie hanya dapat menggunakan himpunan bagian aman dalam kumpulan karakter ASCII, tidak dapat langsung berisi karakter non-ASCII, spasi, koma, titik koma, dll. Banyak framework sisi server saat menyetel Cookie akan otomatis melakukan encoding URL (encodeURIComponent/Percent-encoding) untuk karakter non-ASCII, misalnya teks beraksara bahasa Indonesia akan dienkode menjadi bentuk %XX. Browser juga mempertahankan bentuk encoding saat mengirim kembali. Ketika alat ini mendeteksi nilai berisi encoding %XX, akan otomatis menampilkan teks asli setelah didekode decodeURIComponent dengan panah hijau di samping nilai asli, memudahkan Anda melihat konten asli.

Apa perbedaan antara Set-Cookie dan header permintaan Cookie?

Kedua header ini sepenuhnya berbeda arah: Set-Cookie adalah header respons (server → browser), hanya muncul dalam respons, dapat muncul beberapa kali, setiap kali menyetel satu Cookie, berisi atribut lengkap (Secure/HttpOnly/Path/Domain, dll.); Cookie adalah header permintaan (browser → server), setiap permintaan hanya muncul satu kali, di dalamnya adalah pasangan name=value datar dari semua Cookie yang saat ini cocok cakupan (name1=v1; name2=v2), sama sekali tidak berisi informasi atribut. Artinya server tidak dapat mengetahui dari permintaan apakah suatu Cookie telah menyetel HttpOnly atau Secure, informasi atribut hanya disimpan secara lokal oleh browser. Untuk mem-parse header permintaan Cookie, silakan gunakan <a href='/network/http-cookie-parser/'>Parser header permintaan Cookie</a> yang menyertainya.

Mengapa Cookie saya di Safari hilang setelah beberapa hari?

Ini adalah mekanisme Pencegahan Pelacakan Cerdas (ITP: Intelligent Tracking Prevention) Safari yang bekerja. Sejak ITP 2.1, jika pengguna tidak berinteraksi langsung dengan nama domain tersebut dalam 7 hari (yaitu tidak mengunjungi langsung situs nama domain tersebut), Safari akan membersihkan semua Cookie dan data situs di bawah nama domain tersebut, berapa pun Max-Age/Expires yang disetel. Ini paling berdampak pada layanan tersemat pihak ketiga, terhadap Cookie situs utama tidak terpengaruh saat pengguna mengunjungi secara terus-menerus. Selain itu, Safari juga membatasi Cookie pihak ketiga lebih ketat daripada Chrome. Solusi meliputi: menggunakan atribut Partitioned, meminta izin melalui Storage Access API, atau menyegarkan kembali Cookie saat pengguna mengunjungi situs utama. Bab pemecahan masalah alat ini memiliki panduan debugging Safari yang lebih rinci.

Apakah alat mendukung parsing massal banyak Set-Cookie? Apakah mengunggah konten Cookie ke server?

Mendukung parsing massal. Area input mendukung penempelan sebanyak baris Set-Cookie apa pun (misalnya menempelkan seluruh bagian header respons sekaligus), setiap Set-Cookie akan diparse dengan nomor urut independen, banyak kartu atribut menampilkan atribut dan peringatan masing-masing secara terpisah. Semua proses parsing sepenuhnya diselesaikan secara lokal di browser Anda (pemrosesan JavaScript front-end murni), konten Cookie tidak diunggah ke server mana pun, juga tidak mengirim permintaan jaringan, informasi sensitif seperti Session/Token yang Anda tempelkan tidak akan meninggalkan komputer Anda, dapat digunakan dengan tenang.

术语表

Set-Cookie: Header respons HTTP, melalui mana server memerintahkan browser menyimpan Cookie, dapat muncul beberapa kali dalam satu respons.
Cookie (header permintaan): Header permintaan HTTP, daftar pasangan nama-nilai Cookie yang memenuhi persyaratan cakupan yang dilampirkan otomatis oleh browser, tidak berisi atribut.
HttpOnly: Tanda atribut Cookie. Setelah disetel, JavaScript tidak dapat membaca Cookie ini melalui document.cookie, terutama bertahan dari pencurian sesi XSS.
Secure: Tanda atribut Cookie. Setelah disetel, browser hanya mengirim Cookie ini dalam koneksi terenkripsi HTTPS (atau localhost).
SameSite: Atribut Cookie, mengontrol apakah permintaan lintas situs membawa Cookie, nilainya Strict/Lax/None. Chrome 80+ default Lax.
Max-Age: Atribut Cookie, menentukan berapa detik Cookie bertahan, prioritas lebih tinggi dari Expires, disarankan digunakan. =0 berarti segera hapus.
Expires: Atribut Cookie, menentukan titik waktu kedaluwarsa spesifik Cookie (HTTP-date), bergantung pada jam klien.
Path: Atribut Cookie, membatasi awalan jalur URL tempat Cookie berlaku, default mengambil bagian direktori URL respons.
Domain: Atribut Cookie, membatasi nama domain tempat Cookie berlaku. Jika tidak disetel, hanya terbatas pada host saat ini; jika disetel, akan berlaku untuk subdomain.
Partitioned (CHIPS): Tanda atribut Cookie, mengaktifkan penyimpanan terpartisi Cookie pihak ketiga, adalah solusi pengganti setelah Chrome menghentikan Cookie pihak ketiga, harus dipasangkan dengan Secure.
Awalan __Host-: Batasan keamanan awalan nama Cookie. Mensyaratkan harus Secure, Path=/, tidak boleh menyetel Domain, jika melanggar browser menolak menyimpan.
Awalan __Secure-: Batasan keamanan awalan nama Cookie. Mensyaratkan harus menyetel Secure, jika melanggar browser menolak menyimpan.
Cookie Sesi (Session Cookie): Cookie yang tidak menyetel Max-Age dan Expires, otomatis terhapus setelah browser ditutup.
Cookie Pihak Ketiga (Third-party Cookie): Cookie yang disetel di bawah nama domain selain nama domain halaman yang sedang diakses, biasanya disetel oleh layanan pihak ketiga seperti iklan, pelacakan, iframe tersemat, browser secara bertahap membatasinya.

Tabel referensi cepat perbandingan tiga strategi SameSite

Tabel referensi lengkap atribut Set-Cookie (RFC 6265bis)

Batasan ukuran dan jumlah Set-Cookie browser umum