在考慮token是否應該儲存在cookie或localStorage中時，我們需要綜合考慮安全性、便利性、兩者的能力邊界以及設計目的等因素。 
安全性：
Cookies的優勢:
Set-Cookie: token=abc123; HttpOnly;Secure;SameSite=Strict;Domain=example.com; Path=/
HttpOnly：將 HttpOnly 屬性設定為 true 可以防止 JavaScript 讀取 cookie，從而有效防止 XSS（跨站指令碼）攻擊讀取 token。這一特性使得 cookies 在敏感資訊儲存上更具安全性。
Secure：設定 Secure 屬性後，cookie 只會在 HTTPS 連線時傳送，從而防止中間人攻擊。這確保了即使有人截獲請求，token 也不會被明文傳輸。
SameSite：SameSite 屬性減少了 CSRF（跨站請求偽造）攻擊的風險，透過指示瀏覽器在同一站點請求時才傳送 cookie。
Domain 和 Path：這些屬性限制了 cookie 的作用範圍，例如僅在特定子域或者路徑下生效，進一步提高安全性。
localStorage的缺點:
XSS 風險：localStorage 對 JavaScript 程式碼完全可見，這意味著如果應用存在 XSS 漏洞，攻擊者即可輕易獲取儲存在 localStorage 中的 token。
能力層面
Cookies可以做到更前置更及時的頁面訪問控制，伺服器可以在接收到頁面請求時，立即透過讀取 cookie 判斷使用者身份，返回響應的頁面（例如重定向到登入頁）。
// 示例：後端在接收到請求時可以立即判斷
if (!request.cookies.token) {
response.redirect('/login');
}
和cookie相比 localStorage具有一定的滯後性，瀏覽器必須先載入 HTML 和 JavaScript資源，解析執行後 才能透過在localStorage取到資料後 經過ajax網路請求 傳送給服務端判斷使用者身份，這種方式有滯後性，可能導致臨時顯示不正確的內容。
管理的便利性
Cookies是由服務端設定的 由瀏覽器自動管理生命週期的一種方式
伺服器可以直接透過 HTTP 響應頭設定 cookie，瀏覽器會自動在後續請求中攜帶，無需在客戶端手動新增。減少了開發和維護負擔，且降低了人為錯誤的風險。
localStorage需要客戶端手動管理
使用 localStorage 需要在客戶端程式碼管理 token，你得確保在每個請求中手動新增和刪除token，增加了程式碼複雜度及出錯的可能性。
設計目的：
HTTP協議是無狀態的 一個使用者第二次請求和一個新使用者第一次請求 服務端是識別不出來的，cookie是爲了讓服務端記住客戶端而被設計的。
Cookie 設計的初衷就是幫助伺服器標識使用者的會話狀態（如登入狀態），因而有很多內建的安全和管理機制，使其特別適合承載 token 等這些使用者狀態的資訊。
localStorage 主要用於儲存客戶端關心的、較大體積的資料（如使用者設定、首選項等），而不是設計來儲存需要在每次請求時使用的認證資訊。
總結
在大多數需要處理使用者身份認證的應用中，將 token 儲存在設定了合適屬性的 cookie 中，不僅更安全，還更符合 cookie 的設計目的。
透過 HTTP 響應頭由服務端設定並自動管理，極大簡化了客戶端程式碼，並確保在未經身份驗證的情況下阻斷對敏感頁面的訪問。
因此 我認為 在大多數情況下，將 token 儲存在 cookies 中更為合理和安全。
補充
然鵝 現實的業務場景往往是複雜多變的 否則也不會有token應該儲存在cookie還是localStorage上？這個問題出現了。
localStorage更具靈活性: 不同應用有不同的安全需求，有時 localStorage 可以提供更加靈活和精細化的控制。 開發者可以在 JavaScript 中手動管理 localStorage，包括在每次請求時顯式設定認證資訊。這種 靈活性 對於一些高階用例和效能最佳化場景可能非常有用。
所以一般推薦使用cookie 但是在合適的場景下使用localStorage完全沒問題。
作者：某某某人
連結：https://juejin.cn/post/7433079710382571558
