Vibe Coding 安全性：如何保護 AI 打造的應用程式

更多 Ailoot 使用說明請參閱文件。

為什麼 AI 打造的應用程式比較容易遭到駭客入侵？#

我自己也用 AI 打造產品，但不會因為安全問題而疑神疑鬼到「把所有東西都鎖到最嚴」。不過，有一個基本標準絕對不能低於，否則有一天你醒來時，資料庫可能已經空了，伺服器上還跑著別人的挖礦程式。本指南談的就是這個基本標準。不是要你「成為安全專家」，而是「別無緣無故搬石頭砸自己的腳」。

問題的根源很簡單。當你告訴 AI 代理程式「幫我打造一個客戶預約應用程式」，它會盡快讓應用程式運作。安全性是示範時看不見的額外工作。因此，資料庫會設成開放狀態，付款金鑰會直接放進程式碼，而「這位使用者是否有權限？」的檢查只存在瀏覽器中，一秒鐘就能繞過。

第二個原因是平台本身。

換句話說，漏洞會預設自動出現。你沒有做錯任何事，只是什麼也沒做——而在安全領域，不採取行動正是「對所有人開放」的意思。

還有第三層問題。AI 比人更容易洩漏機密。原因很明顯：代理程式不看內容就執行 git add . 和 git push，於是含有金鑰的 .env 檔案也跟著其他內容一起公開。

Vibe Coding 開發者已經從哪些慘痛教訓中學到經驗？#

防止粗心犯錯的最佳疫苗，就是從別人的錯誤中學習。以下有四篇報告，值得你在發布專案前讀一讀。

Lovable 與關閉的 RLS。 Lovable 平台會根據文字描述建置應用程式。2025 年，研究人員在其應用程式中發現系統性漏洞，並指定編號 CVE-2025-48757。原因是生成的應用程式沒有資料庫資料列層級存取規則（RLS，稍後說明）。研究人員抽查一批應用程式，在 170 個應用程式中發現 303 個曝露的存取點。姓名、電話號碼、付款狀態、他人的 API 金鑰，甚至住家地址都曝光了。在受檢查的應用程式中，約有 70 percent 完全關閉了資料列層級保護。

Tea 與敏感資料。 Tea 應用程式（讓使用者匿名評論他人的平台）在 2025 年 7 月遺失了約 72,000 張圖片，其中包括 13,000 張自拍照和證件照片，之後又洩漏超過一百萬則私人訊息。技術原因是儲存空間開放，以及存取檢查薄弱。安全社群常把 Tea 當作鮮明的例子：當快速推出產品比檢查權限更重要時，敏感資料就會最先外洩。

另一個實例。 在原作者描述的一起事件中，某位 Vibe Coding 開發者的應用程式遭到駭客入侵，因為 AI 在建立資料庫時設定了預設密碼，而且可以被自動猜中。接著就是熟悉的過程：入侵者進入系統、安裝挖礦程式，並改寫專案。伺服器最後必須徹底清除。預設密碼就像一扇沒上鎖的門，還掛著「歡迎進來」的牌子。

安全性的兩條戰線：你究竟在哪裡容易受攻擊？#

人們談到「Vibe Coding 安全性」時，通常會把兩種完全不同的擔憂混在一起。我們把它們分開，因為防護方式並不相同。

第一條戰線——代理程式本身。 你在自己的電腦上執行 AI 代理程式，並讓它存取檔案、終端機、金鑰和資料庫。風險在於代理程式不是人：它會照字面遵循指示，並找出最短的路徑，即使那條路徑很危險也一樣。這也包括其他人的指令透過代理程式讀取的文字「注入」代理程式的風險（這稱為 prompt injection）。

第二條戰線——完成後的應用程式。 這是你發布出去、讓大家使用的產品。攻擊目標是已發布的網站或服務：攻擊者闖入開放的資料庫、傳送偽造請求，或猜測他人的帳戶。這和代理程式無關——漏洞是更早之前留下的，其他人會利用它。

Claude 背後的公司 Anthropic 這樣說明主要的防護原則，而這個原則適用於兩條戰線：

