陷阱一：未嚴格驗證簽名演算法（Algorithm Confusion）

部分老舊函式庫或未妥善配置的驗證邏輯允許 Header 中的 "alg": "none"，或者在非對稱金鑰（如 RS256）與對稱金鑰（如 HS256）切換時，誤將公開金鑰作為 HMAC 密鑰進行簽名驗證，導致攻擊者得以輕易偽造任意身分的合法 Token。

陷阱二：敏感機敏資訊直接存於 Payload

JWT 的 Payload 僅經過 Base64URL 編碼，並非加密（除非使用 JWE）。我們在代碼審查中經常發現工程師將身分證號、內部伺服器 IP、甚至密碼雜湊值存放在 Claim 中，造成嚴重的敏感資料外洩。

陷阱三：缺乏即時撤銷（Revocation）機制

無狀態（Stateless）是 JWT 的優點，也是安全管理的雙面刃。當使用者修改密碼、被停權或遭遇憑證外洩時，若系統沒有黑名單（Blacklist）或短時效 Token + Refresh Token 輪替架構，舊 Token 在過期前將持續有效。

陷阱四：密鑰強度不足或硬編碼於代碼庫

使用過於簡短的密鑰字串（如 "secret123"）容易遭到離線字典檔暴力破解。此外，將密鑰提交至 Git 版本控制系統也是常見的低級失誤。

顧問防禦檢查清單

  • 強制指定單一安全演算法（如 EdDSA 或 RS256），禁止動態依賴 Client 端傳入的 alg Header。
  • Access Token 有效期縮短至 5-15 分鐘，搭配儲存於 HttpOnly / Secure Cookie 的 Refresh Token。
  • 嚴格校驗 iss（發行者）、aud（受眾）與 exp（過期時間）標準欄位。