Cookies 怎麼運作？第一方、第三方與瀏覽器隱私限制一次看懂

去寄物處領過外套的人都知道，櫃台收下外套後，只會遞給你一張號碼牌，下次憑牌領回，櫃台不需要記得你長什麼樣子。網站與瀏覽器之間的 Cookies，做的就是這件事。

這裡的 Cookie 跟餅乾無關，指的是網站交給瀏覽器保管的一小段文字資料，瀏覽器每次回到同一個網站，就會把它帶上。

登入後換頁仍是登入狀態、關掉頁面購物車還在、看過的商品跟著出現在別站的廣告，背後多半是同一套機制。它既負責方便，也被拿去追蹤，所以瀏覽器對它的限制一直在變，網路上不少舊文章的說法也早已過時。

這張號碼牌之所以非有不可，源自 HTTP 本身一個天生的限制。

Cookie 是什麼？

Cookie 是伺服器交給瀏覽器保管的一小段資料，瀏覽器之後對同一個網站發出請求時，會把它原樣送回去。根據 MDN 的說明，瀏覽器可以儲存、新建、修改這些資料。伺服器透過 Set-Cookie 標頭把資料交出去，瀏覽器則在日後的請求裡用 Cookie 標頭送回來。不論問的是 Cookie是什麼還是 Cookies是什麼，指的都是同一件事，寫成複數只是因為一個網站通常會同時放好幾個。

每個 Cookie 的組成很單純，就是名稱加上值，再加上若干屬性。名稱和值是網站真正想記住的內容，屬性則是附帶的規則，決定它能存多久、送到哪些地方、腳本讀不讀得到。所以一個 Cookie 並不只是一組「名稱=值」，而是一份帶著使用條件的小紙條。

HTTP 預設無狀態，Cookie 補上跨請求的記憶

MDN 指出，HTTP 協定預設是無狀態（stateless）的。意思是伺服器每收到一個請求，都當作第一次見到你，不會記得上一個請求是誰送的，也不知道兩個請求是不是來自同一個人。對只看文章的頁面這沒有影響，但換成會員網站或購物網站就麻煩了，你剛輸入完密碼，換到下一頁，伺服器若認不出你，就得再問一次。

Cookie 補上的，就是跨請求的這一塊記憶。伺服器把一段識別資料交給瀏覽器，之後這個瀏覽器送來的每個請求都帶著它，伺服器便能認出這些請求出自同一處，再決定該回個人化的頁面還是一般版本。以最簡單的登入流程來說，MDN 列出的過程大致如下：

1. 使用者送出登入憑證。
2. 憑證正確時，伺服器的回應帶有 session ID 的 Cookie，記錄這個人已登入。
3. 使用者進到同網站的另一頁，瀏覽器把含 session ID 的 Cookie 隨請求送出。
4. 伺服器檢查 session ID，有效就回個人化頁面，無效就刪除該 ID，顯示一般頁面或要求重新登入。

這四步裡，使用者從頭到尾沒有再輸入過密碼，替伺服器記住「這個人剛登入過」的，是那個帶著 session ID 的 Cookie。會員網站的登入狀態，多半就是這樣維持的。

伺服器以 Set-Cookie 設定，瀏覽器以 Cookie 標頭送回

實際走一輪，只需要兩個標頭。伺服器在回應裡用 Set-Cookie 設定，一個 Cookie 一行，格式是 名稱=值，回應可以同時帶多個。以下沿用 MDN 的寫法：

HTTP/1.1 200 OK
Set-Cookie: yummy_cookie=chocolate
Set-Cookie: tasty_cookie=strawberryCode language: plaintext (plaintext)

瀏覽器收到後存起來，之後對同一個網站發請求，就用 Cookie 標頭，把同網站的 Cookie 以分號串在一起送回：

GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=chocolate; tasty_cookie=strawberryCode language: plaintext (plaintext)

