87% 的 AI 寫程式 PR 有資安漏洞：Claude Code vs Codex vs Gemini 完整解析

本文是社群貼文的完整延伸版。社群版講了核心數字，本文加上六大漏洞類型深度解析、為什麼傳統工具抓不到、以及台灣企業可以立即執行的安全檢查清單。

---

重點回顧

DryRun Security 讓 Claude Code、OpenAI Codex、Google Gemini 三款 AI 程式 Agent 從零建立兩個真實應用，掃描每一個 pull request，結果是：30 個 PR 裡 26 個有漏洞，漏洞率 87%。

更值得注意的不是數字本身，而是模式：六個漏洞類型在三款 Agent、兩個完全不同的應用裡反覆出現。問題不是偶發的，是結構性的。AI 不是不懂安全概念，它是不知道要把安全組件串接起來。

對台灣正在導入 AI 開發工具的工程師和企業來說，這份研究的意義是：你現在用來 review 程式碼的方法，很可能抓不到 AI 最常犯的那類錯誤。

---

【獨家】六大漏洞類型，為什麼是這六個？

這份研究最讓我感興趣的部分，不是某款 Agent 表現特別差，而是六個漏洞類型同時出現在三款 Agent、兩個應用裡。這幾乎不可能是巧合，背後有結構性的原因。

讓我逐一拆解每個漏洞類型，以及為什麼 AI 會在這裡犯錯。

1. 存取控制失效（Broken Access Control）

AI 犯錯的邏輯：AI 在實作功能時，第一優先是「功能可以運作」。當它在建立一個刪除用戶、修改資料的 API 端點時，它的思維是「這個端點要能執行這個操作」，而不是「這個端點要先確認誰有權限執行這個操作」。

具體情境：在 FaMerAgen（兒童過敏追蹤 app）中，三款 Agent 都建立了可以刪除家庭成員資料的 API 端點，但沒有驗證發出請求的用戶是否有權限執行這個操作。任何人只要知道端點路徑，都可以刪除別人的資料。

為什麼難發現：程式碼本身沒有語法錯誤。功能測試也會通過（因為功能「可以運作」）。只有專門做授權滲透測試才會被發現。

---

2. 業務邏輯漏洞（Business Logic Failures）

AI 犯錯的邏輯：AI 預設相信前端傳來的資料。在遊戲應用 Road Fury 裡，分數、餘額、解鎖狀態都是由前端送到後端儲存的，三款 Agent 都沒有在後端做驗證。

具體情境：這等同於讓玩家可以自己修改分數再上傳。攻擊者只需要用 browser dev tools 改掉 API request 的 payload，就可以偽造任何分數、用 0 元解鎖付費內容。

為什麼這是 AI 思維的盲點：客戶端驗證和伺服器端驗證的重要性，需要對「攻擊者存在」這個前提有意識。AI 在沒有被提示的情況下，不會主動假設「有人會嘗試作弊」。

---

3. OAuth 實作失誤

AI 犯錯的邏輯：OAuth 的實作有很多「可以省略的步驟」，但這些步驟省略了就會開洞。state 參數是其中最常被省略的——它的作用是防止 CSRF 攻擊，但在「讓 Google 登入可以運作」這個目標裡，不加 state 也能通過功能測試。

具體情境：沒有 state 參數的 OAuth 流程，攻擊者可以偽造登入請求，把受害者的帳號連結到攻擊者控制的第三方帳號。這是一種帳號接管攻擊（account takeover）。

額外風險：三款 Agent 的不安全帳號連結邏輯，讓「使用 Google 登入的 A 帳號」有可能被連結到「另一個 email 帳號」，形成帳號合併漏洞。

---

4. WebSocket 沒有身份驗證

AI 犯錯的邏輯：這個漏洞最能說明 AI 的局部正確、整體失效問題。三款 Agent 都正確地為 REST API 實作了認證中間件（JWT 驗證、session 檢查）。但當需要實作 WebSocket 連線時，AI 把 WebSocket 當成一個獨立的系統處理，忘記了把已經寫好的認證邏輯接進去。

具體情境：Road Fury 的多人對戰功能使用 WebSocket。REST API 需要登入，但 WebSocket 連線不需要。攻擊者可以直接建立 WebSocket 連線，用任何用戶 ID 發送訊息，操控遊戲狀態。

深層原因：「REST API 的安全性」和「WebSocket 的安全性」對 AI 來說是兩個獨立的問題，它不會自動把兩者連起來。這需要對整個系統架構有全域視野。

---

5. Rate Limiting 沒有連接

AI 犯錯的邏輯：每個程式庫都定義了 rate limiting 中間件（限制同一 IP 每分鐘的請求次數），但沒有任何一款 Agent 把它掛載到應用程式的路由上。

這是整份研究裡我覺得最精準說明問題的發現：AI 知道要「寫出」rate limiting，但不知道要「啟用」它。

類比：家裡裝了門鎖，但工人忘記把鎖安裝到門上。鎖的材料在工具箱裡，但門沒有鎖。

後果：沒有 rate limiting 的 API，可以被用來做暴力破解登入（brute force）、帳號列舉（user enumeration）、DDoS 攻擊。這些在 OWASP Top 10 裡都是常見的攻擊手法。

---

6. JWT 密鑰管理不當

AI 犯錯的邏輯：JWT（JSON Web Token）需要一個密鑰來簽名和驗證 token。正確的做法是從環境變數讀取這個密鑰。但 AI 在「讓程式可以執行」的前提下，會加入一個 hardcoded 的 fallback 密鑰（例如 "secret" 或 "your-secret-key"），以確保程式在沒有設定環境變數的情況下也能啟動。

