本卡屬 FR-075 掃描系列，母卡 CM-1546。掃描 jedi-iam 的「登入態、UI 路由與共用工具」模組。本棒是按業務模組垂直切——從 route 到 service 到 domain 到 repository 是一條完整的請求路徑。

這一棒在做什麼（白話）

用 Claude Code 的 claude-security plugin，掃 jedi-iam 裡「登入態、UI 路由與共用工具」這個模組（約 74 個檔），找出資安問題，產出一份報告。只找問題、不修問題——修正是後續另外開卡的事。

為什麼是「一條完整路徑」而不是「一層」：權限漏洞最常活在層與層的接縫上——route 收了一個 id，你要看到 service 才知道有沒有驗證那個 id 屬於呼叫者。只給 route 或只給 service，兩邊都看不出問題。所以這一棒把同一個模組的每一層都給你。

為什麼切這一塊

三件事合在一棒。一是登入之後的憑證生命週期——token 怎麼發、怎麼撤、登出有沒有真的失效、登入紀錄寫了什麼。S1 掃的是「怎麼證明你是你」，這一棒掃的是「證明完之後那張票怎麼管」。二是middleware：JWT 怎麼被驗、user context 怎麼被設進去——這是每一個請求都會經過的地方，而 context 設錯就是後面每一層的權限判斷都錯（已知 jedi-common 的 session_scope 在沒有 context 時會 fail-open 成 super admin，所以「context 什麼情況下會是空的」正是這一棒要回答的）。三是共用層與 plugin 預設值，不安全的預設會被所有 consumer 繼承而沒人察覺。

重點看什麼

這些是給你的思考起點，不是檢查清單——掃描工具會自己找，這裡列的是這個模組最容易出事的地方：

• middleware 怎麼驗 JWT、驗失敗時怎麼處理（loader 該 return 不該 raise）
• user context 在哪些路徑下會是空的或殘留上一個請求的值（socketio、背景工作、錯誤處理路徑）
• refresh token 的效期、輪替、撤銷；登出之後舊 token 還能不能用
• token 存哪裡、比對方式，能不能被列舉或猜測
• login_log 寫了什麼——會不會把密碼或 token 記進去
• ui_route（決定選單顯示什麼）的權限過濾，會不會洩漏使用者沒權限的功能存在
• common/utils 裡的共用函式，特別是外部連線的 TLS 設定
• plugin.py 的每一個預設值，問「這個預設是 fail-open 還是 fail-closed」

已知的舊發現（用來對照，不是答案）

2026-09-05 有一輪不完整的掃描（40 個 agent 只有 28 個回報、驗證面板從未執行），在這一塊找到過：

M-7 Redis TLS 不驗憑證（common/utils/redis_client_util.py:39）／L-3 忘記密碼遮罩預設為關（plugin.py:191，主專案已覆寫為 True，但預設不安全）

這份舊清單只是參照。你這一棒的價值在於跑完整條含驗證面板，所以：舊的沒被你的掃描找到，要在回報裡說明（是面板刪掉了，還是根本沒掃到）；你找到舊清單沒有的，那就是新收穫。完整舊清單見 compliance-manager-be repo 的 docs/features/FR-075-2609-jedi-package-security-audit/scan-findings-batch1.md。