除了標頭這條路，網頁上的 JavaScript 也能透過 document.cookie 設定與讀取 Cookie。不過設了 HttpOnly 屬性的 Cookie，腳本讀不到。

Google 的 web.dev 另有一個範例，Set-Cookie: promo_shown=1; Max-Age=2600000; Secure，示範 名稱=值 後面可以接屬性。對應的請求標頭只會送出 Cookie: promo_shown=1，也就是說屬性是給瀏覽器看的規則，不會跟著請求再送回伺服器。

Cookie 的 3 類用途，便利與追蹤只是用法不同

MDN 把 Cookie 的用途分成三類，分別是工作階段管理（session management）、個人化（personalization）與追蹤（tracking）。同一種技術被拿去做很不同的事，便利和追蹤只是用法的差別，Cookie 本身分不出好壞。

Chrome 的說明頁提到的偏向便利那一面，包括讓使用者保持網站登入狀態、記住網站偏好設定，以及提供與當地相關的內容。對照自己的經驗最容易懂，購物車關掉頁面還在，看過的鞋子卻跟著出現在別站的廣告，這兩件事就分屬不同的類別。

登入狀態與購物車的工作階段管理

MDN 把使用者登入狀態、購物車內容、遊戲分數都歸在工作階段管理，共同點是伺服器需要在多次請求之間，記住同一個人的狀態。

這裡有個常被誤會的地方，Cookie 裡通常放的只是一個識別碼，不是把你的資料整包存在瀏覽器，真正的帳號資料和購物車內容多半留在伺服器上，伺服器拿識別碼去查。識別碼無效時，伺服器就像前面登入流程的第 4 步那樣，把它刪除，再顯示一般頁面或要求重新登入。

MDN 在安全的段落也建議，Cookie 裡放伺服器可以查表的不透明識別碼，不要直接把敏感資訊放進去。這樣即使 Cookie 被別人看到，看到的也只是一串沒有意義的字元。

語言和外觀的偏好設定

網站記住你選的語言，或記住你切換過的深色模式，用的就是個人化類的 Cookie。MDN 舉的例子正是顯示語言與介面主題。這是相對單純的一種用途，偏好設定通常不含個人身分，存留時間則看網站希望記住多久，可長可短。

web.dev 的範例很具體，promo_shown=1 這個 Cookie 搭配 Max-Age=2600000，約等於一個月。使用者關掉宣傳橫幅後，這段期間內不會再看到它，等 Cookie 到期，橫幅才會再出現。

分析與廣告的行為追蹤

追蹤類 Cookie 的運作方式很單純，先在瀏覽器放一個識別碼，下次再看到這個識別碼，就知道是同一個瀏覽器回來了。網站的統計工具用這個辦法認出回訪者、計算造訪次數，資料一般在同一個網站內打轉，屬於追蹤類裡較中性的一端。

廣告平台的做法不同。MDN 說明，第三方伺服器可以結合多個網站上的第三方 Cookie，建立使用者的瀏覽歷史、興趣與習慣的輪廓。於是你在一個網站搜尋過某項商品，之後到哪個網站都被相似商品的廣告追著跑，這是 MDN 舉的經典例子，也是「看過的商品跟著出現」的由來。

兩者的差別在資料有沒有離開同一個網站。分析類的識別碼只在自家網站累積，廣告類則是在許多網站讀到同一個識別碼，累積成跨站的輪廓。而跨站的界線怎麼劃，取決於 Cookie 是第一方還是第三方。

第一方與第三方 Cookie 以網址列的網站為界

判斷標準只有一個，Cookie 所屬的網站，和瀏覽器網址列顯示的網站是不是同一個。相同就是第一方，不同就是第三方。web.dev 特別強調，這並不是 Cookie 自帶的標籤，而是跟使用者當下的瀏覽情境有關，所以同一個 Cookie 換一個瀏覽的網站，就可能從第一方變成第三方。