具體後果：如果這個 fallback 密鑰被硬編碼在程式碼裡，攻擊者只要看到原始碼（或猜到常見的 fallback 值），就可以用這個密鑰偽造任何用戶的 JWT token，不需要知道帳號密碼就能登入任何帳號。

台灣企業特別要注意：如果你的工程師直接把 AI 產出的程式碼推到 GitHub（特別是公開倉庫），這個 fallback 密鑰就是公開的。這不是假設，這在業界已經有很多真實的資料外洩案例。

---

【獨家】傳統掃描工具為什麼抓不到這些漏洞？

這是整個研究裡對企業影響最大的發現。如果你的工程師現在用的是傳統 SAST（Static Application Security Testing）工具，它對上面六種漏洞的命中率非常低。

原因很簡單：傳統 SAST 用的是 regex 模式比對。它會找「已知的危險函式呼叫」，比如你用了已知有 SQL Injection 風險的 eval() 或直接字串拼接 SQL 查詢，它就報警。

但上面六種漏洞沒有這種語法特徵： – 「rate limiting 已定義但沒有掛到路由」——regex 看不到「連接關係」 – 「WebSocket 沒有套用 REST API 的認證邏輯」——regex 不追蹤程式流 – 「JWT fallback 密鑰」——這個值本身不危險，危險的是它是 hardcoded

DryRun 自己的情境式分析工具（Contextual Analysis）在測試中達到 88% 的漏洞識別率，相比傳統 SAST 工具的差距顯著——特別是在邏輯層級的漏洞上。

對企業的實際意義：如果你的 CI/CD 管線裡跑的是 ESLint security plugin、npm audit 或標準 Bandit，它們確實有用，但對 AI 寫出來的這類漏洞，防護效果很有限。你需要額外的工具，或者更嚴格的人工 code review 流程，專門針對這六種模式。

---

【獨家】台灣企業 AI 開發的安全檢查清單

根據這份研究的發現，以及我在 400 多家台灣企業的培訓經驗，我整理了一份立即可用的檢查清單。不管你的工程師用的是 Claude Code、Cursor、Copilot 還是其他 AI 工具，這份清單都適用。

檢查項目	具體做法	風險等級
WebSocket 認證	確認 WebSocket upgrade handler 有套用與 REST API 相同的 JWT/session 驗證	高
Rate Limiting 掛載	搜尋 rate limiter 定義，確認它有被 app.use() 或路由 middleware 引用	高
JWT 密鑰來源	grep 搜尋 “secret” 字串，確認所有 JWT secret 都來自 process.env，無任何 hardcoded fallback	高
破壞性端點授權	所有 DELETE / PUT / PATCH 端點都要有存取控制，驗證操作者有權限修改目標資源	高
伺服器端資料驗證	分數、餘額、狀態等關鍵欄位必須在後端重新計算，不可直接接受前端傳來的值	中高
OAuth state 參數	所有 OAuth 流程必須包含 state 參數，並在 callback 時驗證	中高
PR 安全審查時機	在每個 PR 合併時掃描，不是只在最終版本掃（風險是累積的）	流程

最重要的一個轉變：不是「AI 寫完，人來修漏洞」，而是「人先設好安全框架，AI 在框架裡開發」。

這個框架可以是： – 在 prompt 裡明確要求「所有端點都要有身份驗證，所有 rate limiter 要掛到路由上」 – 使用 GitHub Copilot 的 security prompt engineering – 在 PRD（產品需求文件）裡加入安全要求，再把 PRD 餵給 AI

安全不是最後一道關，是整個流程的前提。

---

阿峰觀點

我帶過很多工程師從「剛開始用 AI 寫程式」到「用 AI 大幅加速開發節奏」的過程。最常見的進化路徑是：

第一階段：覺得 AI 很神，產出的程式碼能動，就直接用。 第二階段：踩到一個大坑（通常是生產環境的 bug），開始懷疑 AI。 第三階段：知道 AI 的邊界，有選擇地使用。

DryRun 這份研究幫大家跳過了第二階段——你不需要親自踩坑，現在就可以直接知道 AI 最容易出問題的地方在哪。

有一件事我想強調：這份研究不是要證明「AI 不能用來寫程式」。Claude Code 和 Codex 確實能大幅加速開發，這一點沒有疑問。問題是安全審查的機制還沒跟上 AI 的速度。

在 AI 出現之前，工程師寫一個 PR 需要幾個小時。在這段時間裡，安全意識通常會在某個時刻介入（「等一下，這個端點忘記加認證了」）。現在 AI 可以在幾分鐘內生成整個功能，這個自然的「停下來想一想」的時間消失了。

速度帶來了效率，也帶來了新的系統性風險。

知道這個風險在哪，比用不用 AI 更重要。「會用、懂用、好用、每天用」——「懂用」這一塊，包括懂 AI 的局限。

---

本文提到的資源

資源	說明
DryRun Security 原始報告	Help Net Security 報導，含研究方法和完整漏洞分類
DryRun Security	專注 AI 輔助開發安全的研究與工具
OWASP Top 10	Web 應用安全最常見的十大漏洞類型，本研究多個漏洞都在清單內

---

如果你的公司正在導入 AI 開發工具，想同時建立安全的 AI 開發流程，歡迎到 autolab.cloud 聯繫阿峰老師。服務過超過 400 家企業，從製造業到金融業，都有落地的 AI 開發培訓案例。

加入 LINE 社群，跟一萬多名學員一起關注 AI 工具的最新動態：https://lin.ee/mUvPZwJC

---

---

關於作者

黃敬峰（AI峰哥），企業 AI 實戰培訓專家，400+ 企業合作、10,000+ 學員。核心心法：「會用、懂用、好用、每天用」。官網：https://www.autolab.cloud