logo
GeekFormat

Set-Cookie 解析器

Set-Cookie Parser

貼上多行 Set-Cookie 回應標頭以檢查屬性,並標記有風險的 SameSite / Secure 組合。

Cookie 屬性卡片

2 個 Set-Cookie
#1sessionabc123
path/
httponly(旗標)
secure(旗標)
samesiteLax
未發現明顯的屬性問題
#2preview1
max-age600 (10m 0s)

setCookieParser.attr.maxAgeHint

samesiteNone
secure(旗標)
setCookieParser.warn.missingHttpOnlysetCookieParser.warn.missingPath

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"
    ]
  }
]

貼上Set-Cookie標頭,瀏覽器為什麼不收Cookie立刻有答案。

相關推薦

適用場景

  • 瀏覽器拒絕寫入Cookie時,快速定位是SameSite策略問題、缺Secure標誌,還是Path/Domain不匹配導致
  • 第三方登入/SSO/嵌入iframe場景下Cookie被瀏覽器攔截,偵測SameSite=None是否正確搭配Secure
  • 資安稽核時批次檢查介面回傳的Cookie是否全部設定HttpOnly防止XSS竊取,是否設定Secure防止HTTP明文傳輸
  • 使用__Host-/__Secure-前綴Cookie時驗證是否滿足RFC 6265bis的強制要求,避免被瀏覽器靜默丟棄
  • 除錯CHIPS(Partitioned Cookie)三方Cookie分割區方案時,確認Partitioned與Secure同時宣告
  • 伺服端設定Max-Age/Expires時確認數值有效,避免因時鐘偏差或Max-Age=0導致Cookie立即過期
  • 對比不同環境(開發/測試/生產)的Set-Cookie標頭差異,排查開發環境正常生產環境Cookie遺失的詭異問題
  • 從DevTools或curl回應中整段複製回應標頭,無需手動去除Set-Cookie:前綴,工具自動識別剝離
  • 寫介面文件或WASM/WebWorker請求相關Bug時,把解析後的JSON結果直接貼到文件中說明Cookie結構

功能特點

  • 多Cookie獨立解析:每行Set-Cookie獨立成卡片,編號展示名稱、值與URL解碼值,一眼分清哪個Cookie有問題
  • 14種屬性資安偵測:自動識別SameSite=None缺Secure、SameSite值非法、Partitioned缺Secure、缺HttpOnly、缺Path、缺SameSite、__Host-前綴違規、__Secure-前綴缺Secure、Max-Age無效/為0、Domain點號開頭、Expires未配Max-Age等常見錯誤
  • 全屬性完整拆解:SameSite、Secure、HttpOnly、Path、Domain、Expires、Max-Age、Partitioned逐項列出,flag型屬性與帶值屬性一目了然
  • Max-Age自動換算:將秒數自動換算為天/小時/分鐘/秒的人類可讀時間,例如Max-Age=2592000會顯示為30d
  • URL解碼值自動顯示:Cookie值含%XX編碼時自動展示解碼後原文(如sessionID%3Dabc→sessionID=abc),綠色箭頭標識
  • RFC 6265bis前綴偵測:嚴格校驗__Host-和__Secure-前綴Cookie的合規要求,包括Path=/、禁Domain、必設Secure
  • 原始標頭一鍵複製:所有解析的Cookie原始行彙總複製,方便貼上到郵件、Issue、文件同步給團隊
  • JSON結構化預覽:解析結果支援JSON格式輸出,包含name/value/decodedValue/attributes/attributeMap/warnings完整欄位,可直接用於指令碼和測試案例
  • 全本機處理:Set-Cookie內容在瀏覽器本機解析,不上傳任何伺服器,避免外洩敏感Session、Token等資訊
  • 智慧警告徽章:每種問題用橙色警告徽章標出具體原因,無需對照RFC逐條查文件
  • 多行批次輸入:一次貼上整段回應標頭(如從Chrome DevTools Network面板複製),自動剝離Set-Cookie:前綴逐行解析
  • 支援帶引號和分號的值:正確處理RFC規範中帶雙引號的Cookie值和Expires日期中的分號,不會錯誤拆分

