Day 11 我把功能驗收寫成 Scenario，讓 LLM 透過 Playwright MCP 依照前置條件操作頁面。Scenario 確認的是：使用者依既定步驟操作時，畫面與流程是否符合預期。

Scenario 的驗證範圍只涵蓋既定情境。它不會自動確認使用者變更單號時後端是否仍執行授權檢查、登出後是否清除前一位使用者的草稿，也不會確認前端隱藏按鈕後 API 是否仍可被直接呼叫。

因此，我把 Step 7 加入 Security Agent ，會針對本次異動從資安角度再檢查一次；我確認修法與風險後，才更新功能文件。

• 網頁資安涵蓋 SQL Injection、登入狀態、權限、API 資料、前端暫存與設定。
• DAP 的 Security Agent 在「回上一步調整」功能中，發現登出後未清除草稿與購物車；帳號切換後，下一位使用者可能看見前一位的暫存資料。
• Agent 負責找出疑點與建議修法；我確認結果與剩餘風險，再把已接受的做法寫進文件。

網頁資安不只是在防 SQL Injection

SQL Injection 是常見的網頁資安問題。後端若把使用者輸入直接串進 SQL，資料可能被錯查、錯改，甚至執行不該執行的指令。

有登入、表單、角色與 API 的系統，還需要處理下面幾類風險。

其中最容易被低估的是權限。前端依角色隱藏按鈕，只處理使用體驗；真正的授權必須由後端在 API 層確認登入者能否讀取、修改或執行這一筆資料。OWASP 也提醒，API 若使用客戶端提供的 ID 存取資料，伺服器端需要檢查該使用者是否有權操作那筆物件。OWASP API1: Broken Object Level Authorization

我原本以為資安審查主要會看 XSS、SQL Injection 或 Token。實際把 DAP 的流程跑起來後，第一個具體案例卻是帳號已經切換，前端仍保留上一位使用者的資料。

一個改善體驗的功能，藏著帳號切換後的資料問題

Spec 082 的功能是「回上一步調整」。使用者填完申請並送出後，可以回到前一頁修改，不必重新填完所有欄位。前端為此暫存表單草稿、購物車與部分送出結果。

這項設計改善了表單調整的體驗，也帶來帳號切換後的資料隔離需求。Security Agent 在 Step 7 檢查同一個瀏覽器分頁的登入切換：使用者 A 登出、使用者 B 登入後，記憶體中的暫存資料必須清除。

Repository 的審查紀錄顯示，原本的登出流程沒有完整清除這些 state。帳號 B 在特定情況下可能看見 A 的草稿、購物車或暫存送出資料。問題不在 API 攻擊或 SQL 語法，而在帳號已切換、前端 state 仍停留在前一位使用者身上。

使用者 A 填表 → 前端暫存草稿
       ↓
同分頁登出 → 使用者 B 登入
       ↓
未清除暫存時，B 可能看到 A 的資料
       ↓
登出時統一清除相關 state

修法是在登出時同時清除認證狀態、草稿、購物車、暫存送出結果與摘要。後來另一個姓名查詢快取也出現同類風險，讓我留下明確規則：新增全域前端 cache 時，同時檢查登出後的清除行為。

Security Agent 把資安檢查整理成可確認的結果

DAP 的 Security Agent 讀取本次的 Spec 與異動範圍，檢查資料輸出方式、登入與 API 安全慣例、依賴套件，以及前端暫存是否跨使用者殘留。審查結果會列出已檢查項目、疑點、建議修法與需要人工決定的風險。

SQL Injection 也在檢查範圍內。使用者輸入不能直接拼到 SQL；值採參數化查詢，無法參數化的資料表名、欄位名或排序欄位限制在 allowlist。前端驗證不取代後端驗證。

OWASP 將權限、登入狀態、Injection、設定與 API 授權列為 Web 與 API 的主要風險。OWASP Top 10、OWASP API Security Top 10

Security Agent 的輸出包含本次已檢查的項目、發現的疑點、建議修法，以及需要我決定的剩餘風險。

資安檢查完成後，由人確認再更新文件

目前 DAP 的流程如下：

Spec / Plan / Task
  ↓
實作與 Scenario
  ↓
Security Agent 審查本次異動
  ↓
issue 與修法（若有）
  ↓
我確認資安結果
  ↓
文件更新

Security Agent 完成資安檢查後，我會確認檢查結果、修法是否符合需求、清除資料的時機是否保留原有流程，以及剩餘風險是否可接受。確認完成後，才更新這次功能的文件。

文件會成為下一個 LLM session 或接手同仁理解專案的 context。因此文件只記錄已確認的修法、限制與規則，避免把尚未接受的做法寫成既定流程。

目前留下的是功能層級的審查紀錄，範圍涵蓋本次異動與相關風險。外部滲透測試、全系統掃描與正式環境資安認證不在這個流程的範圍內。這個停點讓風險能在結案與文件更新前被確認。

今天可以做的：替一個已完成變更留下 Security Review

今天不需要建立完整的 Security Agent。選一個剛完成、會讀取使用者輸入、API 資料或設定檔的改動，替它留下一份小型 Security Review。

把本次的 Spec、Scenario 與 Git diff 提供給 Claude Code，要求它只針對這次變更列出接觸到的資料、既有慣例與疑點。

# Security Review｜功能名稱

## 範圍
- 本次異動檔案：
- 對應 Spec／Scenario：
- 會接觸的輸入、設定檔或 API 資料：

## 檢查
- [ ] 確認使用者無法透過 ID、角色或狀態操作不屬於自己的資料。
- [ ] 確認登入、登出、權限與既有 HTTP 安全封裝沒有被破壞。
- [ ] 確認不可信資料沒有被不安全地渲染、拼 URL、拼 SQL 或執行。
- [ ] 確認敏感資料不會被輸出或錯誤暫存，並定義登出後的清除規則。
- [ ] 確認本次沒有新增不必要的套件、權限、外部連線或設定。

## 結果
- 通過：
- Issue／修復建議：
- 人工確認：
- 文件可否更新：

可以提供 Claude Code 這段指令：

請讀取本次 spec.md、scenarios.md 與 Git diff，只審查這次變更。
請檢查：資料是否可能跨使用者殘留、前端是否誤當成權限邊界、
不可信輸入是否會被不安全地輸出或執行、既有登入與 HTTP 慣例是否被繞過，
以及是否新增不必要依賴或設定。
輸出通過項目、issue、證據位置與最小修復建議。
不要宣稱「完全安全」；不確定之處請列為待人工確認。

先把審查範圍寫小、寫清楚，再讓 AI 依據本次異動檢查，結果會比泛泛地檢查整個專案更容易確認。

小結：功能完成後，還要確認資料留在對的人身上

082 原本是改善表單調整體驗的功能。Security Agent 讓我看到資料暫存的邊界：資料可以為同一位使用者保留，但帳號切換後必須清除。

Step 7 把資安審查放在程式完成與文件更新之間。Agent 先列出疑點與修法，我確認結果與邊界，文件再收錄已經接受的做法。

下一篇會接著說明，Spec、Plan、Scenario 與 Security Review 都留下來後，文件如何成為下一次 AI 理解專案的輸入。

參考資料

• OWASP. OWASP API Security Top 10 – 2023.
• Anthropic. Automated Security Reviews in Claude Code.