在傳統的 Web 架構中（如前面 DVWA 範例），伺服器透過 Session 和 Cookie 來紀錄使用者的登入狀態。然而，隨著現代開發全面轉向前後端分離（SPA + Mobile App），RESTful API 與 JWT（JSON Web Token） 成了身份驗證的主流。

一、 什麼是 JWT（JSON Web Token）？
JWT 是一種無狀態（Stateless）的 Token 機制。簡單來說，伺服器不需要在後端資料庫或 Redis 紀錄 Session，而是直接將使用者的身份資料（如 userId, role）包成 JSON，並用伺服器私鑰進行數位簽名（Signature）後傳給客戶端。

一個典型的 JWT 由三部分組成：

1.Header（標頭）：定義演算法（如 HS256）與 Token 類型。

2.Payload（負載）：存放使用者的基本資料與過期時間（exp）。

3.Signature（簽名）：使用伺服器密鑰（Secret Key）對 Header + Payload 計算出的驗證碼，用來防止 Token 被篡改。

二、 常見的 JWT 資安陷阱與攻擊手法
許多開發團隊使用了 JWT，卻因為設定瑕疵導致安全性大打折扣：

1. 將敏感資料以明文放入 Payload

以為 JWT 看起來像一串亂碼就是加密了。但其實 Header 和 Payload 只是用 Base64URL 編碼，任何人都能複製該字串到 jwt.io 網站直接還原並看光內容！

防禦：千萬不要在 Payload 放密碼、身分證字號、信用卡號等敏感資訊。

2. 未設定合理的過期時間（Expiration Time）

JWT 是無狀態的，一旦發放出去，在過期前都是有效的。如果沒有設定 exp，攻擊者竊取 Token 後就能永久冒充該使用者。

防禦：設定短效期的 Access Token（例如 15~30 分鐘），並搭配 Refresh Token 機制進行續期。

3. 演算法繞過漏洞（alg: "none" 攻擊）

部分不嚴謹的後端 JWT 解析庫，如果接收到 Header 寫著 "alg": "none"，會直接跳過簽名檢查並信任內容。

防禦：後端程式碼必須強行指定並鎖定驗證的演算法（如限制只能為 HS256 或 RS256）。

三、 CORS（跨域資源共享）配置陷阱
當前端呼叫不同網域的後端 API時，瀏覽器出於同源政策（Same-Origin Policy）會阻擋請求，此時就必須透過 CORS Header 來放行。

常見的危險配置：
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

危害：當後端設定 Access-Control-Allow-Origin 或是盲目信任傳進來的 Origin Header 時，任何惡意網站都可以跨域發送請求，並透過使用者的瀏覽器讀取 API 回傳的敏感資料！

正確做法：

使用白名單機制（Strict Whitelist），明確指定允許跨域存取的網域。

不要盲目在 API 回應中 reflections（反射）Origin 請求標頭。