以嵌入 YouTube 影片為例，web.dev 說明，訪客若已登入 YouTube，第三方 Cookie 能讓嵌入的播放器沿用他的登入工作階段，「稍後觀看」按鈕就不需要先跳轉登入。同一個 Cookie，直接開 YouTube 時是第一方，到了別人網站的嵌入影片裡就成了第三方。

MDN 指出，第三方 Cookie 常在兩種情況下送出，一種是點連結跳轉到另一個網站，另一種是頁面嵌入了他站的元件，例如 iframe。MDN 也稱第三方 Cookie 為 cross-site cookies（跨站 Cookie），認為這個叫法更準確，因為「第三方」容易讓人以為是別人的公司所有，但即使是同一家公司旗下的不同網站，彼此也算跨站。

判斷看的是「網站」，不是完整的主機名稱。WebKit 的說明舉例，sub.news.example 在 news.example 之下載入，算同一個網站，所以是第一方。WebKit 也提到，並不存在一種特別的「第三方 Cookie」，重點在於內容以第三方身分載入時，能不能存取屬於它的 Cookie。

第三方 Cookie 並非只拿來追蹤。MDN 列出的正當用途包括跨相關網站共用登入狀態、共用偏好或主題、跨網站分析，以及廣告曝光計數。但 MDN 同時指出，這類用途在技術上與追蹤用途無法區分，所以瀏覽器很難只擋壞的、放行好的，這也是三家瀏覽器各自選了不同做法的背景。

工作階段 Cookie 與永久 Cookie 以到期時間區分

兩者的分別只看有沒有設定到期時間。沒有設 Expires 或 Max-Age 的是工作階段 Cookie，瀏覽器的工作階段結束就刪除；有設的是永久 Cookie，要等到期日一到，或存留秒數用完，才會被刪除。

「工作階段何時結束」是由瀏覽器定義，不是看分頁有沒有關。MDN 指出，有些瀏覽器重啟時會還原上次的工作階段，使工作階段 Cookie 無限期存留。所以有時候明明關掉瀏覽器，再打開登入還在。另一種情況是網站把登入用的 Cookie 設成永久 Cookie，在到期之前，關掉瀏覽器也不會讓它消失。WordPress 就是一例，登入時勾選保持登入，驗證 Cookie 會帶著到期時間，沒有勾選則是工作階段 Cookie。

永久 Cookie 有兩種寫法：

Set-Cookie: id=a3fWa; Expires=Tue, 31 Dec 2030 07:28:00 GMT
Set-Cookie: id=a3fWa; Max-Age=2592000Code language: plaintext (plaintext)

Expires 是絕對的日期時間，Max-Age 則是從設定當下起算的秒數，2592000 秒等於 30 天。兩者同時設定時，以 Max-Age 為準，IETF 的 RFC 6265bis 草案演算法也是這樣處理，有 Max-Age 就用它，沒有才看 Expires。MDN 認為 Max-Age 較不易出錯，原因是 Expires 以接收 Cookie 的客戶端時鐘為準，伺服器與客戶端的時間一旦不一致，到期時間就會跟著偏差。web.dev 也建議用 Max-Age，確保 Cookie 不會保留超過必要的時間。

要立刻刪除一個 Cookie，做法是用相同的名稱、Path、Domain 再設定一次，並把 Expires 設成過去的日期，或把 Max-Age 設為 0 或負數：

Set-Cookie: id=a3fWa; Max-Age=0Code language: plaintext (plaintext)

網站有登入功能時，還有一件事要留意。MDN 建議每次登入都重新產生並重發工作階段 Cookie，目的是防範 session fixation，也就是攻擊者先讓使用者拿到一個已知的識別碼，再等使用者登入後直接借用它。

Cookie 屬性決定傳送範圍和安全條件

名稱和值之外的設定都叫屬性，決定這個 Cookie 送到哪裡、什麼條件下才送、腳本讀不讀得到。Expires 與 Max-Age 前面已經說過，剩下的有三組，分別是 Domain 與 Path、Secure 與 HttpOnly，以及 SameSite。用寄信來比喻，Domain 和 Path 像收件地址，Secure 和 SameSite 像限收條件，HttpOnly 則決定網頁腳本能不能把信拆開來看。

