多數站主檢查一個網站做得好不好，標準只有一個：打開來會不會跑、畫面對不對、點下去有沒有反應。但資安漏洞不會讓頁面跑不動，它躲在畫面底下，你點幾次都點不出破綻——攻擊者卻能直接繞過登入頁，把資料庫裡別人的訂單、病歷、密碼原封不動撈走。
用 AI（如 ChatGPT、Claude、GitHub Copilot 這類工具）寫程式碼，現在已經是很多網站、後台系統背後真正在動工的方式，尤其新創與中小型網站更常見。這類工具在功能正確上進步得很快，你要的頁面、按鈕、表單，大概都寫得出來，不過 Veracode 一份鎖定 AI 程式碼安全性的測試發現，整體只有 56%的 AI 生成程式碼通過安全測試，代表另外 44%都藏著至少一個資安瑕疵。你不需要懂程式，也能知道該問對方什麼問題、自己怎麼動手驗。
先從這個落差有多大、背後又是什麼原因造成的說起。
AI 生成程式碼的資安風險是什麼？
Veracode 一份 2026 年 7 月發布的測試，把重點放在 AI 寫出來的程式碼安不安全這件事上。研究團隊找來超過 100 個大型語言模型，讓它們各自完成 80 項程式撰寫任務，程式語言涵蓋 Java、Python、C#、JavaScript 四種，再針對 SQL Injection、跨站腳本、日誌注入、加密實作失效四類漏洞逐一檢測。結果顯示，整體只有 56%的 AI 生成程式碼通過安全測試，代表另外 44%（幾乎每兩份程式碼就有一份）含有可被利用的安全瑕疵。拆開四類漏洞看，差距更大：SQL Injection 的安全通過率有 83%、加密實作失效有 87%，但跨站腳本只有 15%通過（即 85%失敗）、日誌注入只有 12%通過（即 88%失敗）。也就是說，AI 在防止資料庫被入侵這件事上表現還算過得去，一碰到判斷哪些輸出內容需要過濾就幾乎全軍覆沒。
這個現象不是時間到了自然會改善。Veracode 在 2026 年 3 月發布的更新報告更直接指出，儘管廠商聲稱有改善，AI 模型的資安表現依然停滯，整體通過率仍卡在約 55%左右，而且較大的模型並沒有在資安表現上贏過較小的模型，模型規模跟資安能力是兩條沒有交集的曲線。同一系列 Veracode 測試按語言細分後顯示，Java 的失敗率高達 72%，是四種語言裡表現最差的一種；Cloud Security Alliance 在 2026 年 4 月發布的研究報告〈Vibe Coding’s Security Debt: The AI-Generated CVE Surge〉也引用了這個數字，作為佐證。
為什麼 AI 寫功能可以寫得又快又準，一碰到資安表現就差這麼多？背後有三個結構性原因。第一、訓練資料本身就混雜大量不安全的寫法。網路上流傳的程式碼範例有安全的也有不安全的，AI 把兩種都學成有效解法，沒有能力分辨哪種才該用在正式環境。第二、AI 生成程式碼時，通常只看得到眼前這一小段任務，不理解整個應用系統的商業邏輯與安全需求，自然也就不會去補那些情境要求才會浮現的防護。第三、要判斷一個變數是不是使用者可以自由輸入的內容，需要跨越好幾個函式去追蹤資料怎麼流動，這種跨函式的資料流分析超出目前模型的語意理解能力，也是跨站腳本與日誌注入失敗率特別高的核心原因。
企業端的實測數據更能說明問題規模已經多大。Cloud Security Alliance 引述 Apiiro 對 Fortune 50 企業自 2024 年 12 月至 2025 年 6 月的深度程式碼分析發現，用 AI 輔助開發的工程師，程式碼提交速度是同儕的 3 到 4 倍，但資安團隊發現的問題數量卻以 10 倍速度往上衝，從每月約 1,000 件暴增到逾 10,000 件。細看問題類型會更清楚看出落差在哪裡：語法錯誤降了 76%、邏輯錯誤降了 60%（這正是 AI 最擅長的功能正確性），但架構層級的漏洞不減反增，權限提升路徑增加 322%，架構設計缺陷增加 153%。這一類漏洞恰好就是需要理解整個系統情境、單看一段程式碼看不出來的類型，也是最容易在正式環境釀成實際損害的一種。
對非技術背景的站主來說，問題出在判準本身就用錯了地方。你能自己驗收的，大概就是打開網站會不會跑、按鈕有沒有反應，這正是 AI 表現最好、最不容易出錯的那一環。至於程式碼有沒有留資料庫漏洞、有沒有把金鑰寫死在裡面，光憑肉眼看畫面完全看不出來。這也是為什麼接下來這幾種常見漏洞，都需要一份具體的檢查清單去要求對方，而不是憑感覺覺得東西做出來了、能動，應該就沒問題。
先求功能跑得動，權限就跟著放寬
開發階段最常見的優先順序，是先讓功能跑起來，權限之後再收緊。這個順序聽起來合理，實際上「之後」常常沒有發生，上線前沒人回頭把權限改回嚴謹的設定，一路放寬的存取規則就這樣留在正式環境裡。AI 生成程式碼特別容易踩進這個陷阱，因為它的預設目標就是讓眼前這段程式跑得動、資料抓得到，而不是先判斷這筆資料該不該讓這個使用者看到。
一個已經被記錄在美國國家漏洞資料庫（NVD）裡的真實案例可以說明這件事有多具體。AI 輔助開發平台 Lovable 在 2025 年 4 月 15 日之前的版本存在一個編號 CVE-2025-48757 的漏洞，CVSS 嚴重度評為 9.3 分，屬於最高等級的 Critical，問題出在資料列層級安全性（Row-Level Security）的驗證被繞過。這套機制原本是用來限制同一張資料表裡誰能看到哪些資料列，一旦繞過，理論上不該被看到的其他使用者資料就會直接曝光。
這不是單一產品的個案。Cloud Security Alliance 引述 Escape.tech 對 1,400 款以 AI 輔助開發平台（含 Lovable、Base44、Bolt.new、Vibe Studio 等）打造、且當時已經在正式環境服務真實使用者的應用程式進行掃描，結果掃出 2,038 個高風險漏洞、400 多組外洩的金鑰與憑證，還有 175 起個人資料外洩案例，當中包含病歷、財務資料、驗證憑證這類最敏感的資訊。這些應用程式掃描當下都已經上線，不是還在測試環境的半成品。
如果你的網站背後有資料庫或後端服務是靠 AI 輔助寫出來的，有一件事值得直接問對方，那就是資料的存取權限是怎麼設定的，是不是每個使用者只看得到自己的資料。更具體一點，可以請對方在上線前做一次測試，在完全沒有登入的狀態下試著直接呼叫網站的資料查詢功能，看看能不能讀到本來該屬於別人的資料。這個測試不需要寫程式，對方應該能在幾分鐘內示範結果給你看。
為了不擋使用者，輸入驗證就被拿掉
輸入驗證指的是，使用者在表單、網址參數這些地方打進去的內容，程式在使用之前要先檢查、過濾，確認裡面沒有夾帶惡意指令。這一關偏偏是 AI 生成程式碼最容易跳過的地方，原因不難理解。AI 在生成程式碼時傾向找一條最短路徑讓功能先動起來，把使用者輸入的內容直接拼進資料庫查詢或輸出到頁面上，是最快讓程式碼看起來正確的寫法，卻也是最不安全的寫法。
這不是憑印象下的判斷，學術研究早就量化過規模。Pearce 等人在 IEEE Symposium on Security and Privacy 2022 發表的研究〈Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions〉，讓 GitHub Copilot 針對 MITRE「CWE Top 25」高風險弱點清單相關的情境生成程式碼，總共分析了 1,689 個生成出來的程式，結果約 40%含有可被利用的漏洞，拆語言看，C 語言的漏洞率約 50%，Python 約 39%。這是最早、也是被廣泛引用的 AI 程式碼安全性學術評估之一，證明 AI 容易漏掉輸入驗證不是單一工具或單一情境的問題。
前面提到的 Veracode 測試把注入類漏洞拆得更細。同一批測試中，AI 生成程式碼對 SQL Injection（CWE-89）的安全通過率是 83%，代表仍有 17%的情況會產生可被注入攻擊的寫法；跨站腳本（CWE-80）的失敗率則高達 85%。Veracode 指出主因是，判斷哪些變數需要做資料清洗需要超出單一程式片段的應用情境，而這正是 AI 目前做不到的部分，它看得到眼前這幾行程式碼，看不到這個變數之後會被送去資料庫還是顯示在頁面上，自然也就不知道該用哪一種方式過濾。日誌注入（CWE-117）的失敗率是 88%，同樣是資料清洗判斷不足所致。
你可以直接問對方一件事，表單、網址參數這類使用者可以自己輸入內容的地方，是不是都在伺服器端做過資料驗證與過濾，而不是只在前端擋一層。前端的檢查很容易被繞過，真正該守住的是伺服器端這一關。
後台功能的伺服器端授權檢查
不少後台功能的保護，其實只做到把畫面上的按鈕藏起來，一般會員登入後看不到管理選項，乍看沒有破綻，但只要知道對應的網址或 API 路徑直接打進去，系統若沒有在伺服器端重新確認這個使用者的權限，操作照樣會成功。前端藏起來只是不讓你看到入口，伺服器端檢查才是真正擋住操作本身。差別在於前者只防看得懂畫面的一般使用者，後者才防得住直接對系統發指令的人。
這類權限控管缺陷不是冷門風險。OWASP（開放網路應用程式安全計畫）在 Top 10:2021 官方文件中，把「Broken Access Control」列為當年排名第一的風險類型，官方報告指出受測應用程式裡有 94%被檢測出某種形式的權限控管缺陷，是十大風險裡出現比例最高的一類。換句話說，這不是罕見的邊緣情況，而是十個網站裡有九個以上都中過的通病。
Wiz 研究團隊在 2025 年 7 月揭露的 Base44 案例是一個具體示範。研究人員發現，Base44 平台的 Swagger UI（API 說明介面）因設定疏失而公開可被存取，攻擊者只要取得一個並不具保密性、直接寫在網址與 manifest.json 檔案路徑裡的 app_id 參數，就能繞過原本的驗證機制，存取其他使用者的私有應用程式。這代表一個低階攻擊者不需要任何進階技巧，光靠讀取一個公開路徑裡的參數就能闖進別人的系統。所幸 Wiz 通報後不到一天，Base44 即強化了隱私設定的驗證機制，官方也確認沒有客戶資料因此受影響，但修復速度快不代表這類設計疏失發生的機率低。
不需要懂程式，你自己就能做一個簡單驗證，換一個一般會員的帳號登入，試著透過修改網址或參數（例如把網址裡的使用者編號換成別的數字），看看能不能因此看到別人的資料或本該只有管理員才能用的後台功能。如果換個數字就打得開，代表伺服器端根本沒有真的檢查權限，只是把入口藏起來而已。
金鑰與密碼常被直接寫進程式碼
金鑰與密碼一旦被寫死在程式碼裡，傷害幅度跟其他漏洞不太一樣。它不需要攻擊者花時間找漏洞、繞過防護，只要拿到那組金鑰，就等於拿到直接開門的鑰匙，前面所有的權限設計、輸入驗證都會被一次繞過。更麻煩的是，程式碼只要曾經被推上公開的版本控制平台，即使後來又刪掉，掃描外洩憑證的工具幾乎都會在短時間內找到它，不會因為事後刪除就變安全。
GitGuardian《The State of Secrets Sprawl 2025》報告統計，2024 年公開 GitHub 上被偵測到的外洩密鑰達 2,380 萬組，比前一年成長 25%；其中通用型密鑰占外洩總量的 58%，而且 2022 年外洩的密鑰裡有 70%至今仍然有效、未被撤銷，代表多數團隊發現金鑰外洩之後並沒有真的去換掉它。報告還提到，啟用 GitHub Copilot 的儲存庫，密鑰外洩率比基準組高出 40%（6.4%對 4.6%）。香港中文大學團隊發表的學術研究〈Your Code Secret Belongs to Me: Neural Code Completion Tools Can Memorize Hard-Coded Credentials〉則進一步測試發現，研究人員向 GitHub Copilot 發出 900 次提示，總共取得 8,127 則程式碼建議，其中 2,702 則通過篩選、疑似含有效密鑰（平均每次提示約產生 3 組疑似密鑰），但逐一驗證後，真正確認仍然可用的密鑰只有 2 組——多數看起來像金鑰的建議，實際上並不是真的能用的憑證。
最新一份《The State of Secrets Sprawl 2026》報告（涵蓋 2025 年資料）顯示這個趨勢還在加速，由 Claude Code 共同撰寫的程式碼提交，在公開 GitHub 上的密鑰外洩率約是基準值的兩倍；與 AI 服務相關的密鑰外洩案例較前一年成長 81%，達到 127 萬 5,105 組。也就是說，AI 輔助開發工具用得越普及，金鑰外洩的規模跟著同步放大，不是暫時的過渡現象。
你不需要懂程式，也能請對方直接示範。先問清楚金鑰與密碼是怎麼存放的，正確做法是用環境變數或密鑰管理服務，而不是寫死在程式碼或版本紀錄裡；接著可以直接要求對方示範一次，在原始碼裡搜尋不到任何一組金鑰或密碼。只要對方能打開程式碼、示範搜尋不到任何明文金鑰，基本上就守住了這一關。
AI 建議的套件不一定真的存在
AI 在寫程式時，常常需要引用外部的套件庫（別人寫好、可以直接拿來用的程式碼模組）來完成某個功能，資料處理、串接金流、寄送郵件幾乎都靠套件庫節省重工。問題是 AI 有時候會很有把握地叫你去安裝一個根本不存在的套件，名稱編得跟真的一樣，聽起來也很合理，實際上套件庫裡根本查不到這個東西，這種現象叫做幻覺套件（package hallucination）。
這不是偶發個案。Spracklen 等人在德州大學聖安東尼奧分校主導、發表於 USENIX Security Symposium 2025 的研究〈We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs〉，分析了 16 個大型語言模型產生的 576,000 個程式碼樣本，發現約 19.7%，接近兩成引用了實際上不存在的 Python 或 JavaScript 套件。更關鍵的是後續發現，這些幻覺出來的套件名稱裡有 43%會在相似的提示下被穩定重複產生，58%會在同一個查詢重跑 10 次內至少再出現一次。也就是說，這些幻覺名稱不是隨機亂編、每次都不一樣，而是可預測、可以被提前鎖定的。
這個特性正好給了攻擊者一個新的可乘之機。Python Software Foundation（Python 官方基金會）的資安人員 Seth Michael Larson 把這種攻擊手法命名為 slopsquatting，也就是幻覺套件搶注，作法是攻擊者事先分析 AI 最常幻覺出來的套件名稱，搶先把這些名稱註冊成真實存在、內含惡意程式的套件，等開發者或 AI 代理工具依照建議去安裝時，裝進來的就是惡意版本。這個術語由國際官方開源基金會正式命名並公開討論，代表這已經是業界正式承認、不是危言聳聽的新型供應鏈攻擊類別。
你可以請對方針對程式碼引用的每一個外部套件，實際到套件庫搜尋確認這個套件名稱是不是真的存在、有沒有人持續維護，而不是下載次數異常低、說明頁近乎空白的可疑套件。這個檢查不需要懂程式邏輯，單純確認這個名字查得到、查得到的東西看起來正常就足夠。
測試帳號留著方便除錯，卻沒人記得關掉
開發過程中為了方便測試，留一組預設帳密、開一個除錯用的路徑，是很常見的做法，問題出在上線前這些東西常常沒人記得清掉。這種疏漏跟前面幾種漏洞不太一樣，它不是程式邏輯寫錯，單純是收尾沒收乾淨，卻一樣能被攻擊者直接拿來當作入口。
OWASP 把這類問題歸在「Security Misconfiguration」（安全設定缺陷）這個類別下，定義涵蓋幾種具體情境：未變更的預設帳號與密碼、開啟除錯模式導致敏感系統資訊外洩給一般使用者、以及不必要的功能（連接埠、服務、頁面、帳號、權限）仍處於啟用狀態。這是 OWASP 官方十大風險分類之一，不是邊緣冷門的項目。MITRE CWE 弱點分類裡也有一個專門對應的編號，CWE-489「Active Debug Code」，定義應用程式在正式環境中仍留有除錯用的功能或程式碼屬於已知且被正式收錄的弱點類別，攻擊者可以利用這類殘留功能繞過原本設計的存取限制。這代表這不是某個開發者個人的疏忽，而是一個有正式名稱、業界普遍承認的已知問題。
AI 生成的基礎建設程式碼（IaC，用程式碼描述伺服器、雲端資源該怎麼設定）特別容易繼承這類不安全的預設值。Cycode 資安部落格的分析指出，這類程式碼會直接繼承訓練資料裡的不安全預設，包括公開儲存空間、過寬的雲端權限規則、關閉的日誌紀錄、以 root 身分執行的容器；只要提示語要求的是讓它動起來，AI 就會往先求能跑的方向生成，這些設定往往跟著功能一起被部署上線，而且通常比應用程式邏輯本身受到更少的檢查與注意。
你可以請對方列出所有非一般使用者也能登入或呼叫的帳號與路徑，確認上線前已經清除或改過密碼。自己也能動手做一個簡單測試，用瀏覽器試打幾個常見的管理或除錯路徑，確認打不開、也不會意外洩漏系統資訊。
沒有人真正讀過整份程式碼
前面幾種漏洞各自成因不同，但底下其實藏著同一個問題，那就是程式碼寫出來之後有沒有人真的看過。不管是開發者對 AI 輸出的信任是不是過了頭，還是 AI 自己內建的審查功能本身可不可靠，答案都指向同一個方向。跑得動，從來不等於有人查過。
Perry 等人在 ACM CCS 2023 發表的控制實驗〈Do Users Write More Insecure Code with AI Assistants?〉，找來實際受試的開發者分兩組，使用 AI 助手（以 OpenAI Codex 為基礎）協助撰寫程式碼的一組，以及完全不使用 AI 輔助的另一組，結果使用 AI 輔助的開發者不只寫出更多安全漏洞（尤其是字串加密與 SQL Injection 這兩類任務特別明顯），還更相信自己交出的程式碼是安全的——開發者對程式碼安全性的信心程度，跟程式碼實際安不安全兩者根本對不上。這個現象被稱為信任悖論，AI 輔助帶來一種虛假的安全感，讓開發者原本應該會做的仔細檢查反而被壓下去了。
業界調查也印證了同樣的落差。Snyk 的資安研究發現，將近 80%的開發者相信 AI 工具生成的程式碼比人類撰寫的更安全，這個普遍認知恰好跟前述多項實證研究的結果相反。更值得留意的是，連 AI 工具本身內建的自我審查功能都靠不住，Amro 與 Alalfi 在 2025 年發表的研究〈GitHub’s Copilot Code Review: Can AI Spot Security Flaws Before You Commit?〉發現，GitHub Copilot 內建的程式碼審查功能經常無法偵測出 SQL Injection、跨站腳本、不安全的反序列化這類關鍵漏洞，反而只標記出低嚴重度的風格與格式問題。這代表就算對方回答有用 AI 工具檢查過，也不能當作已經查出要緊漏洞的保證。
開發者社群自己其實也不是完全沒有警覺。Stack Overflow 2025 年的開發者調查發現，84%的開發者正在使用或計畫使用 AI 工具，同時有 46%的開發者主動表示不信任 AI 輸出的準確性，多數團隊選擇在這種矛盾心態下仍然出貨，而不是先解決這個信任落差再上線。
面對這件事，你能問的問題很直接，誰、用什麼方式複查過 AI 寫出來的程式碼，尤其是牽涉金流、會員帳號、個人資料的功能。答案不能只是跑得動就直接上，也不能只是有讓 AI 工具檢查過，你要的是一個明確的人、明確的複查動作。
資安要求要寫進合約與驗收條件
口頭問過對方一次，不代表這些檢查真的會被落實。真正能落實的做法，是把這些要求寫進合約或驗收條件裡：什麼時候要做、誰負責做、做完要拿出什麼證明，都寫清楚，而不是停留在一句你要注意資安喔。
好消息是，這件事現在的技術門檻並不高。掃描外洩密鑰、掃描相依套件有沒有已知漏洞、靜態程式碼分析（不用真的執行程式，直接檢查原始碼有沒有常見的危險寫法）這類自動化檢查工具已經很普及，多半有免費或低成本的方案可用。換句話說，有沒有做是流程有沒有被要求的問題，不是技術上做不做得到的問題。
如果碰到自己判斷不了的地方，也有管道可以找人幫忙複查。數位發展部數位產業署提供「資安檢測診斷服務」，由政府單位主辦、委託中華民國資訊軟體服務商業同業公會協助執行，涵蓋企業資安評級、主機系統弱點掃描、目錄伺服器組態檢視、網路封包側錄分析、惡意程式檢視、防火牆設定檢視六項檢測，對標美國 NIST 網路安全框架；申請對象須為依台灣公司法設立的本國公司，檢測範圍為 21 至 100 個 IP，企業自付新台幣 3 萬 5 千元。另外，TWCERT/CC（台灣電腦網路危機處理暨協調中心，現由國家資通安全研究院運作）也發布了「中小企業基本資安防護指引」，是專門寫給非大型企業參考的官方文件，可以拿來對照自己網站目前做到哪一步。
至少對牽涉金流、會員帳號、個人資料的功能，建議找懂資安的人做最後一次複查。這些功能一旦出事，影響的不只是網站好不好用，還有使用者的錢跟個資，值得花這筆複查的成本。
AI 讓有一個能用的網站變得比以前快很多，這件事不會逆轉，也沒有必要逆轉。真正該調整的是驗收的心態，與其在畫面上點一點確認沒有壞掉，不如把資安檢查當成跟功能有沒有做完同等重要的一道關卡，寫進交付條件裡逐項確認。你不需要懂程式碼，只需要知道該問對方什麼問題、該找誰複查。等到這些檢查變成流程裡理所當然的一步，而不是想起來才臨時追加的動作，你的網站才真正經得起打開瀏覽器之外的檢驗。