使用方法

  1. 打開瀏覽器DevTools的Network面板,找到目標要求,在Response Headers區域複製Set-Cookie的內容(支援多行,一次複製所有Cookie)
  2. 將複製的Set-Cookie回應標頭貼上到輸入區,每行一條Cookie(無需手動刪除Set-Cookie:前綴,工具會自動剝離)
  3. 工具即時解析,頂部顯示識別到的Set-Cookie條數,下方每個Cookie獨立為一張屬性卡片
  4. 卡片頭部顯示編號、Cookie名、原始值,若值包含URL編碼會在綠色箭頭後顯示解碼後的值
  5. 卡片主體按SameSite、Secure、HttpOnly、Path、Domain、Max-Age、Expires、Partitioned等逐項展示屬性,Max-Age會自動附括號換算易讀時間
  6. 卡片底部顯示檢查結果:橙色警告徽章標註具體問題(每條問題都有明確繁體中文說明),綠色徽章表示未發現明顯問題
  7. 需要對照伺服端設定時點擊「複製原始標頭」把全部原始Set-Cookie行複製出來;需要程式化處理時檢視「JSON預覽」

常見問題

為什麼 Set-Cookie 標頭設定成功了但瀏覽器沒有儲存我的Cookie?

這是最常見的問題,瀏覽器不會主動報錯,而是靜默丟棄不合規的Cookie。常見原因有:SameSite=None缺少Secure、Secure Cookie在HTTP頁面設定(localhost例外)、__Host-/__Secure-前綴不滿足約束、Domain/Path不匹配、超過4KB大小限制、Max-Age為0或負數。建議先把Set-Cookie貼到本工具,檢視警告徽章定位具體原因,再打開Chrome DevTools → Application → Cookies,在對應網域下檢視是否有黃色警告三角形,懸浮可看到具體拒絕原因。

SameSite 的 Strict、Lax、None 到底什麼區別?什麼時候用哪個?

Strict完全不允許跨站傳送,最安全但使用者從外站連結點進來會顯示未登入,適合支付/改密等敏感操作Cookie。Lax是Chrome 80+的預設值,允許頂級GET導覽跳轉時攜帶(點擊外站連結跳回你網站),但iframe/img/script/XHR/POST表單等子資源不攜帶,是大部分場景的推薦值。None允許所有跨站場景傳送(用於SSO單點登入、三方嵌入iframe、跨站API呼叫),但必須同時設定Secure,否則瀏覽器直接拒絕。

為什麼 SameSite=None 必須配 Secure?

這是Chrome從80版本(2020年2月)開始強制執行的規則,Firefox、Edge、Safari也都跟進了。因為SameSite=None明確允許跨站傳送Cookie,攻擊者更容易在跨站場景發起CSRF或竊聽,必須配合Secure(HTTPS加密傳輸)來降低風險。如果你的SameSite=None Cookie在HTTP下設定,瀏覽器會直接丟棄而不儲存。本工具會偵測SameSite=None缺Secure的組合並標紅警告。

Max-Age 和 Expires 用哪個?有什麼區別?

優先用Max-Age。Max-Age是相對時間(多少秒後過期),不依賴用戶端時鐘,瀏覽器收到後開始倒數;Expires是絕對時間點,依賴使用者電腦本地時間(使用者把時鐘改到1970年Cookie就立即過期)。當兩者同時存在時Max-Age優先級更高(RFC 6265明確規定)。如果都不設定,Cookie變成「工作階段Cookie」,瀏覽器關閉即失效。本工具會對設定了Expires但沒設Max-Age的情況給出提示,建議補Max-Age。注意Max-Age單位是秒不是毫秒。

Path=/ 和不設定 Path 有什麼區別?

Path決定了瀏覽器在哪些URL路徑的要求中會攜帶這個Cookie。不設定Path時,瀏覽器預設使用「回應URL去掉最後一段後的路徑」,比如從/api/user/login設定Cookie,預設Path是/api/user/,那麼/路徑和/order/下的要求不會帶這個Cookie。顯式設定Path=/可以讓Cookie對整個網站生效。注意Path匹配是前綴匹配,Path=/api也會匹配/api/、/api/user、/api/v2/abc等。__Host-前綴Cookie強制要求Path=/。

Domain 開頭帶點(比如 .example.com)和不帶點有什麼區別?

