AI 寫的程式安全嗎？Vibe Coding 常見的資安漏洞
AI 寫的程式不一定安全：能跑，只代表功能做出來了。Veracode 2025 年的報告用 80 個程式任務測試 100 多個 AI 模型，在沒有特別要求資安時，有 45% 的任務寫出帶有已知弱點的程式碼。上線前，金鑰、資料庫權限、輸入驗證與套件都要逐項確認。
畫面做好、功能點得動，下週就要發給客戶。「AI 寫的，應該沒問題吧？」問題是，你要求 AI 的是讓功能動起來；沒開口要的安全，它不一定會顧到。以下用白話說明 Vibe Coding（用自然語言請 AI 寫程式、自己不太看程式碼的開發方式）常見的資安漏洞。
研究怎麼說：AI 寫的程式碼有多常帶漏洞？
資安公司 Veracode 在〈2025 GenAI Code Security Report〉設計 80 個程式填空任務，涵蓋 Java、JavaScript、C#、Python，每題都有安全與不安全兩種寫法，對應 SQL 注入、跨網站指令碼（XSS）、日誌注入與不安全的加密演算法四類弱點。題目交給 100 多個大型語言模型完成，提示不加任何資安要求，再用工具自動檢查原始碼。
結果只有 55% 的任務產出安全的程式碼。SQL 注入與加密兩類的平均通過率在八成以上，XSS 與日誌注入只有一成多；較新、較大的模型，也沒有寫出明顯更安全的程式碼。
研究條件要看清楚：每題只給單一函式，也沒提醒資安；報告也說，加入資安要求後結果可能較好。所以重點不是「你的程式有 45% 是漏洞」，而是：你沒要求，AI 很常選到不安全的寫法。報告認為，這和 AI 學習的公開程式碼本來就混著不安全寫法有關。
人和 AI 一起寫也類似。史丹佛大學團隊在 ACM CCS 2023 發表的使用者研究，請 47 位受試者完成 5 個資安相關的程式任務；可用 AI 助理（當時 OpenAI 的 codex-davinci-002 模型）的一組，有 4 題比較常寫出不安全的解法。以寫入資料庫那題為例，AI 組有 36% 的人寫出可被 SQL 注入的程式，沒有 AI 的對照組是 7%。而且用 AI 的人更傾向相信自己的程式是安全的。
Vibe Coding 常見的 7 個資安漏洞
1. 金鑰寫在前端或程式碼裡
請 AI「串金流」或「接上 OpenAI」時，最省事的做法是把金鑰直接寫進程式。但前端程式碼每個訪客都下載得到，推上公開程式碼倉庫也等於公開。以雲端資料庫 Supabase 為例，官方把金鑰分兩種：publishable key 可公開，只能碰到資料庫規則允許的範圍；secret key 會繞過規則，官方明講不能放進瀏覽器。外洩後怎麼補救，可以看〈程式碼裡的 API 金鑰外洩〉。
2. 資料庫權限沒設好：Supabase 沒開 RLS
Supabase 的 Row Level Security（RLS，列層級安全），是「每一筆資料誰能看、誰能改」的規則。官方文件寫明：對外 API 可存取的資料表若沒開 RLS，只要角色被授予權限，就能讀寫整張表，因此這類資料表每一張都要開。文件也提醒，部分專案新建資料表時，預設就把讀、寫、改、刪權限給了未登入的訪客角色，只加規則不會收回。白話說：網站要登入，資料庫卻可能對所有人開著門。
3. 只在前端擋權限
「看不到管理按鈕」不等於「不能做管理動作」，按鈕藏起來只是畫面。國際資安社群 OWASP 的 2025 年版 Top 10 把「存取控制失效」排第一，並指出存取控制只有放在可信任的伺服器端程式或 serverless API 才有效，因為攻擊者改不到那裡的檢查。
4. 輸入沒有驗證：SQL 注入與 XSS
SQL 注入，是使用者輸入的文字被系統當成資料庫指令執行，資料可能被讀走或竄改；XSS，是使用者輸入的內容沒處理就顯示在網頁上，變成在其他訪客瀏覽器裡執行的程式。前面 Veracode 的實驗中，XSS 正是 AI 表現最差的類別之一。防守方向：資料庫查詢用參數化寫法、顯示使用者內容前先編碼，檢查放在伺服器端。
5. 裝到不存在或過時的套件
套件是別人寫好、可直接安裝的程式模組。USENIX Security 2025 的一篇論文，用 16 個模型以 Python 與 JavaScript 產生 57.6 萬份程式碼樣本，發現模型推薦的套件有 19.7% 根本不存在；商用模型（研究中為 GPT 系列）平均 5.2%，開源模型 21.7%。抽樣重問同一題 10 次，有 43% 的假套件 10 次都再出現。研究者指出，攻擊者可以搶先用這些名字發布惡意套件。研究測的是 GPT-4 等當時的模型，新模型的比例可能不同。
過時套件也是風險：OWASP 把有漏洞、不再維護或過時的元件列為供應鏈風險。
6. 除錯模式與錯誤訊息外露
開發時為了找錯，系統常把詳細錯誤直接顯示在畫面上，上線忘了關，訪客也看得到程式內部資訊。OWASP 把向使用者顯示堆疊追蹤（程式出錯時的內部執行紀錄）或過度詳細的錯誤訊息列為安全設定錯誤，並提醒這可能暴露含已知漏洞的元件版本。
7. 沒有登入嘗試限制
登入頁若能無限次嘗試，等於讓自動化程式一組組猜密碼。OWASP 建議限制登入失敗次數或逐步拉長等待時間，同時避免正常帳號被惡意鎖住，並在可行時加上多因素驗證。
上線前自查清單：這 8 項先問清楚
這張表只看資安；產品面的上線準備，可以參考〈Vibe Coding 做出 App 之後，怎麼走到真正上線？〉。
| 檢查項目 | 怎麼確認 |
|---|---|
| 金鑰 | 前端與程式碼裡沒有 secret key 或密碼；推上 Git 過的金鑰已作廢換新 |
| 資料庫規則 | 對外資料表都已開 RLS；用「未登入」和「另一個帳號」各試一次，看不到別人的資料 |
| 權限檢查 | 管理功能在伺服器端檢查身分 |
| 輸入處理 | 資料庫查詢用參數化寫法；使用者內容顯示前有編碼 |
| 套件 | 每個套件都確認存在、拼字正確、仍有人維護，並掃描已知漏洞 |
| 錯誤訊息 | 除錯模式已關閉；錯誤頁只顯示一般提示 |
| 登入防護 | 登入失敗有次數限制或延遲；管理員開啟多因素驗證 |
| 紀錄 | 登入失敗、權限被拒有紀錄，且有人定期看 |
只要有一項答不出來，就先列為上線前要補的工作。
我用 AI 做的系統要上線了，怎麼確認真的擋得住？
清單能抓出明顯問題，但權限有沒有真的擋住，光看程式碼不一定看得出來，要實際試過才知道。研究也顯示，用 AI 的人容易高估程式的安全性，最好請沒參與開發的人再看一次。
如果系統即將對客戶開放、內部又沒人能做，可以考慮智盾資安服務：檢查程式源碼與金鑰外洩（硬編碼金鑰、外洩憑證、有已知漏洞的相依套件），也檢測網站與對外服務、資料庫曝露與設定；風險會在授權範圍內實際驗證、由人工重現確認，並交付風險分級報告與優先修補建議。檢測反映的是特定時間點的狀態，大改版後值得再確認一次。
資料來源與核對日期
- Veracode，〈2025 GenAI Code Security Report〉，https://www.veracode.com/wp-content/uploads/2025_GenAI_Code_Security_Report_Final.pdf，2026-10-07 核對。
- Neil Perry、Megha Srivastava、Deepak Kumar、Dan Boneh，〈Do Users Write More Insecure Code with AI Assistants?〉（ACM CCS 2023），https://arxiv.org/pdf/2211.03622，2026-10-07 核對。
- Joseph Spracklen 等，〈We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs〉（USENIX Security 2025），https://www.usenix.org/system/files/usenixsecurity25-spracklen.pdf，2026-10-07 核對。
- Supabase，〈Row Level Security〉，https://supabase.com/docs/guides/database/postgres/row-level-security，2026-10-07 核對。
- Supabase，〈API keys〉，https://supabase.com/docs/guides/api/api-keys，2026-10-07 核對。
- OWASP，〈OWASP Top 10:2025〉，https://top10.owasp.org/2025/，2026-10-07 核對。
- OWASP，〈A01:2025 Broken Access Control〉，https://top10.owasp.org/2025/A01_2025-Broken_Access_Control/，2026-10-07 核對。
- OWASP，〈A02:2025 Security Misconfiguration〉，https://top10.owasp.org/2025/A02_2025-Security_Misconfiguration/，2026-10-07 核對。
- OWASP，〈A03:2025 Software Supply Chain Failures〉，https://top10.owasp.org/2025/A03_2025-Software_Supply_Chain_Failures/，2026-10-07 核對。
- OWASP，〈A05:2025 Injection〉，https://top10.owasp.org/2025/A05_2025-Injection/，2026-10-07 核對。
- OWASP，〈A07:2025 Authentication Failures〉，https://top10.owasp.org/2025/A07_2025-Authentication_Failures/，2026-10-07 核對。
- OWASP Cheat Sheet Series，〈Cross Site Scripting Prevention Cheat Sheet〉，https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html，2026-10-07 核對。
作者與關係揭露
本文由奧微軟體開發企業社發布。內容為一般資安知識整理，不構成個別系統的檢測結論；奧微軟體提供與本文主題相關的智盾資安服務。
常見問題
AI 寫的程式安全嗎？
不一定。Veracode 2025 年報告讓 100 多個 AI 模型完成 80 個程式任務，沒要求資安時，有 45% 的任務寫出帶已知弱點的程式碼；能跑不代表安全，上線前要檢查。
Vibe Coding 常見的資安漏洞有哪些？
常見的有金鑰寫在前端或程式碼裡、資料庫權限沒設好（例如 Supabase 沒開 RLS）、只在前端擋權限、輸入沒驗證、裝到不存在或過時的套件、錯誤訊息外露，以及沒有登入嘗試限制。
用 Supabase 一定要開 RLS 嗎？
Supabase 官方文件要求，對外 API 可存取的每張資料表都要開 RLS；沒開時，只要角色被授予權限就能讀寫整張表。會繞過 RLS 的 secret key 不能放進瀏覽器。