屬性的規格由 IETF 制定。現行已發布的版本是 RFC 6265，2011 年 4 月發布，屬於 Proposed Standard。修訂版 draft-ietf-httpbis-rfc6265bis 尚在草案階段，最新的 draft-22 發布於 2025 年 12 月，預定成為 Proposed Standard 並取代 RFC 6265。IETF datatracker 顯示它已排入 RFC Editor 的發布佇列，正等待最終核准，還沒有正式的 RFC 編號。

草案與 RFC 6265 相比，調整包括限制 Cookie 的大小、限制 Max-Age 與 Expires 的最大值，以及把 host-only flag 納入 Cookie 唯一性的計算。實際寫屬性時，以 IETF 的規範和 MDN 的說明為準，不要靠舊文章的記憶。

Cookie 的 4096 位元組大小上限與數量限制

Cookie 的內容就是一組 名稱=值，但大小有限制。RFC 6265bis 草案規定，名稱與值的長度合計超過 4096 位元組時，瀏覽器必須忽略整個 Cookie，不是只截掉超出的部分；屬性值（例如 Path、Domain）超過 1024 位元組時，則是忽略那一個屬性。MDN 則說，單一 Cookie 通常上限是 4KB。

數量也有上限。每個網域能存的 Cookie 數量依瀏覽器而異，通常是數百個。更現實的限制在於每個請求都會帶著 Cookie 送出。web.dev 提到，熱門網站設的 Cookie 往往遠不只三個，而使用者的上傳頻寬通常比下載頻寬受限，請求多帶的這些資料都會拉長首位元組時間（TTFB）；MDN 也提醒，這在慢速的行動網路上可能拖慢效能。所以數量與大小都該節制。

Domain 與 Path 劃定傳送範圍

Domain 決定哪些主機收得到這個 Cookie，Path 決定哪些路徑收得到。最容易誤解的是 Domain，不設定反而最嚴格，Cookie 只會送給設定它的那個主機，不含子網域；一旦指定了 Domain，就連同所有子網域一起送。MDN 的例子是在 mozilla.org 設 Domain=mozilla.org，developer.mozilla.org 等子網域也會收到。

伺服器只能把 Domain 設成自己的網域或上層網域，不能設到別人的網站。MDN 的例子是，api.example.com 送出的回應可以設 Domain=api.example.com 或 Domain=example.com，但不能設成 beta.api.example.com、other.example.com，也不能設成 com 這類公開後綴。

Path 用路徑前綴比對。Path=/docs 會比對 /docs、/docs/、/docs/Web/ 與 /docs/Web/HTTP，但不會比對 /、/docsets 或 /fr/docs。要注意的是，MDN 明確指出 Path 不是為了安全而設，也無法避免 Cookie 從別的路徑被讀取。

Secure 與 HttpOnly 限制傳輸和腳本存取

Secure 管的是傳輸。帶 Secure 的 Cookie 只會隨加密的 HTTPS 請求送給伺服器，不會隨未加密的 HTTP 請求送出，因此使用未加密 HTTP 的網站也無法設定 Secure Cookie。localhost 是例外，只是 MDN 註明 Safari 不支援這個例外。HTTPS 與 HTTP 的差別，以及全站切換的做法，站上另有專文說明。

HttpOnly 管的是腳本。帶 HttpOnly 的 Cookie 不能用 document.cookie 存取，只有送到伺服器時才讀得到。MDN 建議維持登入工作階段的 Cookie 都該設 HttpOnly，可以降低跨站腳本（XSS）攻擊的風險，攻擊者注入的腳本就很難直接偷走登入識別碼。

兩個屬性搭配，前者讓 Cookie 不走未加密的連線，降低途中被攔截的機會，後者讓腳本讀不到登入用的 Cookie。但這些屬性並非萬能，MDN 指出，Secure 不代表能防所有存取，能直接取得使用者硬碟的人，仍可以讀到 Cookie 檔案。