在現代瀏覽器(Chrome、Firefox、Edge、Safari近期版本)中兩者已經等價,都會讓Cookie對example.com及其所有子域(a.example.com、b.c.example.com)生效。點號開頭是RFC 2109時代的舊寫法,RFC 6265已經明確忽略前導點。不過為了可讀性推薦寫不帶點的形式。本工具會對Domain帶前導點的情況給出提示(不是錯誤,但屬於歷史遺留寫法)。注意:不設定Domain時Cookie僅對目前主機生效(子域不會帶),設定Domain後會對子域生效。

__Host- 和 __Secure- 前綴是什麼?不寫前綴可以嗎?

這是RFC 6265bis引入的Cookie名資安前綴,用來給高資安Cookie加固約束:瀏覽器看到Cookie名以__Host-開頭時,會強制要求必須同時設定Secure、Path=/、不能設定Domain,任一條件不滿足就直接拒絕儲存;__Secure-前綴要求必須設定Secure,其他屬性可配。不寫前綴也可以工作(大部分Cookie都不用前綴),但對於工作階段標識、授權Token等高資安Cookie強烈推薦使用__Host-前綴,因為它能防止子域/路徑級別的Cookie注入攻擊。本工具會自動偵測兩種前綴的合規性。

HttpOnly Cookie 真的安全嗎?防止XSS和CSRF嗎?

HttpOnly能防止JavaScript透過document.cookie讀取Cookie值,是<strong>緩解XSS竊取工作階段</strong>的重要防線,但不是萬能的:XSS攻擊者仍然可以在使用者瀏覽器中發起要求(要求自動帶Cookie)執行操作(這是CSRF範疇);HttpOnly也不能防禦CSRF攻擊(需要SameSite或CSRF Token配合)。HttpOnly+Secure+SameSite=Lax/Strict三件套同時使用才能達到基礎資安水位。敏感Cookie(session、JWT、access_token)必須HttpOnly,非必要不要給前端JS讀。本工具對缺少HttpOnly的Cookie會標警告。

Partitioned(CHIPS)Cookie 是什麼?什麼時候需要用?

Partitioned是Chrome為應對第三方Cookie淘汰推出的新屬性,全名為Cookies Having Independent Partitioned State(CHIPS)。傳統三方Cookie(比如廣告/嵌入服務在多個網站設定的Cookie)是全域共享的,會被用來跨站追蹤使用者。加了Partitioned後,瀏覽器會按頂級網站分別儲存該三方Cookie:使用者在A站看到的三方Cookie和B站看到的完全獨立,不能跨站共享身份。使用場景:嵌入式影片/地圖/支付元件、三方客服外掛、跨站SSO嵌入iframe。使用Partitioned必須同時設定Secure,推薦配合__Host-前綴使用。

一個Cookie最大能存多少?每個網域能放多少個?

根據RFC 6265,瀏覽器至少支援每個Cookie 4096位元組(包含名稱、值和屬性),主流瀏覽器(Chrome/Firefox/Safari/Edge)都按這個上限執行,超出部分會被靜默截斷或丟棄。數量限制因瀏覽器而異:Chrome每個網域約180個,Firefox約150個,Safari約600個(且受ITP七天清理策略影響),超出後瀏覽器會按LRU策略淘汰最舊的Cookie。建議Cookie儲存工作階段標識即可,不要把大段業務資料放Cookie裡(業務資料放localStorage或伺服端Session)。

支援從Chrome DevTools直接複製Set-Cookie來解析嗎?需要手動去前綴嗎?

完全支援,無需手動處理。你可以在Chrome DevTools → Network面板點擊目標要求,在Response Headers區域右鍵Set-Cookie的值直接複製(多行時Ctrl/⌘+點擊多選或整段複製),貼到本工具輸入區即可。工具會自動剝離每行開頭的Set-Cookie:前綴(不區分大小寫),自動處理行首行尾空白,正確處理Expires日期中包含的逗號、分號等特殊字元,也能正確處理帶雙引號的Cookie值。

Cookie 值中的中文或特殊字元為什麼會變成 %XX 形式?

RFC 6265要求Cookie值只能使用ASCII字元集中的一個安全子集,不能直接包含中文、空格、逗號、分號等。很多伺服端框架在設定Cookie時會自動對非ASCII字元做URL編碼(encodeURIComponent/Percent-encoding),例如「你好」會編碼為%E4%BD%A0%E5%A5%BD。瀏覽器回傳時也保持編碼形式。本工具偵測到值含%XX編碼時,會在原始值旁用綠色箭頭自動展示decodeURIComponent解碼後的原文,方便你檢視真實內容。