實際上，這表示不要指望 AI「自己避免做壞事」。先限制它實際能做的事，再要求它遵守規範。當它的行為失常時——而這一定會發生——只有你預先設下的硬性界線能保護你。

希望 AI 工作時表現可預期，不要每個新專案都讓你搬石頭砸自己的腳嗎？安全規則是 Second Brain 的一部分：把它們寫進 CLAUDE.md 一次，代理程式就會在每次請求中遵循。

AI 代理程式取得電腦存取權後能做什麼？#

最容易被低估的風險，是你自己的代理程式權限過於寬鬆。你甚至不需要外部駭客。你應限制代理程式的權限，避免授予任務不需要的管理員權限。

這裡沒有惡意意圖。只是當代理程式被要求「解決任務」時，它比人更快找到結構性弱點。如果這個弱點能讓它存取你的金鑰或正式環境，它就會利用這個權限。所以第一條規則是最小權限。只給代理程式完成特定任務所需的存取權，一點也不要多給。

這並不是我憑空想像。約翰霍普金斯大學的研究人員攻擊了 Anthropic、Google 和 Microsoft 的正式環境代理程式。他們的結論很直接：

即使你不是程式設計師，實際上可以怎麼做？

1. 不要在正式環境的機器上以「允許所有操作」模式執行代理程式

   代理程式不會要求確認的模式（通常稱為 bypass 或 yolo）只適用於沙箱或測試專案，不能用在存有有效金鑰和正式環境存取權的機器上。

2. 禁止代理程式讀取機密

   在 Claude Code 中，你可以設定規則，拒絕存取含有金鑰的檔案。如此一來，即使代理程式想開啟 .env，工具也不會允許。

3. 將正式環境金鑰分開存放

   正式環境資料庫和付款服務的金鑰，不應放在代理程式寫程式碼的同一個資料夾中。將環境分開：實驗時使用測試金鑰。

4. 使用工具的沙箱

   新型 AI 工具可以在隔離的沙箱中執行命令，無法存取系統的其他部分。在 Claude Code 中，這能將權限請求減少約 84 percent，因此使用起來也更方便。

Claude Code 中拒絕讀取機密的規則大致如下——將它放在權限設定中：

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(**/.env)",
      "Bash(git push *)"
    ]
  }
}

絕對不能把 API 金鑰和密碼放在哪裡？#

最便宜也最常見的錯誤，就是把金鑰放進程式碼。付款服務的 API 金鑰、資料庫密碼、機器人權杖，這些全都是機密。它們應該放在獨立的 .env 檔案中，而且必須列在 .gitignore 裡，才不會跟著程式碼一起進入 git。

開發者經常分享這類故事，帳單金額高達數萬美元。

2025 年問題的規模：公開儲存庫中新增了 28.65 million 個硬編碼機密，年增 34 percent。AI 服務金鑰的外洩量上升 81 percent。Vibe Coding 讓情況雪上加霜，因為代理程式會不看內容就提交。

現在就手動檢查以下項目：

1. 開啟專案的 .gitignore 檔案

   確認裡面有 .env 這一行。如果沒有，請在第一次提交前加入。

2. 前往你的 GitHub 儲存庫

   確認裡面沒有 .env 檔案。搜尋儲存庫中的 .env 或部分金鑰字串，是快速檢查的方法。

3. 如果金鑰已外洩，請撤銷並重新發行

   光是刪除提交並不夠：金鑰可能已經被取得。前往服務供應商（付款服務、雲端服務、AI 供應商），撤銷舊金鑰並發行新金鑰。這稱為金鑰輪替。

4. 只給金鑰最低限度的權限

   如果金鑰只用來讀取資料，就將它設為唯讀。如此一來，就算外洩，也能減少遭竊的資料。

沒有 RLS 時，為什麼所有人都能看到你的資料庫？#

如果你使用 Supabase 或類似資料庫來打造應用程式，這是最重要的段落。RLS 是 Row Level Security 的縮寫。簡單來說，它是一條規則，決定特定使用者能看到資料表中的哪些資料列。沒有這項規則，「orders」資料表就會把所有客戶的訂單都傳給每個人。

Supabase 官方文件對此有個簡潔明確的說法：

