審查 AI 生成程式碼的 5 項安全檢查：你的 Copilot 不會替你做的事

如果你用 Copilot、Cursor 或任何 AI 編碼助手超過幾週，大概已經發展出對其錯誤的第六感。變數名稱稍微不對。函式看起來正確但行為不對。你能抓到這些，因為它們會讓測試壞掉，或在上下文中看起來不對勁。

安全漏洞不是這樣。它們編譯得過。能通過 linter。看起來像是完全合理的程式碼。根據 Veracode 2026 年 GenAI 程式碼安全報告，這些漏洞有 44% 的機率會進到正式環境。

報告發現，AI 生成的程式碼安全基準通過率只有 56%。這個數字比起前幾年完全沒有進步，即使模型在撰寫功能正確的程式碼方面已經明顯變強。LLM 變聰明了，但沒有變得更安全。

以下是一份審查 AI 生成程式碼的實用檢查清單，按 AI 助手最容易漏掉的安全漏洞類別來分類。

1. 認證與 Session 管理

AI 模型在認證程式碼方面表現特別差。一篇今年發表的 arXiv 論文以 NIST SP 800-63B 認證指南為基準，評估了五個主流編碼助手，發現它們全部存在一致的失敗模式。這些模型會漏掉暴力破解防護，搞錯 session 逾時邏輯，即使被明確要求寫「安全」的程式碼，依然無法正確處理密碼儲存。研究人員測試了四種提示策略——基本、安全、NIST 標準、迭代重新提示——發現雖然重新提示能改善結果，但即使在多輪優化之後，沒有一個模型能持續通過所有安全檢查。

審查 AI 生成的認證程式碼時，檢查這三件事：

暴力破解防護： 登入端點有速率限制嗎？AI 助手經常生成接受無限次嘗試的登入處理器。加入一個計數器，追蹤每個 IP 或帳號的失敗登入次數，在達到閾值後鎖定，通常是 15 分鐘內 5 到 10 次嘗試。鎖定應是暫時的（15 到 30 分鐘），而非永久，以避免讓攻擊者對合法使用者發動阻斷服務攻擊。

Session 失效： 使用者登出時，session 真的結束了嗎？AI 程式碼常會呼叫一個登出函式，清除客戶端的 cookie，但伺服器端的 session token 依然有效。確認你的登出路徑是在伺服器端失效 session，而非只有客戶端。在 JWT 系統中這尤其危險，AI 助手經常生成只刪除 cookie 而不維護 token 黑名單或撤銷清單的「登出」端點。