SameSite 以 Strict、Lax、None 控制跨站送出

前面談到的第三方 Cookie 能不能送出，關鍵開關就是 SameSite。MDN 說明，它讓伺服器指定 Cookie 是否、何時隨跨站請求送出，有三個值：

• Strict：只在請求源自 Cookie 所屬的網站時才送出，適合登入驗證或購物車這類一定先經過初始導覽才會用到的功能。
• Lax：與 Strict 類似，但使用者從其他網站連結導覽到來源網站時也會送出。MDN 舉聯盟連結為例，連結導向夥伴網站，夥伴設 Cookie 記錄連結被點過，用來顯示回饋橫幅與折扣。
• None：來源網站與跨站請求都會送出，適合廣告科技或分析服務嵌入他站內容的情境。設 SameSite=None 時，必須同時設 Secure。

沒設 SameSite 時，Chromium 系瀏覽器視為 Lax，其他瀏覽器行為不一，所以最好明確設定。跨網站嵌入的需求，例如 iframe 裡的登入元件，更要明確寫成 SameSite=None，MDN 的範例如下：

Set-Cookie: widget_session=7yjgj57e4n3d; SameSite=None; Secure; HttpOnlyCode language: plaintext (plaintext)

web.dev 把 SameSite 屬性定位成明確指出 Cookie 用途的標記，標明它屬於第一方情境還是第三方情境。Chrome DevTools 的說明與 MDN 也都把 SameSite=None 視為第三方 Cookie 的特徵，看到這個值，通常就代表這個 Cookie 打算跨站使用。

Cookie 與 localStorage、sessionStorage 的分工

早期網頁沒有其他選擇，Cookie 被當成一般的用戶端儲存空間。現在 MDN 建議，儲存用途改用 Web Storage API（localStorage 與 sessionStorage）或 IndexedDB，它們是專為儲存設計的，不會把資料送給伺服器，也避開了 Cookie 數量與大小有限、每個請求都得帶著走而拖慢效能的缺點。

範圍的劃分也不同。MDN 說明，localStorage 只依來源分區，sessionStorage 則依瀏覽器分頁與來源分區，關閉分頁就銷毀該分頁的資料。Cookie 的範圍則由前面介紹的 Domain 與 Path 決定。

該用哪一個，判準其實很簡單。要讓伺服器知道的資料，例如登入識別碼，就用 Cookie；只需要留在瀏覽器端的偏好或暫存，則用 Web Storage。舉例來說，深色模式如果只有前端畫面要用，放進 localStorage 就夠了，不必每個請求都帶；但伺服器要依語言回不同的頁面，這個偏好就得走 Cookie。

Web Storage 的兩套 API 都是同步的，大量資料操作可能造成阻塞，需要處理大量資料時，MDN 建議改用非同步的 IndexedDB。

Chrome、Safari 與 Firefox 的第三方 Cookie 現況

三家瀏覽器對第三方 Cookie 的預設並不相同。Chrome 預設允許，使用者可以自行封鎖；Safari 預設封鎖全部；Firefox 則不封鎖，而是把每個網站的 Cookie 分開存放。MDN 的整理也指出，Chrome 只有在無痕模式，或使用者在設定中明確封鎖時，才會擋下第三方 Cookie。

網路上不少較早的文章仍寫著「Chrome 即將淘汰第三方 Cookie」，這已經不是現況。看到這類帶著淘汰時程的說法，要先確認文章的發表時間，再對照各家的公告日期。

Chrome 仍預設允許，由使用者在設定中自行封鎖

2025 年 4 月 22 日，Google 在 Privacy Sandbox 的公告中表示，將維持現行在 Chrome 提供第三方 Cookie 選擇的做法，不會推出獨立的第三方 Cookie 提示，使用者可以繼續在 Chrome 的隱私權和安全性設定中，選擇最適合自己的選項，同時會強化無痕模式的保護。