這是 Vibe Coding 開發者最容易遇到的陷阱。透過點選 Supabase 控制台建立資料表時，保護功能會自動開啟。但如果是 AI 建立資料表——它幾乎總是直接撰寫 SQL 命令——RLS 就會預設保持關閉。這代表代理程式產生的資料表幾乎肯定對整個網際網路開放。那 170 個 Lovable 應用程式的資料外洩，原因正是如此。

該怎麼做：

1. 直接詢問代理程式

   輸入：「顯示所有已關閉 RLS 的資料表。」AI 會產生清單——那就是你的待辦事項。

2. 為每個含有使用者資料的資料表啟用 RLS

   並至少新增一項存取政策，例如「使用者只能查看自己的資料列」。

3. 檢查控制台

   在 Supabase 控制台中，每個資料表都應顯示「RLS enabled」。如果是灰色或紅色，表示該資料表處於開放狀態。

4. 實際測試

   以一般使用者身分登入，並嘗試請求他人的資料。如果存取被拒，表示政策正在運作。

為什麼介面中的權限檢查無法保護你？#

常見的錯誤想法是：「我已經讓一般使用者看不到管理員按鈕。」問題在於，按鈕只不過是瀏覽器中的一張圖片。使用者可以不透過按鈕，直接向伺服器傳送請求。如果伺服器沒有再次檢查權限，就會執行別人的命令。

一種典型漏洞稱為 IDOR。假設你在網址 id=123 開啟自己的訂單。把它改成 id=124，你就能看到別人的訂單，因為伺服器沒有檢查那是否真的是你的訂單。這是 Vibe Coding 應用程式最常見的漏洞之一，而薄弱的權限檢查正是 Tea 資料外洩的原因。

規則很簡單：每個「這位使用者是否有權執行這項操作？」的檢查，都必須在伺服器上重複進行。介面是為了方便，保護則必須在後端完成。可以直接交給代理程式的指示是：「為每個讀取或變更使用者資料的端點新增伺服器端權限檢查；不要依賴介面中隱藏元素的做法。」

不是程式設計師的話，要如何檢查程式碼中的漏洞？#

好消息是：現在你可以請同一個 AI 檢查安全性，而且它很能找出常見漏洞。以下是三種用途各異的工具。

1. Claude Code 中的 /security-review 命令。 一次性檢查目前分支的 SQL injection、XSS、授權漏洞、資料外洩和相依性問題。我在另一篇Claude Code 安全性審查指南中，逐步說明了它的運作方式，以及如何為每次變更加入自動檢查。這裡的重點是：它是第一道防線，只要執行一個命令就能啟動。

2. 官方 security-guidance 外掛程式。 從官方外掛程式市集使用 /plugin install security-guidance@claude-plugins-official 安裝（需要 Claude Code 2.1.144 或更新版本）。它會在三個時間點檢查程式碼：每次編輯時、每回合結束時，以及提交時。它會偵測授權繞過、IDOR、注入和弱加密。不過，Anthropic 坦率說明了它的限制：

npx skills add <author>/<repo>

接著只要告訴代理程式：「檢查我的專案是否有漏洞。」不過，這個技能集有一項重要但書，所以下文會為它安排獨立段落說明。

補充背景：大型業者也開始認真看待 AI 程式碼安全性。Project Glasswing 在 2026 年 6 月 2 日擴大至 150 個組織。合作夥伴利用 Anthropic 模型，在短時間內找到超過 10,000 個重大漏洞。風險顯而易見：

可以信任來自 GitHub 的技能和擴充功能嗎？#

事情在這裡變得特別棘手，因為危險可能來自你為了安全而安裝的工具。執行 npx skills add ... 或安裝擴充功能時，你會把別人的程式碼載入系統，然後代理程式會以你的權限執行它。如果作者遭到駭客入侵，或套件從一開始就有惡意，就會出問題。

以上一節介紹的技能集為例。它的名稱中包含「Anthropic」，讓人放下戒心。但它自己的說明清楚寫著：

