用 AI 寫程式安全嗎？學會像壞人一樣檢查你的網站 — 編譯摘要
濃縮
- 反向稽核比正向找錯更快定位漏洞：與其打開程式找「哪裡寫錯」，不如先扮攻擊者問「我能拿它做什麼」，想清楚攻擊路徑後，該裝沒裝的防禦自然浮現。
- 證據：一個對所有人開放、接受任意設定鍵值、直接寫入核心設定的窗口，攻擊者一句請求就能把網站首頁網址改成釣魚站，或開放任意註冊並把新帳號預設成最高管理員，整站接管。
- 多道防禦是縱深關係，少一道都算破綻：通行證（nonce/CSRF）、查身分（capability）、關閉對外入口（移除 nopriv）、寫入白名單，這四道不是擇一，全缺就是整站被接管，稽核時不能抓到一個問題就收手。
- 證據：把四道裡任何一道拿掉，該窗口都還有風險，所以修補要當成一整組做。
- AI 只回答被問的問題，能跑不等於安全：AI 給你能跑的版本，但「沒明講、少了卻會出事」的防護（通行證、查身分、白名單）預設不補；用 AI 開發的人更需要在「能跑」之後用攻擊者視角再掃一遍。
- 證據：呼應 [[ai-是放大器]]——AI 只放大你問到的部分，沒問的它幫不了你。
質疑
結論 1：反向稽核比正向找錯快
- 前提假設：稽核者「想得到」所有攻擊路徑。
- 邊界條件：攻擊者思維只能涵蓋「已知」攻擊模式。對未見過的新型攻擊（如 [[ai-wordpress-three-blind-spots]] 提到的 Agent 行為攻擊——模擬完整使用者流程、夾帶精準參數測試），單靠想像補不上，需要正常流量基準線才認得出。
- 可靠性：來自單一示範案例而非統計，但「缺 nonce / 缺權限檢查 / 任意寫入」是 OWASP 與 WordPress 漏洞庫長年高頻案例，泛化基礎穩固。
結論 2：縱深防禦少一道都算破綻
- 前提假設：合法輸入「可以被列舉」，所以白名單有效。
- 邊界條件：當輸入空間爆炸（富文本、檔案上傳、自由格式內容），白名單難以窮舉，得改用型別驗證 + 編碼輸出等其他層。
- 換技術棧：四道鎖是 WordPress / Web 後端的具體投射，換成前端、行動 App、嵌入式系統，防禦「項目」不同，但「縱深 + 反向思考」的元規則可遷移。
結論 3：AI 只回答被問的
- 前提假設：使用者不知道要主動要求安全防護。
- 反例 / 演化：當安全規則被寫進 AI 的固定流程（Skill / checklist），AI 產出的安全性可逼近資深手寫水準——問題在流程設計，不在 AI 能力。
對標
- 瑞士起司模型（Swiss Cheese Model）：航空與醫療安全的經典模型——單層防護都有洞，把多層錯開疊起來才擋得住。完全對應「四道鎖少一道都算破綻」的縱深防禦。
- 紅隊演練 / Pre-mortem 事前驗屍：管理與資安都用「先假設失敗 / 被攻破，反推哪裡會破」的方法，與本文「先當壞人再回頭補鎖」同構；科學的否證思維也是同一招。
- 分權制衡：銀行櫃員與金庫管理員分權、[[通訊平台 Bot 安全設計]] 的白名單與身份配對，都是「查身分 + 關閉對外入口」的不同領域投射。
- 遷移場景：任何「接收外部輸入 → 執行動作」的介面都適用——API 端點、表單、Webhook 接收端（見 [[三層 API 驗證]]）、AI agent 的工具呼叫權限。AI agent 能呼叫外部工具後，「白名單化可呼叫的動作」正是同一條規則的最新戰場。
![]()