做Web開發(fā)的早晚會遇到這么一關(guān)登錄狀態(tài)到底該怎么存翻了一圈資料Cookie、Session、Token各說各話有的說Session安全有的說Token跨域方便還有人說Cookie早就該被淘汰了。尤其剛接觸前后端聯(lián)調(diào)或者自己寫登錄注冊功能的時候這三個概念經(jīng)常攪在一起接口調(diào)不通還以為是后端代碼寫錯了其實問題的根源全在認證機制的理解上。我當年也被這東西繞暈過后來在真實項目里跌跌撞撞踩了一圈坑才把這塊徹底理清楚。說句大實話這仨不是一個層面的東西它們之間的關(guān)系更像是“容器—存儲—憑證”的分工協(xié)作而不是三個互相對立的方案。這篇文章我不講什么高深理論就用大白話把它們的來龍去脈、底層邏輯、實際使用場景和真實項目里的坑一次說透保證你看完能馬上動手在自己項目里做取舍。1. 三者本質(zhì)先弄清它們分別解決什么問題1.1 從HTTP的無狀態(tài)聊起HTTP協(xié)議本身是“無狀態(tài)”的意思是服務(wù)器每次收到請求都像個失憶的人它不知道這次請求是不是你上次剛進來的那個人。你登錄成功之后刷新一下頁面按理說服務(wù)器應(yīng)該記得你是誰但HTTP協(xié)議天生沒這個記憶能力。這時候就需要有一種機制讓服務(wù)器“認出你”。你說簡單啊那每次請求都帶上用戶名和密碼不就行了行倒是行但每次都要明文傳密碼既不安全也極其浪費。于是人們就設(shè)計了各種更聰明的方案核心目標就一個讓你第一次證明過身份之后后面每次請求都能輕量地證明“我就是我”。這就像進健身房第一次辦了卡前臺把你信息登記了給你一把儲物柜鑰匙。以后每次來你晃一下鑰匙就行不用重新跟人家復(fù)述一遍姓名、電話、身份證號。Cookie、Session、Token本質(zhì)上都是在扮演這把鑰匙區(qū)別只在于鑰匙的樣子、存鑰匙的地方以及健身房前臺記不記得住你。1.2 一個健身房類比看懂三者的協(xié)作關(guān)系我見過很多初學者上來就搞混Cookie和Session誰包含誰其實完全可以拿健身房這個例子硬套Cookie是你掛在手上的鑰匙牌瀏覽器負責保管每次你走到健身房門口發(fā)請求給服務(wù)器它會自動把鑰匙牌遞過去。Session是健身房前臺手里的儲物柜登記冊上面寫著“鑰匙牌號為A001的人名字叫小明辦了年卡”。這個登記冊放在服務(wù)端服務(wù)器每次看到鑰匙牌號就去翻登記冊。Token是你手機上的電子通行證上面印著“本人小明年卡會員有效期到年底”還帶一個防偽簽名。健身房大門只需要驗一下簽名真?zhèn)尉湍苤苯臃拍氵M去前臺完全不用翻登記冊。所以你說三者是對立關(guān)系嗎不是。Session幾乎總是配合Cookie一起用因為Session本身只負責在服務(wù)端存數(shù)據(jù)它需要一種方式把那個“會話標識”送到瀏覽器再帶回來——Cookie剛好就是最現(xiàn)成的搬運工。Token則更像一張自帶信息的通行證可以把Session里的“登記冊”部分整個干掉但它的驗證環(huán)節(jié)需要簽名算法來支撐。1.3 三個最常被問到的核心差異這三個概念傻傻分不清本質(zhì)上是因為經(jīng)常有人在不同的層面進行比較。我?guī)湍惆阉鸪扇齻€最核心的問題第一個問題狀態(tài)到底存在哪Cookie存在瀏覽器本地Session存在服務(wù)端Token也大部分存在客戶端但Token更特殊——它把“你是誰、你有什么權(quán)限”這些信息直接編碼在憑證本身里。第二個問題服務(wù)器怎么驗證你Cookie時代服務(wù)器讀到Cookie里的內(nèi)容就能拿到身份信息Session時代服務(wù)器必須先拿著會話ID去查存儲查到了才知道你是誰Token時代服務(wù)器不需要查任何存儲直接驗簽就能確認憑證真假。第三個問題丟失了會怎樣Cookie丟了如果里面存了身份信息別人撿到就能冒充Session標識丟了因為服務(wù)端登記冊還在只要設(shè)置合理風險通?？煽豑oken丟了由于服務(wù)端不保存狀態(tài)、無法主動讓你這個Token失效危險期會一直延續(xù)到它過期為止。理解了這三條后面再看技術(shù)細節(jié)就不會亂了。2. Cookie細節(jié)深入不僅僅是“瀏覽器小餅干”2.1 Cookie的完整工作機制Cookie是服務(wù)器通過HTTP響應(yīng)頭種到瀏覽器里的一個小型文本片段瀏覽器拿到之后會按域名、路徑、過期時間等規(guī)則存起來之后每次向該域名發(fā)請求都會自動帶上匹配的Cookie。用一個最直觀的例子用任何后端語言都只是換個寫法本質(zhì)都是設(shè)置這個響應(yīng)頭Set-Cookie: sessionIdabc123xyz; ExpiresWed, 02 Nov 2026 08:00:00 GMT; Path/; HttpOnly; Secure; SameSiteLax瀏覽器收到這個響應(yīng)頭之后會在本地記錄一條Cookie鍵是sessionId值是abc123xyz域名是當前請求的域名路徑限制是/過期時間是2026年11月2日。之后你再去訪問該域名下的任何頁面請求頭里都會帶上Cookie: sessionIdabc123xyz服務(wù)器從請求頭里解析出這個Cookie就知道“哦是abc123xyz這個會話”。2.2 每個屬性都要弄明白的工程細節(jié)我見過大量Cookie相關(guān)bug幾乎都是某個屬性寫錯了導致的。這里把幾個重要屬性逐一拆開講Expires與Max-AgeExpires指定一個絕對的過期時間點Max-Age指定從設(shè)置時刻起相對存活多少秒。現(xiàn)代瀏覽器以Max-Age優(yōu)先。如果你兩個都不設(shè)置那這個Cookie就是會話級Cookie瀏覽器一關(guān)就沒了。很多“為什么下次打開還要重新登錄”的排查方向就在這里因為你種下的可能是個沒設(shè)過期時間的會話Cookie。Domain決定Cookie要送到哪個域名。默認情況下只發(fā)給設(shè)置它的那個域名但如果你設(shè)置了Domainexample.com那它的所有子域比如www.example.com、api.example.com都會收到。反過來跨域請求時前端反復(fù)跟你抱怨“為什么沒有Cookie”八成就是Domain規(guī)則沒搞對。Path路徑限制控制哪些路徑下發(fā)送。一般設(shè)成/最省心但如果你的接口里有些路徑不需要帶認證信息設(shè)了Path之后可以減少無謂的傳輸。HttpOnly這個屬性極其重要。設(shè)置之后瀏覽器禁止JavaScript腳本通過document.cookie去讀取這個Cookie。這樣即便頁面里被注入了惡意腳本攻擊者也偷不走你的會話憑證。我強烈建議任何跟身份認證有關(guān)的Cookie都必須加HttpOnly這是對抗XSS跨站腳本攻擊的第一道防線。Secure要求只在HTTPS連接下才會發(fā)送這個Cookie。生產(chǎn)環(huán)境必須開不然在Wi-Fi環(huán)境下中間人攻擊者裸奔在網(wǎng)絡(luò)上就能抓到你的Cookie。SameSite這是應(yīng)對CSRF跨站請求偽造的關(guān)鍵武器。Strict表示跨站請求一律不帶CookieLax表示跨站場景下只有頂級導航比如你從郵件點鏈接跳轉(zhuǎn)到該網(wǎng)站才帶Cookie一般子資源請求、跨站AJAX都不帶None表示任何場景都帶但前提是必須同時設(shè)置有Secure屬性。現(xiàn)在主流瀏覽器默認SameSite就是Lax這也是為什么很多舊系統(tǒng)升級到新版瀏覽器之后第三方登錄回跳突然拿不到Cookie的原因之一。2.3 Cookie的邊界別把什么都往里塞Cookie雖方便但它絕對不是用來裝大數(shù)據(jù)的。瀏覽器的Cookie容量很小一般單域名Cookie總量也就4KB左右這是瀏覽器的實際實現(xiàn)約束不是RFC強制規(guī)定單個Cookie大小在幾千字節(jié)以內(nèi)數(shù)量上也有限制。除了體積限制還有個更要命的問題Cookie會在每次請求時自動攜帶。如果你把一個大對象塞進Cookie那么你的每個請求頭都會被撐大不僅浪費帶寬某些網(wǎng)關(guān)或代理甚至可能因為請求頭過大直接給你返回4xx錯誤。我見過有人把整份用戶資料JSON序列化之后塞進Cookie的結(jié)果接口頻繁報錯做了半天排查才發(fā)現(xiàn)是Cookie體積超標。正確的做法是Cookie里只放一個不透明的標識符比如會話ID或者Token具體數(shù)據(jù)存在服務(wù)端或者編碼在憑證本身里。2.4 為什么不能只在Cookie里存用戶名有人會問那我把用戶名直接存進Cookie服務(wù)器讀出來不就知道我是誰了嗎何必搞Session和Token這個方案不是完全不行但有兩個問題繞不過去。第一你沒法校驗這個Cookie是不是被篡改過的。你存一個usernameadmin攻擊者直接在瀏覽器里改成usernameroot服務(wù)器毫無察覺地就信了。第二你沒法控制它失效。用戶改密碼、管理員封號Cookie還在用戶依然能繼續(xù)訪問。真正合理的做法是Cookie里存的是無法被普通人偽造的隨機憑證或簽名憑證服務(wù)器驗證的是這個憑證本身而不是直接信任憑證明文里的信息。這也是Session和Token這兩個方案存在的根本意義。3. Session機制深挖服務(wù)端的“登記冊”3.1 Session的工作流程與存儲位置Session方案的核心思想是把用戶狀態(tài)放在服務(wù)端客戶端只保留一個會話ID。完整流程是用戶提交用戶名密碼服務(wù)器校驗通過后創(chuàng)建一個Session記錄并生成一個隨機的Session ID。服務(wù)器通過Set-Cookie把Session ID發(fā)給瀏覽器。瀏覽器后續(xù)請求自動攜帶這個Session ID。服務(wù)器根據(jù)Session ID去Session存儲里查找對應(yīng)的數(shù)據(jù)比如用戶ID、角色權(quán)限、過期時間。如果找到且沒過期就認為請求已認證繼續(xù)處理業(yè)務(wù)。這里Session ID本身通常不帶業(yè)務(wù)含義它就像一把鑰匙上的編號號碼本身沒有意義關(guān)鍵是服務(wù)端的“登記冊”里對應(yīng)那條記錄。實際項目里Session數(shù)據(jù)可以存哪從簡單到復(fù)雜有幾種選擇內(nèi)存存儲直接存在服務(wù)器進程內(nèi)存里讀快但麻煩多——服務(wù)一重啟就全沒了而且多實例部署的時候沒法共享。外部緩存最常用的是Redis所有后端實例共用一份Session數(shù)據(jù)服務(wù)重啟不影響多機部署也能正常工作。數(shù)據(jù)庫可以存關(guān)系型數(shù)據(jù)庫或文檔數(shù)據(jù)庫除非有審計和離線分析需求否則一般沒必要因為性能問題首選數(shù)據(jù)庫。生產(chǎn)環(huán)境我基本只用Redis方案原因很簡單Session最需要的就是“快”和“共享”Redis兩個都能滿足。3.2 Session ID的生成與傳輸細節(jié)Session ID看起來只是一個隨機字符串但它的生成質(zhì)量直接決定安全性。如果生成的ID可以被預(yù)測比如按序號遞增攻擊者就可以通過偽造ID去冒充別人。所以Session ID必須使用足夠強的隨機源生成比如加密安全的隨機數(shù)生成器讓它不可猜測、不可預(yù)測。傳輸上前面已經(jīng)說了是借助Cookie。這里有個細節(jié)這個Cookie的名字不一定要叫sessionId你可以自定義但要注意的是它必須被設(shè)為HttpOnly并且名字別跟業(yè)務(wù)Cookie撞上。有些框架默認生成的名字可能會跟你的業(yè)務(wù)Bean字段重復(fù)導致解析錯亂這種問題排查起來特別隱蔽。3.3 Session的過期策略與“記住我”邏輯Session不會永久有效否則服務(wù)端存儲會越積越多。常見策略是設(shè)置一個過期時間比如30分鐘。到期之后用戶重新訪問就相當于未登錄狀態(tài)。這里有個產(chǎn)品層常見的需求“用戶主動關(guān)掉瀏覽器再打開還是要保持登錄?！鼻懊嬲f過會話級Cookie會在瀏覽器關(guān)閉時失效。要實現(xiàn)“記住我”的效果在做登錄的時候就需要手動把Cookie的過期時間一并拉長——但要注意這不等于讓Session永不過期。你必須同時考慮服務(wù)端Session的過期時間應(yīng)該大于或等于Cookie的過期時間否則Cookie還在服務(wù)端記錄卻已經(jīng)沒了用戶看到的依然是“登錄過期請重新登錄”的提示。還要提一下“滑動過期”與“固定過期”的區(qū)別?；瑒舆^期意味著只要用戶一直有操作每次操作就往后續(xù)期固定過期則是不管活動與否到期一律踢下線。金融、政務(wù)類系統(tǒng)喜歡固定過期防止有人人走忘記關(guān)電腦普通互聯(lián)網(wǎng)產(chǎn)品大多用滑動過期體驗更順滑。兩種模式?jīng)]有絕對的好壞按業(yè)務(wù)安全等級選就行。3.4 Session方案的集群困境與解法Session有一個很樸素的問題如果應(yīng)用部署了多臺服務(wù)器用戶在A服務(wù)器登錄了Session存在A的內(nèi)存里下一次請求被負載均衡轉(zhuǎn)發(fā)到B服務(wù)器B去存儲里查不到這個Session用戶就被當成未登錄了。解法有三個方向按成本從低到高排列Session粘滯Sticky Session讓負載均衡把同一個用戶的所有請求固定轉(zhuǎn)發(fā)到同一臺服務(wù)器。配置簡單但機器故障或發(fā)布擴容時還是會出問題。Session共享把Session集中存到Redis之類的獨立存儲里所有服務(wù)器實例都從同一處讀寫。這是最常用的生產(chǎn)方案既能橫向擴容也能平滑發(fā)布。無狀態(tài)化改造壓根不用Session改用Token方案讓服務(wù)器不需要保存任何會話狀態(tài)。這個徹底解決了共享問題但也帶來了Token特有的挑戰(zhàn)下一節(jié)詳聊。4. Token認證深度解析把信任寫進憑證里4.1 JWT的結(jié)構(gòu)與簽名原理Token這個詞含義很廣但實際工作中只要說Token絕大多數(shù)人默認指JWTJSON Web Token。JWT由三部分組成Header聲明類型和簽名算法比如{alg:HS256,typ:JWT}。Payload放自定義聲明比如用戶ID、過期時間、角色等。Signature對前兩部分做簽名得到的防偽串。三部分各自做Base64編碼然后用點號拼起來最終長這樣eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c這里必須強調(diào)一個原則JWT是簽名不是加密。Payload部分做的是Base64編碼任何拿到Token的人都能直接解碼看到里面的明文內(nèi)容。所以絕不允許往Payload里塞密碼、手機號、身份證號之類的敏感數(shù)據(jù)。簽名的作用是防篡改不是防偷看。簽名過程用HS256算法來舉例的話驗證邏輯就是拿同樣的密鑰重新把Header和Payload拼起來算一遍HMAC比對算出來的簽名和Token自帶的簽名是否一致。只要密鑰不泄露哪怕攻擊者把Payload里的role從user改成admin算出來的簽名也對不上服務(wù)器直接拒收。4.2 Token方案為什么更適合前后端分離和微服務(wù)Session時代每個服務(wù)都需要訪問同一個Session存儲才能認出用戶。走到微服務(wù)架構(gòu)時問題會變得非常麻煩每個服務(wù)都得配置到同一個Redis的連接某次緩存抖動可能影響所有服務(wù)。Token方案則完全繞開了這個問題。只要服務(wù)端能校驗Token簽名它就能信任Token里攜帶的身份信息而不需要去翻存儲。這讓認證邏輯變成了一個純粹的計算動作天然適合API網(wǎng)關(guān)、微服務(wù)、移動端App這類多端、多服務(wù)的場景。內(nèi)部服務(wù)之間調(diào)用也可以彼此傳遞同一個Token各自驗簽完事。還有一個場景是移動端。App不是瀏覽器沒有一個自動管理Cookie的容器雖然理論上也可以手動管理Cookie但姿勢極其別扭。Token方案下App拿到Token后存在本地安全存儲里每次請求時手動加到Authorization請求頭即可這才是移動端的標準玩法。4.3 Token的過期時間與Refresh Token設(shè)計Session可以設(shè)置服務(wù)端過期時間到期不及時續(xù)期就失效。Token卻有個特性服務(wù)端無法主動讓它失效。因為服務(wù)端根本不保存Token的狀態(tài)一個還沒到期的Token即便用戶已經(jīng)注銷甚至被管理員封禁它在剩余有效期內(nèi)依然可以正常使用。要解決這個問題通常有兩種策略第一種策略是設(shè)置短生命周期Token。比如讓Token只存活15分鐘。但15分鐘一到用戶就被強制要求重新登錄這體驗太差了。于是引入Refresh Token——一個更長生命周期的憑證比如7天甚至30天專門用來在Access Token過期之后去換一個新的Access Token。用戶無感知地續(xù)期服務(wù)端要“踢人”時只需要讓Refresh Token失效下一次換取新Token時就能攔住。第二種策略是在服務(wù)端維護一個Token黑名單或Token白名單。黑名單存儲“還沒到期但已被吊銷”的Token白名單則把所有有效Token存下來。這兩種做法本質(zhì)上又引入了服務(wù)端狀態(tài)Token“無狀態(tài)”的優(yōu)勢就打了折扣但某些安全等級高的業(yè)務(wù)只能這么做屬于典型的“用復(fù)雜度換控制權(quán)”。我在實際項目里的取舍是普通互聯(lián)網(wǎng)產(chǎn)品Access Token短命Refresh Token長命就夠了金融、后臺管理類系統(tǒng)再疊加一個服務(wù)端白名單多一道保險。4.4 Token到底放哪里localStorage還是HttpOnly CookieToken方案下還有一個經(jīng)典爭論Token該存在瀏覽器哪個位置存在localStorage里JavaScript可以自由讀取每次請求手動塞進Authorization請求頭。好處是跨域場景比較靈活缺點是只要頁面被注入惡意腳本Token就能被直接偷走而localStorage對這類攻擊完全沒有防護。存在HttpOnly Cookie里瀏覽器自動攜帶腳本讀不到。這解決了XSS竊取問題卻引來了CSRF問題——因為Cookie是自動攜帶的攻擊者可以在另一個站點偽造請求讓你的瀏覽器帶著Cookie發(fā)出危險操作。好在有SameSite屬性和CSRF Token機制可以兜底。我在項目里的默認推薦是如果前端是純靜態(tài)頁加API服務(wù)且跨域不是特別復(fù)雜的場景優(yōu)先放HttpOnly Cookie因為它的XSS風險面更小如果業(yè)務(wù)必須支持完全跨域的API調(diào)用再把Token放到安全存儲里手動管理。沒有絕對安全的方案只有結(jié)合自己業(yè)務(wù)的取舍。5. 三者的橫向?qū)Ρ扰c選型決策說了這么多原理落到選型這一步直接給一張對比表方便你收藏以后查。對比維度Cookie直接存身份信息SessionTokenJWT狀態(tài)存儲位置瀏覽器服務(wù)端憑證本身服務(wù)端是否存儲狀態(tài)否是否純無狀態(tài)時服務(wù)端擴容難度無需處理需要共享存儲天然易擴容身份信息篡改難度容易明文不容易依賴服務(wù)端不容易依賴簽名主動失效能力強刪Cookie即可強刪Session即可弱到期前無法主動失效跨域支持差受同源策略限制差依賴Cookie好可放請求頭移動端適配麻煩麻煩標準做法典型場景簡單個人偏好記錄傳統(tǒng)服務(wù)端渲染應(yīng)用前后端分離、微服務(wù)、App選型的時候我一般按這個思路來快速判斷做傳統(tǒng)服務(wù)端渲染的Web系統(tǒng)比如Java Thymeleaf / PHP / 服務(wù)端模板直接用Cookie Session模式成本最低、框架支持最好、安全模型也成熟。做前后端分離的單頁應(yīng)用如果業(yè)務(wù)只在自家域名內(nèi)跑可以用Session方案也可以把Token放在HttpOnly Cookie里如果接口要給多個域名共用直接上Token方案配合Refresh Token。做純移動端App或小程序直接用Token方案這是移動端的事實標準。做公共服務(wù)平臺或微服務(wù)架構(gòu)TokenJWT配合網(wǎng)關(guān)統(tǒng)一鑒權(quán)幾乎是唯一合理的選擇。記住一個原則沒有絕對先進的方案只有當前場景下是否合適。好幾年前有人天天鼓吹“Token已全面取代Session”我在實際項目里看到不少傳統(tǒng)系統(tǒng)里的Session依然跑得很健壯反而是強行上Token后因為失效機制沒做完善用戶被無故踢下線體驗還不如原來。6. 實戰(zhàn)排查這幾個常見坑你遲早會遇到6.1 登錄成功了但刷新頁面就失效遇到這種問題先按順序排查三個點第一服務(wù)端種下的Cookie有沒有設(shè)置過期時間。沒有Expires也沒有Max-Age的話這個Cookie就是會話級Cookie瀏覽器一關(guān)就沒了頁面刷新可能沒事但下次新開Tab就會失效。第二Cookie過期時間與Session過期時間是否匹配。常見做法是Cookie設(shè)了30天但Session存儲只存活30分鐘時間一到服務(wù)端記錄就沒了Cookie還在又有什么意義我建議Cookie死活時間跟Session存儲的過期時間對齊要么一起長命要么一起短命。第三Session存儲是否因為重啟而丟失。如果你用的是內(nèi)存Session存儲每次后端服務(wù)重新部署后所有登錄用戶都會被清掉。生產(chǎn)環(huán)境不能這么玩至少得換Redis。6.2 跨域請求怎么都帶不上Cookie這是前后端分離項目里最常見的問題。瀏覽器跨域請求不會自動帶上目標域名的Cookie前端和后端需要同時做三件事才能打通前端請求要開啟withCredentials在fetch里對應(yīng)credentials: include后端的CORS響應(yīng)頭必須明確指定允許的Origin不能用*并且設(shè)置Access-Control-Allow-Credentials: true后端種Cookie時SameSite屬性不能為Strict否則部分跨站場景下根本不會發(fā)送。以上三個條件缺一個跨域登錄就會失敗而且瀏覽器報錯往往只是輕飄飄一句“CORS error”讓人不知道到底是哪里掛了。排查時直接打開Network面板看請求頭里有沒有Cookie以及響應(yīng)頭里的Set-Cookie有沒有被瀏覽器攔截能幫你快速定位問題在哪一端。6.3 Token過期了用戶還在頁面上提交時才告訴你重新登錄這個坑幾乎只出現(xiàn)在沒做自動續(xù)期的Token項目里。Access Token存活期太短用戶停留在頁面上瀏覽太久Token悄悄過期了用戶毫無感知一提交表單直接被彈回登錄頁寫了半天的內(nèi)容全沒了。這是極其勸退的產(chǎn)品體驗。解決方案是分兩條腿走第一必要的地方加心跳檢測——定時用一個輕量接口驗證登錄態(tài)快過期時主動用Refresh Token換新Token第二在發(fā)起業(yè)務(wù)請求遇到“認證失敗”時先嘗試用Refresh Token靜默續(xù)期一次續(xù)期成功就重放剛才的請求。這樣用戶全程無感知體驗自然就順了。還要提醒一句Refresh Token必須要比Access Token更小心保存。它權(quán)力更大、壽命更長一旦泄露等于“永久的鑰匙”。有條件的話Refresh Token應(yīng)該做設(shè)備綁定防止別人拿你的Refresh Token去別的設(shè)備換Token。6.4 明明設(shè)置了HttpOnly跨站腳本還是偷到了數(shù)據(jù)HttpOnly只是保護Cookie不被JS讀取但它管不住攻擊面更大的API接口。一個典型的攻擊鏈路是攻擊者在頁面里注入腳本腳本不會去讀document.cookie而是直接向服務(wù)端發(fā)請求拉數(shù)據(jù)——因為只要瀏覽器帶了有效的認證Cookie這個請求在服務(wù)端看來完全合法。所以HttpOnly不等于免疫XSS。該做的防御還是要做所有輸入要校驗、輸出要轉(zhuǎn)義、內(nèi)容安全策略CSP要配好、持久型XSS要重點防。認證憑證這塊再安全輸入口被打穿一樣防不住。6.5 Cookie體積過大導致請求異常我之前排查過一個詭異的問題接口在測試環(huán)境一切正常生產(chǎn)環(huán)境偶爾報錯而且報錯完全沒有規(guī)律。后來看網(wǎng)絡(luò)日志才發(fā)現(xiàn)一個請求的Header體積已經(jīng)超過2KB而生產(chǎn)環(huán)境的網(wǎng)關(guān)對Header總大小有限制超過就拒絕處理。原因就是有人把用戶菜單數(shù)據(jù)序列化塞進了Cookie每幀請求都帶著這一大包走自然容易觸頂。這種問題排查起來非常費勁因為你自己瀏覽器里未必復(fù)現(xiàn)等到高流量機器上日志刷屏才發(fā)現(xiàn)是Header超限。好的實踐是Cookie里只放ID數(shù)據(jù)走接口拉或者只放簽名過的Token業(yè)務(wù)數(shù)據(jù)一律放服務(wù)端。請求頭越瘦出問題的概率越低。6.6 同一個瀏覽器前后登錄的賬號狀態(tài)串了多賬號切換在同一瀏覽器下是隱藏高頻事故點。常見場景是用戶先登錄A賬號退出后又登錄了B賬號結(jié)果頁面顯示的卻還是A賬號的某些信息。原因往往在于退出登錄時只刪了業(yè)務(wù)側(cè)的登錄態(tài)沒刪干凈或者Token的Key使用了固定的字符串不同用戶之間產(chǎn)生了緩存覆蓋。解決這個問題沒有太多花活就是規(guī)范好狀態(tài)生命周期登錄時統(tǒng)一寫入退出時統(tǒng)一清除多個頁面Tab之間盡量用同一套會話狀態(tài)管理邏輯不要在業(yè)務(wù)里到處手動改認證數(shù)據(jù)。你偷懶跳過哪一步線上就會以詭異的方式回報你。用經(jīng)驗說話幾個掏心窩的建議嘮了大半天理論、實操、坑都聊了最后分享幾個我這些年積攢下來的切身體會。第一個建議是別一聽“Token更新”就無腦遷移。技術(shù)上哪種方案更“先進”不重要重要的是你的業(yè)務(wù)場景更適合哪種。老系統(tǒng)用Session好好的你沒有充分理由就別折騰。第二個是認證這塊一定要灰度上線。不管是Session存儲從內(nèi)存換成Redis還是從Session方案切到Token方案都別一把梭。先挑一個低風險模塊做小流量驗證觀察認證錯誤率、用戶反饋、服務(wù)端異常日志再逐步擴大范圍。我見過太多人一把切過去第二天早晨線上單子滿天飛。第三個是寫登錄認證相關(guān)的代碼時把日志打到位。認證失敗和業(yè)務(wù)失敗不一樣它需要看到“是誰在什么時間從哪里請求了什么接口、為什么被拒”。沒有充分日志的時候排查認證問題就像閉著眼睛找東西效率極其低下。說回標題那三個詞——Cookie、Session、Token它們沒有哪個該被踩到泥里也無所謂誰“更好”。它們回答的是同一個問題只是答案的思路不同。你在任何項目里只要想清楚“狀態(tài)放哪”“怎么驗證”這兩件事再根據(jù)實際場景權(quán)衡一下安全、體驗、復(fù)雜度選型就不會出錯。這套思路我用到現(xiàn)在還沒遇到過它們擺脫不掉的場景。