Set-Cookie 和 Cookie 要求標頭有什麼區別?

兩者是完全不同方向的標頭:Set-Cookie是回應標頭(伺服器→瀏覽器),只在回應中出現,可以出現多次,每次設定一個Cookie,包含完整屬性(Secure/HttpOnly/Path/Domain等);Cookie是要求標頭(瀏覽器→伺服器),每次要求只會出現一次,裡面是目前匹配作用域的所有Cookie的扁平name=value對(name1=v1; name2=v2),完全不包含屬性資訊。也就是說伺服器從要求中無法知道某個Cookie是否設了HttpOnly或Secure,屬性資訊只有瀏覽器在本機儲存時才保留。解析Cookie要求標頭請使用配套的<a href='/network/http-cookie-parser/'>Cookie要求標頭解析器</a>。

為什麼Safari中我的Cookie過幾天就消失了?

這是Safari的智慧追蹤預防(ITP: Intelligent Tracking Prevention)機制在起作用。從ITP 2.1開始,如果使用者7天內沒有直接與該網域互動(即沒有直接造訪過該網域網站),Safari會清理該網域下的所有Cookie和網站資料,不管Max-Age/Expires設多長。這對第三方嵌入服務影響最大,對主站Cookie在使用者持續造訪下不受影響。此外Safari對第三方Cookie的限制也比Chrome嚴格。解決辦法包括:使用Partitioned屬性、透過Storage Access API請求權限、或在使用者造訪主站時重新重新整理Cookie。本工具的故障排查章節中有更詳細的Safari除錯指引。

工具支援批次解析多個Set-Cookie嗎?會上傳Cookie內容到伺服器嗎?

支援批次解析。輸入區支援貼上任意多行Set-Cookie(比如一次貼上整段回應標頭),每個Set-Cookie會獨立編號解析,多張屬性卡片分別展示各自的屬性和警告。所有解析過程完全在你的瀏覽器本機完成(純前端JavaScript處理),Cookie內容不會上傳到任何伺服器,也不會發網路要求,你貼上的Session/Token等敏感資訊不會離開你的電腦,可以放心使用。

术语表

Set-Cookie
HTTP回應標頭,伺服器透過它指示瀏覽器儲存Cookie,可在一個回應中出現多次。
Cookie(要求標頭)
HTTP要求標頭,瀏覽器自動附加的符合作用域要求的Cookie名值對清單,不含屬性。
HttpOnly
Cookie屬性標誌。設定後JavaScript無法透過document.cookie讀取該Cookie,主要防禦XSS工作階段竊取。
Secure
Cookie屬性標誌。設定後瀏覽器僅在HTTPS(或localhost)加密連線中傳送該Cookie。
SameSite
Cookie屬性,控制跨站要求是否攜帶Cookie,取值為Strict/Lax/None。Chrome 80+預設Lax。
Max-Age
Cookie屬性,指定Cookie存活秒數,優先級高於Expires,推薦使用。=0表示立即刪除。
Expires
Cookie屬性,指定Cookie過期的具體時間點(HTTP-date),依賴用戶端時鐘。
Path
Cookie屬性,限定Cookie生效的URL路徑前綴,預設取回應URL的目錄部分。
Domain
Cookie屬性,限定Cookie生效的網域。不設定時僅限目前主機,設定後對子域生效。
Partitioned(CHIPS)
Cookie屬性標誌,啟用三方Cookie分割區儲存,是Chrome淘汰三方Cookie後的替代方案,須搭配Secure。
__Host-前綴
Cookie名前綴資安約束。要求必須Secure、Path=/、不得設定Domain,違反則瀏覽器拒絕儲存。
__Secure-前綴
Cookie名前綴資安約束。要求必須設定Secure,違反則瀏覽器拒絕儲存。
工作階段Cookie(Session Cookie)
不設定Max-Age和Expires的Cookie,瀏覽器關閉後自動刪除。
第三方Cookie(Third-party Cookie)
在目前造訪頁面網域之外的網域下設定的Cookie,通常由廣告、追蹤、嵌入iframe等三方服務設定,各瀏覽器正在逐步限制。

SameSite 三種策略對比速查表

Set-Cookie 屬性完整參考表(RFC 6265bis)

常見瀏覽器Set-Cookie大小與數量限制

Troubleshooting