2025 年 10 月 17 日，Google 再次發布公告，宣布淘汰 Attribution Reporting、Topics、Protected Audience 等一批 Privacy Sandbox API，同時表示 Chrome 將維持現行的第三方 Cookie 選擇方式，並持續支援已被廣泛採用的 CHIPS 與 FedCM，也維持 Private State Tokens。

兩次公告之後，Chrome 依舊預設允許，使用者可以在「設定 → 隱私權和安全性 → 第三方 Cookie」中，選擇「允許第三方 Cookie」或「封鎖第三方 Cookie」，無痕模式則預設封鎖。Chrome 的說明頁也提醒，封鎖後依賴第三方 Cookie 的網站可能無法正常運作，這時可以把該網站加入例外清單。

Safari 以 ITP 預設封鎖全部第三方 Cookie

WebKit 的 Tracking Prevention 說明寫得很直接，ITP（Intelligent Tracking Prevention）預設封鎖所有第三方 Cookie，沒有例外。第三方 Cookie 的存取，只能透過 Storage Access API 與彈出視窗的暫時相容修正取得。MDN 說明，Storage Access API 需要使用者互動並獲授權，嵌入內容才能請求存取。

對網站經營者影響較大的，是另一條 7 天規則。WebKit 指出，ITP 會刪除所有以 JavaScript 建立的 Cookie，以及其他可由腳本寫入的儲存（IndexedDB、LocalStorage、SessionStorage 等），前提是使用者 7 天沒有與該網站互動。以 JavaScript 寫入的第一方分析 Cookie 也在這條規則的範圍內，訪客超過 7 天沒與網站互動，回來時統計工具就可能把他當成新訪客。

使用者想自己調整，Apple 的說明是在 Mac 版 Safari 的「設定」→「隱私權」，勾選「防止跨網站追蹤」，第三方內容供應商的 Cookie 與網站資料就會被刪除，除非使用者以第一方網站的身分直接造訪該供應商，並與它互動。MDN 也註明，Safari 的控制較有限，可以關閉跨網站追蹤防護，但要依 frame 允許第三方 Cookie，只能靠程式碼層面的 Storage Access API。

Firefox 以 Total Cookie Protection 為每個網站分開存放

Mozilla 在 2022 年 6 月 14 日宣布，Total Cookie Protection 成為所有 Firefox 桌面使用者的預設功能。它的做法是為每個網站建立獨立的「cookie jar」，把 Cookie 限制在建立它的網站之內，追蹤公司就無法用這些 Cookie 跨站追蹤。MDN 說明，Enhanced Tracking Protection 維持預設啟用時，就會啟用 Total Cookie Protection。

和 Chrome、Safari 比起來，Firefox 的概念是分隔，而不是封鎖。第三方內容仍然可以在某個網站的範圍內放入並讀回 Cookie，只是換到另一個網站，它拿到的是另一個罐子，無法把兩邊的瀏覽記錄串在一起。

三家放在一起看，對一般網站的影響大小不一。MDN 提到，封鎖第三方 Cookie 會讓依賴它的元件異常，例如社群媒體外掛；嵌入式的登入元件、跨網站共用狀態的功能，也可能在 Safari 與 Firefox 失靈。有跨站需求的網站，常見的做法有三種：

• 明確設定 SameSite=None; Secure，宣告這個 Cookie 就是要跨站使用。
• 使用 CHIPS 的 Partitioned 屬性，讓第三方 Cookie 依頂層網站各自分開存放，MDN 註明它必須搭配 Secure。
• 透過 Storage Access API，讓嵌入內容在使用者互動後，請求存取被封鎖的第三方 Cookie。

查看與調整 Cookies 的位置

查看 Cookie 有兩條路，一般使用者從瀏覽器的設定進去，開發者則從 DevTools 的 Application 面板看。

瀏覽器改版後選單的文字常會微調，記住大方向的位置，比背下每一步更實用。