密碼雜湊： 檢查程式碼是否使用 bcrypt、argon2 或 scrypt，而不是沒有加鹽的 MD5 或 SHA-256。AI 模型有時會預設使用較簡單的雜湊函式，因為這些模式在訓練資料中出現的頻率較高。在認證相關檔案中快速 grep hash( 或 md5( 能抓到大部分這類問題。同時也確認密碼重設 token 有過期時間且為一次性使用——AI 生成的重設流程經常產出沒有過期時間且無單次使用標記的 token。

2. 輸入驗證與注入防護

SQL 注入聽起來像已解決的問題。其實沒有。AI 助手生成使用字串插值的原始查詢語句的頻率比你想像的高，尤其是當提示描述一個簡單的「根據 ID 取得使用者」任務時。模型會選擇通往可運作函式的最短路徑，而那條路徑常常跳過參數化查詢。

對每個 AI 生成的資料庫互動，確認：

• SQL 查詢使用參數化語句或 ORM 的安全查詢建構器。如果你看到包含使用者輸入的字串串接在查詢中，立刻拒絕。
• Shell 指令使用參數陣列（spawn with ['ls', userPath] 而非 exec(`ls ${userPath}`)）。
• API 端點在處理前先驗證輸入型別、範圍和格式。AI 程式碼以生成直接解構 req.body 並傳給資料庫操作的 Express 路由聞名，完全沒有檢查 userId 是否真的是數字。

修復是機械性的，不是創意的。你不是在判斷程式碼是否優雅，而是在檢查使用者輸入是否接觸到任何直譯器——SQL、shell、HTML 渲染器、檔案系統——中間沒有經過消毒處理。一個有用的習慣：每次看到接收使用者輸入的 AI 生成程式碼時，在批准前先追蹤該輸入經過整個函式的路徑。如果它未經驗證或轉義就到達查詢、shell 指令、檔案路徑或回應主體，就標記它。這個單一習慣大約能抓到 Veracode 2026 年審計中發現的安全性問題的三分之一。

3. 錯誤處理與資訊洩漏

AI 生成的錯誤處理器通常有兩種極端：要嘛不存在，要嘛太詳細。兩種都是問題。

不存在的情況很直接：程式碼呼叫 API、拿到回應，然後在沒有檢查狀態碼或捕捉異常的情況下假設成功。當外部服務回傳 500 時，應用程式就崩潰，或將未定義的值往下游傳播。

太過詳細的情況更微妙。AI 助手經常生成包含堆疊追蹤、內部檔案路徑、資料庫 schema 細節或 API 金鑰的錯誤訊息。這些對做偵察的攻擊者來說是金礦。在多個 AI 生成的程式碼庫中都能看到的一種模式：錯誤處理器將完整的例外物件記錄到客戶端回應中：

res.status(500).json({ error: err })

那個 err 物件通常包含帶有絕對檔案路徑的 err.stack、帶有失敗原始查詢的 err.sql，以及偶爾滲入錯誤上下文中的環境變數。

錯誤處理的檢查清單：每個 catch 區塊應該在伺服器端記錄完整錯誤，並向客戶端回傳通用訊息。回應中不得有堆疊追蹤。不得有 SQL。不得有內部路徑。對 Node.js 後端來說，一行中介軟體就夠了：app.use((err, req, res, next) => { console.error(err); res.status(500).json({ error: 'Internal server error' }); })。AI 永遠不會替你生成這段——它預設會直接回傳錯誤物件——但加上它只需三十秒，就能關閉一整類資訊洩漏漏洞。

4. 依賴與供應鏈意識

AI 模型訓練到 2023 年及之前的程式碼，不知道 2026 年發現的漏洞。當它們建議 pip install django==4.2.0 或 npm install express@4.18.2 時，推薦的是訓練當時最新的版本，但這些版本在今天可能有重大 CVE。

這不是 AI 的錯。這是訓練資料運作方式的結構性問題。模型無法知道某個特定版本的套件有已知漏洞，除非該資訊在訓練語料中。而且即使有，模型在生成程式碼時也不會把安全性更新看得比功能正確性更重要。

修復方案：每次 AI 生成依賴宣告時，合併前先執行 npm audit 或 pip-audit。這只需幾秒，能自動抓到大多數已知漏洞。對 Docker 專案，加上 docker scan 步驟來捕捉基礎映像的漏洞。AI 助手很喜歡生成拉取 node:latest 而不指定具體摘要雜湊的 Dockerfile，意味著你的建置會拉取建置當下任何版本——包括基礎 OS 層中任何新發現的漏洞。

同時注意 AI 生成的 import 語句把整個套件匯入只為了一個工具函式。import lodash 只為了用 _.cloneDeep() 會在你的 bundle 中加入數百個函式，其中任何一個都可能藏有未來的漏洞。匯入要具體。Tree-shaking 在建置時有幫助，但無法保護你免受在到達打包工具前就危害套件本身的供應鏈攻擊。

5. 商業邏輯與授權邊界

這是最難的一類，因為它需要理解你的應用程式規則，而 AI 沒有這些規則。AI 助手不會知道只有管理員可以刪除使用者帳號，或者折扣碼只應適用於超過最低金額的訂單，或者使用者不應該能透過更改 URL 中的 ID 來存取其他使用者的私人資料。

AI 程式碼在多租戶系統的授權檢查上特別糟糕。一個常見模式：AI 生成一個像 /api/projects/:id 的路由，根據 ID 取得專案並回傳，但沒有檢查請求使用者是否屬於該專案的組織。程式碼能運作。如果你只用已授權使用者進行測試，測試也會通過。而這正是一個等待發生的資料外洩事件。

對每個 AI 生成、存取資料的路由或函式：

• 確認請求和資料存取之間有授權檢查。
• 用不同使用者的憑證測試，確認他們無法存取不該看到的資料。
• 特別注意批次操作。AI 助手喜歡生成看起來高效但沒有範圍限制的 deleteMany({}) 呼叫。

Veracode 報告發現，商業邏輯缺陷是 AI 引入漏洞中成長最快的類別，正是因為它們對靜態分析工具來說是隱形的。你的 linter 抓不到。型別檢查器抓不到。只有理解程式碼應該做什麼——而不只是它能不能編譯——的人類審查者才能抓到。

我測試過每個 AI 編碼助手都適用的一條經驗法則：如果一個路由觸及沒有明確附加到請求使用者 session 的資料，就假設 AI 忘了檢查權限。大多數情況下，你會是對的。

把這些融入你的工作流程

目標不是停止使用 AI 編碼助手。生產力提升是真實的，因為安全考量而完全拒絕它們是因噎廢食。目標是把 AI 生成的程式碼當作一位天賦極高但從未在正式系統上工作過的初級開發者的程式碼來對待：相信語法，驗證安全性。

一個實用做法：把這五項檢查加入你的 PR 審查清單。不是另開一個沒人會遵守的獨立安全審查流程，而是五個項目，就放在你已經在用的同一份清單裡：

• 認證：速率限制、session 失效、密碼雜湊正確
• 輸入：使用者輸入未經消毒不得觸及 SQL/shell/HTML
• 錯誤：堆疊追蹤記錄在伺服器端，客戶端只看到通用訊息
• 依賴：npm audit / pip-audit 乾淨，無萬用字元匯入
• 授權：每個資料存取路由檢查使用者權限，批次操作有範圍限制

對每個包含 AI 生成程式碼的 PR 執行這些檢查。一旦內化了這些模式，每次審查大約增加三分鐘。根據 Veracode 的數據，另一種選擇是 44% 的機率把漏洞部署出去。

AI 能寫的程式碼和它能保護的程式碼之間的差距還沒有縮小。在那之前，這份清單就是「能動的程式碼」和「能安全部署的程式碼」之間的差別。