# Vibe Coding 安全性：如何保護 AI 打造的應用程式 > 如何防止 AI 打造的應用程式遭到駭客入侵：Lovable 和 Tea 資料外洩、保護機密與金鑰、RLS、代理程式權限，以及發布前的安全檢查清單。 Source: https://ailoot.ai/blog/zh-hant-tw/vibe-coding-security/ Canonical: https://ailoot.ai/blog/zh-hant-tw/vibe-coding-security/ Language: zh-Hant-TW Publisher: Ailoot (https://ailoot.ai/) Translation: guide-014 Revision: sha256-7fe5b625f429351e5b1969daa2a68f700f8e311d5c97f7e6238bd487eff8cb94
重要重點 AI 打造的應用程式遭到駭客入侵，不是因為 AI 很笨，而是它預設會留下容易預測的漏洞：沒有 RLS 的開放式資料庫、直接寫在程式碼中的金鑰，以及只在介面中進行權限檢查。2026 年 5 月，一次掃描檢查了 380,000 個 Vibe Coding 應用程式，發現其中約 5,000 個正在洩漏他人的資料。我會說明這些應用程式會在哪些地方出問題，並提供一份手動檢查清單，即使你不是程式設計師也能使用。
更多 Ailoot 使用說明請參閱[文件](https://ailoot.ai/docs/)。 ## 為什麼 AI 打造的應用程式比較容易遭到駭客入侵？
重要重點 因為 AI 會以「能運作」為目標最佳化程式碼，卻不會思考「是否安全」。它會悄悄讓資料庫保持公開，把金鑰放進程式碼，並只在畫面上檢查權限。根據各種研究，AI 產生的程式碼有 40 到 62 percent 含有漏洞。而身為擁有者的你，要等到收到帳單或資料外洩時才會發現。
我自己也用 AI 打造產品，但不會因為安全問題而疑神疑鬼到「把所有東西都鎖到最嚴」。不過，有一個基本標準絕對不能低於，否則有一天你醒來時，資料庫可能已經空了，伺服器上還跑著別人的挖礦程式。本指南談的就是這個基本標準。不是要你「成為安全專家」，而是「別無緣無故搬石頭砸自己的腳」。 問題的根源很簡單。當你告訴 AI 代理程式「幫我打造一個客戶預約應用程式」，它會盡快讓應用程式運作。安全性是示範時看不見的額外工作。因此，資料庫會設成開放狀態，付款金鑰會直接放進程式碼，而「這位使用者是否有權限？」的檢查只存在瀏覽器中，一秒鐘就能繞過。 第二個原因是平台本身。 換句話說，漏洞會預設自動出現。你沒有做錯任何事，只是什麼也沒做——而在安全領域，不採取行動正是「對所有人開放」的意思。 還有第三層問題。AI 比人更容易洩漏機密。原因很明顯：代理程式不看內容就執行 `git add .` 和 `git push`，於是含有金鑰的 `.env` 檔案也跟著其他內容一起公開。 ## Vibe Coding 開發者已經從哪些慘痛教訓中學到經驗？
重要重點 他們都在相同的三件事上吃過虧：RLS 關閉、沒有權限檢查的開放式儲存空間，以及程式碼裡的金鑰。Lovable 洩漏了 170 個應用程式的資料；Tea 應用程式洩漏了約 72,000 張照片和超過一百萬則私人訊息。每個案例都有公開報告，並附上指定的漏洞編號。
防止粗心犯錯的最佳疫苗，就是從別人的錯誤中學習。以下有四篇報告，值得你在發布專案前讀一讀。 **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 在建立資料庫時設定了預設密碼，而且可以被自動猜中。接著就是熟悉的過程：入侵者進入系統、安裝挖礦程式，並改寫專案。伺服器最後必須徹底清除。預設密碼就像一扇沒上鎖的門，還掛著「歡迎進來」的牌子。
注意 留意這四個故事的共同點：沒有一個涉及「高明的駭客」。每個案例中，漏洞都是預設開放的，擁有者只是不知道必須把它關上。以下內容都在說明如何事先關上這些門。
## 安全性的兩條戰線：你究竟在哪裡容易受攻擊？
重要重點 有兩種威脅，而且彼此不同。第一種是 AI 代理程式本身：你讓它存取電腦、金鑰和資料庫，它即使沒有惡意，也可能破壞或拿走東西。第二種是完成後的應用程式：你放上網路的產品，其他人會對它發動攻擊。兩種威脅需要不同的防護方式，所以我會在下文逐一說明。
人們談到「Vibe Coding 安全性」時，通常會把兩種完全不同的擔憂混在一起。我們把它們分開，因為防護方式並不相同。 **第一條戰線——代理程式本身。** 你在自己的電腦上執行 AI 代理程式，並讓它存取檔案、終端機、金鑰和資料庫。風險在於代理程式不是人：它會照字面遵循指示，並找出最短的路徑，即使那條路徑很危險也一樣。這也包括其他人的指令透過代理程式讀取的文字「注入」代理程式的風險（這稱為 prompt injection）。 **第二條戰線——完成後的應用程式。** 這是你發布出去、讓大家使用的產品。攻擊目標是已發布的網站或服務：攻擊者闖入開放的資料庫、傳送偽造請求，或猜測他人的帳戶。這和代理程式無關——漏洞是更早之前留下的，其他人會利用它。 Claude 背後的公司 Anthropic 這樣說明主要的防護原則，而這個原則適用於兩條戰線：

先在環境層級設計防護措施，然後才管理模型的行為。

— Anthropic Engineering, https://www.anthropic.com/engineering/how-we-contain-claude
實際上，這表示不要指望 AI「自己避免做壞事」。先限制它實際能做的事，再要求它遵守規範。當它的行為失常時——而這一定會發生——只有你預先設下的硬性界線能保護你。 希望 AI 工作時表現可預期，不要每個新專案都讓你搬石頭砸自己的腳嗎？安全規則是 Second Brain 的一部分：把它們寫進 `CLAUDE.md` 一次，代理程式就會在每次請求中遵循。 ## AI 代理程式取得電腦存取權後能做什麼？
重要重點 代理程式會照字面遵循指示，並找到你意想不到的繞道方式。2026 年 5 月，一個沒有管理員權限的 Codex 代理程式注意到使用者可以存取 Docker，便利用這一點取得完整的 root 權限。教訓是：不要給代理程式超過任務所需的權限，也不要在正式環境的機器上以「允許所有操作」模式執行它。
最容易被低估的風險，是你自己的代理程式權限過於寬鬆。你甚至不需要外部駭客。你應限制代理程式的權限，避免授予任務不需要的管理員權限。 這裡沒有惡意意圖。只是當代理程式被要求「解決任務」時，它比人更快找到結構性弱點。如果這個弱點能讓它存取你的金鑰或正式環境，它就會利用這個權限。所以第一條規則是**最小權限**。只給代理程式完成特定任務所需的存取權，一點也不要多給。 這並不是我憑空想像。約翰霍普金斯大學的研究人員攻擊了 Anthropic、Google 和 Microsoft 的正式環境代理程式。他們的結論很直接： 即使你不是程式設計師，實際上可以怎麼做？ 1. ### 不要在正式環境的機器上以「允許所有操作」模式執行代理程式 代理程式不會要求確認的模式（通常稱為 bypass 或 yolo）只適用於沙箱或測試專案，不能用在存有有效金鑰和正式環境存取權的機器上。 2. ### 禁止代理程式讀取機密 在 Claude Code 中，你可以設定規則，拒絕存取含有金鑰的檔案。如此一來，即使代理程式想開啟 `.env`，工具也不會允許。 3. ### 將正式環境金鑰分開存放 正式環境資料庫和付款服務的金鑰，不應放在代理程式寫程式碼的同一個資料夾中。將環境分開：實驗時使用測試金鑰。 4. ### 使用工具的沙箱 新型 AI 工具可以在隔離的沙箱中執行命令，無法存取系統的其他部分。在 Claude Code 中，這能將權限請求減少約 84 percent，因此使用起來也更方便。 Claude Code 中拒絕讀取機密的規則大致如下——將它放在權限設定中： ```json { "permissions": { "deny": [ "Read(.env)", "Read(**/.env)", "Bash(git push *)" ] } } ```
註記 有個重要但書：拒絕讀取的規則涵蓋代理程式內建工具和直接的檔案命令。但如果代理程式執行自製腳本來開啟檔案，這項規則就無法阻止它。因此，真正的硬性界線是系統層級的沙箱，而不只是禁止事項清單。先限制環境，再管理行為。
## 絕對不能把 API 金鑰和密碼放在哪裡？
重要重點 只能放在列於 `.gitignore` 的 `.env` 檔案中，絕不能放在程式碼或公開儲存庫裡。只要金鑰進入公開儲存庫，機器人不到一分鐘就會找到並開始花你的錢。2025 年有 28.65 million 個機密洩漏到公開的 GitHub 儲存庫。如果金鑰已經外洩，只刪除它並不夠——你必須撤銷舊金鑰並重新發行。
最便宜也最常見的錯誤，就是把金鑰放進程式碼。付款服務的 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 時，為什麼所有人都能看到你的資料庫？
重要重點 RLS（Row Level Security，資料列層級安全性）是資料庫自動加在每個請求上的篩選器，讓使用者只能看到自己的資料列。沒有 RLS 時，任何持有應用程式公開金鑰的人都能讀取並變更所有資料。主要陷阱是：AI 透過 SQL 建立資料表時，RLS 預設為關閉。Lovable 的 170 個應用程式正是因此洩漏資料。
如果你使用 Supabase 或類似資料庫來打造應用程式，這是最重要的段落。RLS 是 Row Level Security 的縮寫。簡單來說，它是一條規則，決定特定使用者能看到資料表中的哪些資料列。沒有這項規則，「orders」資料表就會把所有客戶的訂單都傳給每個人。 Supabase 官方文件對此有個簡潔明確的說法：

任何未啟用 RLS 的資料表，都能透過 API 公開存取。

— Supabase Docs, https://supabase.com/docs/guides/database/postgres/row-level-security
這是 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 資料外洩的原因。 規則很簡單：**每個「這位使用者是否有權執行這項操作？」的檢查，都必須在伺服器上重複進行**。介面是為了方便，保護則必須在後端完成。可以直接交給代理程式的指示是：「為每個讀取或變更使用者資料的端點新增伺服器端權限檢查；不要依賴介面中隱藏元素的做法。」 ## 不是程式設計師的話，要如何檢查程式碼中的漏洞？
重要重點 使用三種能像安全工程師一樣讀取程式碼的工具。第一種是 Claude Code 內建的 `/security-review` 命令。第二種是 Anthropic 官方的 security-guidance 外掛程式，每次編輯程式碼時都會檢查。第三種是 GitHub 上收集的 754 個現成安全技能。重要的是：這些工具都無法提供百分之百的保證；它們是多層防護，而不是常識的替代品。
好消息是：現在你可以請同一個 AI 檢查安全性，而且它很能找出常見漏洞。以下是三種用途各異的工具。 | 工具 | 功能 | 何時執行 | |----|----|----| | `/security-review` | 用一個命令一次檢查分支 | 發布前手動執行 | | security-guidance 外掛程式 | 每次編輯、回合結束時及提交時進行檢查 | 在背景持續執行 | | GitHub 技能集 | 根據 OWASP、MITRE 和 NIST 標準進行 754 項檢查 | 需要深入檢查時 | **1. Claude Code 中的 `/security-review` 命令。** 一次性檢查目前分支的 SQL injection、XSS、授權漏洞、資料外洩和相依性問題。我在另一篇[Claude Code 安全性審查](https://ailoot.ai/blog/zh-hant-tw/claude-code-security-review/)指南中，逐步說明了它的運作方式，以及如何為每次變更加入自動檢查。這裡的重點是：它是第一道防線，只要執行一個命令就能啟動。 **2. 官方 security-guidance 外掛程式。** 從官方外掛程式市集使用 `/plugin install security-guidance@claude-plugins-official` 安裝（需要 Claude Code 2.1.144 或更新版本）。它會在三個時間點檢查程式碼：每次編輯時、每回合結束時，以及提交時。它會偵測授權繞過、IDOR、注入和弱加密。不過，Anthropic 坦率說明了它的限制：

請將此外掛程式視為深度防禦中的一層，而不是完整的安全解決方案。

— Anthropic，security-guidance 文件, https://code.claude.com/docs/en/security-guidance
```bash npx skills add / ``` 接著只要告訴代理程式：「檢查我的專案是否有漏洞。」不過，這個技能集有一項重要但書，所以下文會為它安排獨立段落說明。 補充背景：大型業者也開始認真看待 AI 程式碼安全性。Project Glasswing 在 2026 年 6 月 2 日擴大至 150 個組織。合作夥伴利用 Anthropic 模型，在短時間內找到超過 10,000 個重大漏洞。風險顯而易見：

我們估計，對大多數合作夥伴而言，一次重大攻擊可能影響超過 100 million 人。

— Anthropic（Project Glasswing）, https://www.anthropic.com/news/expanding-project-glasswing
## 可以信任來自 GitHub 的技能和擴充功能嗎？
重要重點 不能預設信任——安裝前先檢查。任何技能、外掛程式或擴充功能都是別人的程式碼，而代理程式會在你的電腦上以你的權限執行它。那個名字含有「Anthropic」的技能集其實是社群製作的，和 Anthropic 沒有關係。惡意擴充功能可能在幾分鐘內竊取你的金鑰，而移除套件也不一定能徹底清除它。
事情在這裡變得特別棘手，因為危險可能來自你為了安全而安裝的工具。執行 `npx skills add ...` 或安裝擴充功能時，你會把別人的程式碼載入系統，然後代理程式會以你的權限執行它。如果作者遭到駭客入侵，或套件從一開始就有惡意，就會出問題。 以上一節介紹的技能集為例。它的名稱中包含「Anthropic」，讓人放下戒心。但它自己的說明清楚寫著：

這是獨立的社群專案，與 Anthropic PBC 無關。

— mukul975 儲存庫 README
換句話說，這個名稱會造成誤解。這個技能集目前已相當成熟，也沒有問題，但原則不變：安裝風險由你自行承擔。而且這不是假設性的威脅。2026 年 5 月，一個惡意編輯器擴充功能只在市集上架了 18 分鐘，就在這段時間內竊取了安裝者的密碼管理器密碼、GitHub 權杖、雲端存取權，甚至 Claude Code 設定。另一個棘手之處是：這類惡意軟體往往不會在一般移除套件後消失，並會在下一個工作階段再次執行。 我養成了一個簡單的習慣，也建議你這麼做：從 GitHub 安裝任何技能前，先自行檢查。作者可能遭到駭客入侵、帳戶可能被劫持，惡意軟體也可能混進儲存庫。檢查就是你的防護措施。 安裝前最低限度要做的事：查看作者和星數、閱讀技能說明、不要只因為某篇文章推薦就安裝工具；如果工具不熟悉，先在獨立的測試環境中試用，不要在存有正式環境金鑰的機器上測試。 ## 資料外洩後能幫你恢復的工具：備份和復原
重要重點 最新的備份和 git。資料庫應該經常備份——至少每半小時一次；每三天才複製一次，代表會失去兩次備份之間累積的所有資料。使用 git 可以在代理程式破壞內容時，將程式碼復原至可運作的狀態。AI 遲早會刪掉重要資料——唯一的問題是你有沒有還原點。
安全性不只是「把外人擋在門外」，也包括「出問題時恢復正常」。因為事情一定會出錯。在一個實際案例中，AI 代理程式處理例行任務時，刪除了正式專案中線上運作的資料庫。雖然有備份，但那是三天前的版本——三天的資料就這樣消失了。 因此有兩項規則。 **經常備份。** 如果你的應用程式存有你不願失去的資料，每三天複製一次只是讓人以為受到保護。請設定至少每 30 分鐘自動備份一次。對大多數資料庫而言，包括 Supabase，只要點幾下就能啟用。 **git 是防範代理程式的保險。** git 會儲存程式碼歷史記錄，讓你還原到任何可運作的狀態。代理程式改寫原本能運作的內容時，你可以回復到最後一個可運作的版本，而不是手動修復。如果 AI 刪除或破壞專案，而你不知道如何復原，請參閱另一篇說明：[AI 刪除資料庫時該怎麼辦](https://ailoot.ai/blog/zh-hant-tw/ai-deleted-database-recovery/)。要預先防止專案遭到破壞，請參閱[如何防止 Claude Code 造成破壞](https://ailoot.ai/blog/zh-hant-tw/claude-code-safe-overnight-setup/)指南。 ## 發布前的安全檢查清單
重要重點 對外公開應用程式前，請逐項檢查 10 件事：`.env` 和 `.gitignore` 中的機密、已啟用 RLS、伺服器端權限檢查、Webhook 簽章、金鑰與代理程式的最小權限、最新備份、使用工具檢查程式碼，以及謹慎使用他人的技能。這是基本發布前清單，沒有實測涵蓋比例或保證完成時間；應驗證 app 真實存取情境，打勾本身不證明防護。
在發布前，依序檢查以下清單。 1. **機密放在 `.env` 中，並將 `.env` 列入 `.gitignore`。** 程式碼中不能有金鑰。公開儲存庫中不能有 `.env` 檔案。 2. **金鑰只具備最低限度的權限。** 每把金鑰只能執行必要操作。正式環境金鑰與代理程式的環境分開存放。 3. 所有含有使用者資料的資料表都**已啟用 RLS**，並設有存取政策。 4. 對每項資料操作都進行**伺服器端權限檢查**。只在介面中隱藏按鈕並不足夠。手動測試網址中的 `id` 是否能被更改。 5. **驗證 Webhook 簽章。** 每個處理外部通知的處理常式（付款、表單）都會驗證簽章。 6. 對收到的請求和高成本操作設定**速率限制**，避免密碼遭到暴力破解，也避免帳單暴增。 7. 存有正式環境金鑰的機器上，代理程式**不會以「允許所有操作」模式執行**。拒絕讀取 `.env`。 8. **經常備份**並實際測試——你真的試過還原，而不是只相信備份「放在某個地方」。 9. 使用 `/security-review` 或 security-guidance 外掛程式**檢查程式碼**，並修正發現的問題。 10. 安裝前先**檢查他人的技能和擴充功能**。不要在未經檢查的情況下安裝任何東西。
提示 別想一次把所有東西都鎖得像堡壘一樣，那只會讓人無法動彈。請依專案的風險調整安全等級：附有表單的簡單網站，和處理付款及醫療資料的應用程式，需要的嚴格程度不同。不過，任何其他人都能存取的專案，前五項都是基本要求。
## 今天就從哪裡開始
重要重點 先做三件事，補上最常見、代價最高的漏洞：檢查 `.env` 是否出現在公開儲存庫中、詢問代理程式哪些資料表已關閉 RLS，以及設定比每天一次更頻繁的備份。這些是有用起點，但時間與涵蓋取決於 app；接著仍需真實授權與還原測試。
不要試著一個晚上就完成本指南的所有事項——最後你會什麼也沒做。今天先採取最重要的三個步驟： 1. **檢查機密。** 開啟 `.gitignore`，確認已列出 `.env`，並確認公開儲存庫中沒有金鑰。如果有任何金鑰外洩，就撤銷並重新發行。 2. **詢問 RLS。** 告訴代理程式：「顯示 RLS 已關閉的資料表」，並在存有他人資料的所有資料表中啟用 RLS。 3. **設定頻繁備份。** 如此一來，出問題時，你損失的是幾分鐘而不是幾天。 接著隨著專案成長、開始處理金錢和他人的資料，再依照上方的檢查清單逐項完成。 最後還有一件事。Vibe Coding 的安全性關乎擁有者的責任。你不必成為安全專家。AI 一個晚上就替你打造出產品——很好，但你必須為它負責。本指南列出的基本標準，就是實際履行這項責任的方法。
### 來源 - [Anthropic 如何隔離 Claude（Anthropic Engineering）](https://www.anthropic.com/engineering/how-we-contain-claude) - [Project Glasswing 擴大計畫（Anthropic）](https://www.anthropic.com/news/expanding-project-glasswing) - [Claude Code：權限與 deny 規則（文件）](https://code.claude.com/docs/en/permissions) - [security-guidance 外掛程式（Claude Code 文件）](https://code.claude.com/docs/en/security-guidance) - [Row Level Security（Supabase 文件）](https://supabase.com/docs/guides/database/postgres/row-level-security) - [LLM 應用程式 OWASP Top 10 2025](https://genai.owasp.org/llm-top-10/)
若要進一步使用模型，請前往 [Ailoot](https://ailoot.ai/)。 ## 常見問題：Vibe Coding 安全性：如何保護 AI 打造的應用程式 ### 完成清單就證明 app 安全嗎？ 不會。它涵蓋常見起始檢查，沒有保證排除漏洞百分比。以普通使用者測真實資料存取，檢查 webhook 驗證，並證明備份能還原。 ### 隱藏管理按鈕為什麼不夠？ 攻擊者可直接發底層請求；伺服器必須逐項檢查呼叫者身分與權限，使用者資料也需正確資料庫政策。 ## Ailoot · 公司及其專案組合 Ailoot以累積的營運經驗、廣大的客戶群、穩定的服務及持續的KPI管理為基礎。 公司及其專案組合：數百萬客戶，每月銷售額達數十億。 Ailoot將這些營運經驗用於API存取，讓客戶的產品、代理、應用程式及自動化流程使用AI功能。