一般使用者在瀏覽器設定裡查看與刪除 Cookie

Chrome 的入口在「設定 → 隱私權和安全性 → 第三方 Cookie」，第三方 Cookie 的允許與封鎖開關就在這裡；同一頁的「查看所有網站資料和權限」會列出各網站儲存的資料，可以搜尋特定網站後刪除。

Safari 在「設定 → 隱私權」裡管理網站資料，並勾選「防止跨網站追蹤」。Apple 的說明指出，可以查看所有在 Mac 上儲存了 Cookie 與網站資料的網站，並移除其中一部分或全部，但要注意移除時可能同時變更或移除其他 App 中的 Cookie 與網站資料。Firefox 同樣在設定的隱私權與安全性相關選項裡，提供 Cookie 與網站資料的管理入口。

刪除 Cookie 之前，先想清楚後果。Chrome 的說明頁指出，刪除 Cookie 後，系統可能會把你從已登入的網站登出，也可能刪除已儲存的偏好設定。

開發者用 DevTools 的 Application 面板檢查 Cookie

在 Chrome 開啟 DevTools，切到 Application，展開 Cookies 並選一個網站，右側的表格就是這個網站設定的所有 Cookie。前面介紹過的屬性，在這裡各有一個欄位：

要辨別第三方 Cookie，看 SameSite 欄位就行。Chrome for Developers 的說明寫明，第三方 Cookie 具有 SameSite=None 屬性。DevTools 也會在 Application 與 Network 面板標示有問題的 Cookie，開發時比對屬性設定很有幫助。

這個面板除了查看，也可以篩選、編輯與刪除 Cookie，拿來測試網站在 Cookie 被改掉或消失時的行為，比憑猜測可靠得多。

網站設定 Cookie 時要守住的 4 件事

自己架站，尤其是用 WordPress 的人，不必記住 Cookie 的所有細節，先守住四件事就夠了：

1. 只放識別碼，不放敏感資料，也別塞太多或太大。MDN 建議使用伺服器可以查表的不透明識別碼，必要時也可以考慮 JWT 這類其他驗證機制。
2. 登入用的 Cookie 設 Secure 與 HttpOnly，並明確指定 SameSite，網站也要全站使用 HTTPS。每次登入時重新產生並重發工作階段 Cookie。
3. 存留時間設到夠用就好，用 Max-Age 控制，不要讓 Cookie 留得比必要的時間更久。
4. 弄清楚自己的網站已經在設哪些 Cookie，很多是系統預設就會設的。

以 WordPress 為例，開發者文件列出的預設 Cookie 就包括這幾種：

• wordpress_[hash]：登入時存放驗證資訊，只用於 /wp-admin/。
• wordpress_logged_in_[hash]：登入後設定，標示是否已登入與身分。
• wp-settings-{time}-[UID]：客製後台（可能含前台）介面的設定。
• comment_author_{HASH}、comment_author_email_{HASH}、comment_author_url_{HASH}：留言者取得的三個 Cookie，效期略少於一年，目的是下次留言免重填。
• wordpress_test_cookie：測試瀏覽器能不能寫入 Cookie，失敗時會出現「Cookies are blocked or not supported by your browser.」的錯誤訊息。

其中登入用 Cookie 的存留時間，可以用 auth_cookie_expiration 這個 hook 調整。

另外有兩個 Cookie 前綴值得知道，__Secure- 與 __Host-，它們讓瀏覽器強制 Cookie 符合安全條件。__Secure- 要求帶 Secure 並由 HTTPS 頁面設定；__Host- 在此之上，還要求不帶 Domain、Path 為 /，使 Cookie 只送給設定它的主機。MDN 指出，瀏覽器會拒絕不符合限制的前綴 Cookie。

Cookies 本身只是一小段文字，是方便還是負擔，取決於網站放了什麼、放多久、送給誰。下次打開 DevTools 的 Application 面板，不妨看看自己的網站設了哪幾個 Cookie，再逐個問一次，它有沒有存在的理由。