換句話說，這個名稱會造成誤解。這個技能集目前已相當成熟，也沒有問題，但原則不變：安裝風險由你自行承擔。而且這不是假設性的威脅。2026 年 5 月，一個惡意編輯器擴充功能只在市集上架了 18 分鐘，就在這段時間內竊取了安裝者的密碼管理器密碼、GitHub 權杖、雲端存取權，甚至 Claude Code 設定。另一個棘手之處是：這類惡意軟體往往不會在一般移除套件後消失，並會在下一個工作階段再次執行。

我養成了一個簡單的習慣，也建議你這麼做：從 GitHub 安裝任何技能前，先自行檢查。作者可能遭到駭客入侵、帳戶可能被劫持，惡意軟體也可能混進儲存庫。檢查就是你的防護措施。

安裝前最低限度要做的事：查看作者和星數、閱讀技能說明、不要只因為某篇文章推薦就安裝工具；如果工具不熟悉，先在獨立的測試環境中試用，不要在存有正式環境金鑰的機器上測試。

資料外洩後能幫你恢復的工具：備份和復原#

安全性不只是「把外人擋在門外」，也包括「出問題時恢復正常」。因為事情一定會出錯。在一個實際案例中，AI 代理程式處理例行任務時，刪除了正式專案中線上運作的資料庫。雖然有備份，但那是三天前的版本——三天的資料就這樣消失了。

因此有兩項規則。

經常備份。 如果你的應用程式存有你不願失去的資料，每三天複製一次只是讓人以為受到保護。請設定至少每 30 分鐘自動備份一次。對大多數資料庫而言，包括 Supabase，只要點幾下就能啟用。

git 是防範代理程式的保險。 git 會儲存程式碼歷史記錄，讓你還原到任何可運作的狀態。代理程式改寫原本能運作的內容時，你可以回復到最後一個可運作的版本，而不是手動修復。如果 AI 刪除或破壞專案，而你不知道如何復原，請參閱另一篇說明：AI 刪除資料庫時該怎麼辦。要預先防止專案遭到破壞，請參閱如何防止 Claude Code 造成破壞指南。

發布前的安全檢查清單#

在發布前，依序檢查以下清單。

1. 機密放在 .env 中，並將 .env 列入 .gitignore。 程式碼中不能有金鑰。公開儲存庫中不能有 .env 檔案。

2. 金鑰只具備最低限度的權限。 每把金鑰只能執行必要操作。正式環境金鑰與代理程式的環境分開存放。

3. 所有含有使用者資料的資料表都已啟用 RLS，並設有存取政策。

4. 對每項資料操作都進行伺服器端權限檢查。只在介面中隱藏按鈕並不足夠。手動測試網址中的 id 是否能被更改。

5. 驗證 Webhook 簽章。 每個處理外部通知的處理常式（付款、表單）都會驗證簽章。

6. 對收到的請求和高成本操作設定速率限制，避免密碼遭到暴力破解，也避免帳單暴增。

7. 存有正式環境金鑰的機器上，代理程式不會以「允許所有操作」模式執行。拒絕讀取 .env。

8. 經常備份並實際測試——你真的試過還原，而不是只相信備份「放在某個地方」。

9. 使用 /security-review 或 security-guidance 外掛程式檢查程式碼，並修正發現的問題。

10. 安裝前先檢查他人的技能和擴充功能。不要在未經檢查的情況下安裝任何東西。

今天就從哪裡開始#

不要試著一個晚上就完成本指南的所有事項——最後你會什麼也沒做。今天先採取最重要的三個步驟：

1. 檢查機密。 開啟 .gitignore，確認已列出 .env，並確認公開儲存庫中沒有金鑰。如果有任何金鑰外洩，就撤銷並重新發行。
2. 詢問 RLS。 告訴代理程式：「顯示 RLS 已關閉的資料表」，並在存有他人資料的所有資料表中啟用 RLS。
3. 設定頻繁備份。 如此一來，出問題時，你損失的是幾分鐘而不是幾天。

接著隨著專案成長、開始處理金錢和他人的資料，再依照上方的檢查清單逐項完成。

最後還有一件事。Vibe Coding 的安全性關乎擁有者的責任。你不必成為安全專家。AI 一個晚上就替你打造出產品——很好，但你必須為它負責。本指南列出的基本標準，就是實際履行這項責任的方法。

若要進一步使用模型，請前往 Ailoot。