昨天請 Codex 當第二雙眼睛，Review 重構 commit 中是否有一般程式問題。

今天把檢查範圍縮小到安全面。

不過我不會只問「這個專案安全嗎？」因為安全不是一個能用「是」或「否」回答的問題。

為什麼「安全嗎？」太模糊？

收到這種問題時，Codex 可能列出一長串通用建議：

• 防止 SQL Injection
• 檢查認證與授權
• 使用 HTTPS
• 保護 API 金鑰
• 更新相依套件

這些都是常見安全主題，但目前的 Issue Tracker 是只在瀏覽器執行的前端專案，沒有資料庫、後端 API、登入或不同使用者權限。

如果不先限定系統範圍，安全 Review 很容易變成和目前程式無關的檢查清單。

先看目前真正存在的資料流

現在的資料流很簡單：

使用者輸入任務標題
-> React 處理與顯示
-> 任務資料寫入 localStorage
-> App 啟動時從 localStorage 讀回

這裡有兩個外部輸入來源：

• 使用者在表單輸入的文字
• 瀏覽器 localStorage 中已存在的資料

即使 localStorage 是由應用程式自己寫入，使用者、瀏覽器工具或其他同來源程式仍可能改變內容，因此讀回時不能假設資料一定符合預期格式。

今天要檢查哪些安全面？

針對目前專案，我只檢查四個方向。

1. 使用者輸入如何顯示

任務標題是使用者可控制的內容。要確認程式將它當成文字呈現，而不是直接當成 HTML 執行。

React 一般的 JSX 文字插值會處理輸出；真正需要特別注意的是 dangerouslySetInnerHTML 或直接操作 DOM HTML 的程式。React 官方文件也提醒，只能把可信任且經過處理的資料交給 dangerouslySetInnerHTML。

2. localStorage 資料如何讀取

要確認程式遇到空值、無法解析的 JSON 或不符合預期結構的資料時會怎麼處理。

這類問題不一定都是可被利用的安全漏洞，也可能只是造成頁面無法啟動的穩定性問題。Review 時要正確分類，不要看到外部輸入就全部標成高風險。

3. 前端是否包含敏感資訊

瀏覽器會下載前端程式，因此打包進前端的值不能被當成秘密。

要檢查原始碼、設定與 Git 歷史是否意外包含 Token、密碼、私密 API 金鑰或本機憑證。即使變數名稱寫成 secret，只要送到瀏覽器，使用者仍然能查看。

4. 相依套件與設定

檢查 package.json 與 lockfile 是否有不必要、來源可疑或已知有風險的套件，也要確認專案沒有為了小功能引入過大的依賴。

相依套件工具回報的項目仍需要確認實際版本、使用方式與可利用條件，不能只看到警告數量就判定專案一定存在同等嚴重的漏洞。

今天使用的 Prompt

我會開一個新的 Codex 任務，輸入：

請對目前的 Issue Tracker repository 做一次防禦性安全 Review。
這次只分析，不要修改任何檔案。

專案範圍：
- React + TypeScript 的純前端應用程式
- 任務資料保存在瀏覽器 localStorage
- 目前沒有後端、資料庫、登入、認證或授權

請先建立目前的資料流與信任邊界，再檢查：
1. 使用者輸入的任務標題是否可能被當成 HTML 或程式執行
2. 是否使用 dangerouslySetInnerHTML 或其他不安全的 DOM 寫入方式
3. localStorage 內容遭到修改、損壞或不符合預期格式時的處理
4. 原始碼、設定檔與 Git 追蹤檔案中是否包含敏感資訊
5. package.json 與 lockfile 中是否有具體可證實的相依套件風險
6. 錯誤處理是否可能顯示不應暴露的資訊

輸出規則：
- 只回報能由目前程式或工具輸出支持的 findings
- 每項附上嚴重度、檔案與行號
- 說明攻擊或觸發前提、可能影響與最小修正方向
- 區分安全漏洞、穩定性問題與一般改善建議
- 認證、授權、SQL Injection 等目前不存在的攻擊面，請標示為不適用，不要列成 finding
- 如果沒有具體安全 finding，請直接說明

限制：
- 不要修改檔案
- 不要安裝套件
- 不要執行破壞性或會外傳資料的測試
- 不要為了完整而編造風險

這段 prompt 的回覆

收到 finding 後怎麼辦？

和昨天的 Code Review 一樣，Codex 的安全 finding 也要人工驗證。

確認：

1. 它指出的程式真的存在
2. 攻擊或觸發前提在目前專案成立
3. 提供的輸入能重現描述的結果
4. 影響是否和嚴重度相符
5. 問題究竟是安全漏洞、穩定性缺陷或一般建議

例如損壞的 localStorage 讓自己的頁面無法載入，確實需要處理，但它和攻擊者能讀取其他使用者資料不是同一種影響。

如果找到真實問題呢？

先保存 finding 的位置、觸發方式與影響，再另外建立修正任務。

修正時仍然採用前幾天的流程：

確認問題
-> 建立能重現的測試
-> 做最小修正
-> 執行完整驗證
-> Review diff

今日小結

今天沒有只問 Codex「這個專案安全嗎？」，而是先限定目前純前端 Issue Tracker 的資料流，再檢查輸入顯示、localStorage、敏感資訊與相依套件。