Vibe Coding 上生產環境的代價：安全漏洞、擴展失敗與實戰避坑指南

你花了三個週末用 Lovable 做出一個 app，功能完整、畫面漂亮，準備在 Product Hunt 上線。但你有沒有想過——你的資料庫是不是任何人都能直接讀？你的 API key 有沒有被 AI 寫進前端程式碼？你的 auth 邏輯有沒有被寫反，讓沒登入的人反而能看到所有資料？根據實際測試和多項安全研究，這些不是假設情境，而是 2026 年 2 月已經發生的真實事故。這篇文章給你一份部署前必須過的 security checkpoint，不需要工程師背景也能執行。

TL;DR

• Veracode 研究：100+ 個 AI 模型測試，45% 情況下生成含 OWASP Top 10 漏洞的程式碼（code completion task 情境，非完整 app 直接等同）
• Escape.tech 掃描 5,600+ 個 vibe-coded apps，發現 2,000+ 高危漏洞、400+ 洩漏的 secrets
• 2026 年 2 月兩起真實事故：Lovable app 18K+ 用戶資料外洩、Moltbook 150 萬個 auth tokens 曝光
• 最大隱性風險不是程式碼品質，而是資料庫預設配置（RLS 關閉）和 API key hardcoded
• 文末提供 15 點 production security checklist，indie maker 可立即執行

45%：AI 幫你寫的程式碼有多不安全

你以為 AI 生成的程式碼只是「功能可能有點怪」，但實際上問題遠不止 code style。

Veracode 2025 GenAI Code Security Report 是目前最大規模的 AI 程式碼安全研究之一——測試了 100 多個大型語言模型，設計了 80 個具有已知安全弱點的 code completion 任務，覆蓋 Java、JavaScript、Python、C# 四種語言。結果：在 45% 的情況下，AI 模型選擇了不安全的實作方式，直接引入 OWASP Top 10 安全漏洞。

具體來看最常見的漏洞類型：

• XSS（跨站腳本攻擊）：86% 的相關任務中 AI 未能正確防禦——這是失敗率最高的類別
• Java 程式碼：72% 的安全任務失敗，是四種語言中最差的
• SQL Injection：20% 失敗率，相對較低但仍顯著

這些數字來自 code completion 任務情境，不能直接說「你的 Lovable app 有 45% 機率有漏洞」。但根據我觀察到的模式，它作為基線警戒值是合理的：當你不去審查 AI 生成的程式碼時，你在和一個有 45% 機率引入安全漏洞的系統合作。

其他研究交叉驗證了這個趨勢。CodeRabbit 分析了 470 個 GitHub PRs，發現 AI 共寫程式碼引入 XSS 漏洞的比率是純人工的 2.74 倍。Tenzai Security 用 5 個 AI coding 工具各建了 3 個相同 app（共 15 個 app），發現 69 個漏洞——每一個工具都引入了 SSRF（Server-Side Request Forgery）漏洞，無一例外。

第一道門：資料庫配置——RLS 沉默地洩漏你的一切

如果你用 Lovable 或 Bolt 建 app，後端大概率是 Supabase。Supabase 的 Row Level Security（RLS）是一個在資料庫層控制「誰能讀哪些資料」的機制。簡單說：RLS 開啟 = 只有授權用戶能讀自己的資料；RLS 關閉 = 任何人都能讀走你所有用戶的全部資料。

問題是：根據 Retool blog 引用的 Beesoul data，約 70% 的 Lovable app 的 RLS 處於關閉狀態。

Escape.tech 的大規模掃描進一步確認了這個問題：在分析的 5,600+ 個 vibe-coded apps 中（主要來自 Lovable 約 4,000 個 apps），有 170 個 Lovable apps 存在 critical 等級的 RLS 漏洞。

Lovable 其實有建 security scanner——官方文件列出了 4 個自動化掃描器（RLS analysis、DB security check、code security review、dependency audit）。但關鍵問題是：security scan 在 publishing 前是可選的，不是強制的。這是工具設計層面的責任，不只是使用者的行為問題——當平台不強制執行安全檢查，就有大量 app 跳過這個步驟。

你現在就能做的驗證：

1. 打開 Supabase dashboard → Authentication → Policies
2. 確認每個 table 都有 RLS policies——如果某個 table 顯示「No policies」，那就是漏洞
3. 快速測試：用 anon key 直接查詢你的 table，如果能讀到資料 = RLS 未生效
4. 使用 Lovable 的 security scanner（Dashboard > Security > Run Scan）

第二道門：Secrets 管理——API Key 進了 Prompt 就回不來了

你把 Stripe API key 或 OpenAI API key 貼進 prompt 讓 AI 幫你設定串接，這個動作看起來很自然，但風險鏈比你想的長：

AI 把 key 寫進程式碼（hardcode）→ 你 deploy 到 Vercel/Netlify → 前端 JavaScript bundle 公開可見 → Google 索引你的前端程式碼 → 任何人都能拿到你的 API key

這不是理論推演。Escape.tech 在 5,600+ 個 vibe-coded apps 中發現了 400 多個直接曝光的 secrets——包括 Supabase JWT tokens、OpenAI API keys、Stripe keys 等，這些 secrets 可以在前端 JavaScript bundles 中直接找到。

根據實際操作的經驗，即使你沒有直接在 prompt 裡貼 API key，AI 也可能從範本檔案或 example code 中產生 hardcoded 的 key placeholder，而你在部署前沒有注意到它們已經是真實的 key。

正確做法：

1. 使用環境變數：所有 API key 放在 .env 檔案或 Vercel Environment Variables，永遠不要 hardcode
2. 啟用 GitHub Secret Scanning：Repository → Settings → Code security → 確認 Secret scanning 已開啟
3. 確認 .env 不在 git history 裡：執行 git log --all -- .env，如果有結果，代表 key 可能已經被記錄
4. 注意 NEXT_PUBLIC_ 開頭的變數：這類環境變數會暴露在前端，確認裡面沒有放 secret

第三道門：認證邏輯——Auth 寫反了沒人知道

Auth logic inversion 聽起來像是不會發生的事——認證邏輯怎麼會「寫反」？但 2026 年 2 月的 Lovable 事故證明這完全可能發生，而且是以最荒謬的方式。

根據 The Register 報導，安全研究員 Taimur Khan 在一個 Lovable Discover 上的考試管理 app 中發現：AI 生成的認證邏輯完全顛倒——登入的用戶被拒絕存取，而未登入的攻擊者反而可以讀到所有資料。這個 app 有超過 100,000 次瀏覽、約 400 個 upvotes，18,697 名用戶的資料被暴露，其中包括來自 UC Berkeley、UC Davis 等大學的 4,538 個學生帳戶。

這種漏洞特別危險的原因是：表面上你的 app 運作正常——登入的用戶可以使用功能，你以為 auth 沒問題。但你從來沒測試過「不登入的情況下能不能存取資料」。

你可以自己測試：

用 curl 或 Postman 對你的 private API endpoints 發送請求，不帶任何 token 或帶一個隨便打的假 token：

# 測試：不帶 token 存取 private API
curl -s -o /dev/null -w "%{http_code}" https://你的app.com/api/private-data

# 預期結果：401 或 403
# 如果收到 200 並且返回了資料 = 你有問題

如果收到 200 而不是 401/403，代表你的 auth 邏輯可能有漏洞，需要立即檢查。

擴展崩潰牆：在 5K 用戶才出現的問題

你的 vibe-coded app 在 50 個用戶的時候跑得很順，你以為已經沒問題了。但 The New Stack 有一個精準的描述：「At 50 users this is fine, at 5,000 it's a liability, and at 50,000 it's an incident.」

這不是嚴謹的 benchmark 數字，而是多個觀察者反覆描述的模式。根本原因是 AI 不會主動生成 production-grade 的架構元件：

• N+1 Query：AI 傾向在迴圈中逐次查詢資料庫。一個列表頁面如果有 1,000 筆資料，就會產生 1,001 次 DB 請求，而不是一次批次查詢
• Connection Pool Exhaustion：Supabase 免費方案只有約 20 個並發 DB 連線。10 個用戶同時操作可能就把 pool 用完
• 無 Rate Limiting：AI 不會在「做一個 todo app」的 prompt 裡加入 rate limiting，所以你的 API 任由外界無限制呼叫
• 無 Monitoring：你不會收到任何警告。當 DB 開始變慢或掛掉，你唯一發現的方式是用戶來告訴你

我觀察到最常見的崩潰情境是：app 在 Product Hunt 或 Hacker News 被 featured 後流量暴增，connection pool 直接用完，DB 開始 timeout，而你完全沒有 monitoring 可以看到發生了什麼。

預防措施：

• Rate limiting：最快方案是 Upstash Redis + Vercel middleware，免費方案就夠用
• Error monitoring：Sentry 免費方案，設定後至少能收到 alert
• 基本 load test：用 k6 免費方案模擬 100 個並發用戶，看 response time 和 error rate

真實事故解析：兩個 2026 年 2 月發生的案例

案例一：Lovable 考試管理 app——18K+ 用戶資料外洩

背景：一個用 Lovable 建的考試題目管理 app，在 Lovable Discover 頁面上線，累計超過 100,000 次瀏覽、約 400 個 upvotes。

漏洞：安全研究員 Taimur Khan 發現 16 個安全漏洞，其中 6 個是 critical 等級。最嚴重的問題是 auth logic inversion（認證邏輯顛倒）和 RLS 配置錯誤。

影響：18,697 名用戶資料外洩，包含 4,538 個 K-12 學校和大學的學生帳戶。

教訓：100K+ 瀏覽量不是安全的證明——規模不等於防護。app 「能用」不代表「安全」。

案例二：Moltbook 社交網路——150 萬個 auth tokens 外洩

背景：Moltbook 是一個完全用 vibe coding 工具開發的社交網路 app。

Root Cause：資料庫配置錯誤，與程式碼邏輯無關——純粹是 DB 層面的 misconfiguration。

影響：150 萬個 auth tokens 和 35,000 個 email 地址直接暴露在網路上。

教訓：vibe coding 的便利性不等於配置正確性。AI 幫你生成了整個 app 的架構，但資料庫的安全配置往往不在它的「自動完成」範圍內。

兩個事故的共同模式：沒有 security review → 帶真實用戶資料上線 → 漏洞被發現時已有大量用戶受影響。

如果你的 app 已經出事了——緊急應對三步驟：

1. 立即停服：暫時下線 app，防止更多資料洩漏
2. 評估洩漏範圍：哪些 table 被存取了？哪些用戶資料可能已外洩？
3. 通知受影響用戶：這不只是道德義務，在許多法規下也是法律要求

生態系現況：工具在進步，但還不夠

vibe coding 工具的安全機制正在成熟，但「工具存在」和「安全保障」之間仍有明顯差距。

Lovable：有 4 個自動化 security scanners（RLS analysis、DB security check、code security review、dependency audit）。這是正向進展，但 scan 在 publish 前非強制——意味著工具「提供了選項」但「沒有設置閘門」。

Bolt：目前無內建 security scan。如果你用 Bolt 建 app，安全檢查完全取決於你自己。

Cursor / Claude Code：這類工具屬於 code assistants（協助型），不是 full-stack generators（全自動型）。差異在於：Cursor 生成的程式碼至少有工程師在 review，Lovable/Bolt 則是直接 deploy。但「有人 review」不代表「review 的人有安全意識」——Tenzai Security 的研究顯示，用 5 個不同的 AI coding 工具建相同 app，每一個都引入了 SSRF 漏洞，不分工具類型。

根據實際使用這些工具的經驗，我的建議是：不要假設任何 AI coding 工具的預設配置是安全的。Full-stack generators（Lovable/Bolt）的風險主要在 infra 配置（RLS、auth、secrets）；code assistants（Cursor/Claude Code）的風險主要在程式碼邏輯（XSS、SSRF、injection）。兩種類型都需要 security review，只是 review 的重點不同。

重要：如果你正在考慮選擇 vibe coding 工具，可以參考 Vibe Coding 入門指南 了解各工具的基本比較，以及 Vibe Coding 做 Mobile App 的常見陷阱 了解 mobile 場景的額外風險。

量產級 Vibe Coding 安全 Checklist：上線前必須過的 15 個關卡

優先級 1：今天就做（如果你的 app 已有真實用戶資料）

• Supabase RLS 驗證：Dashboard → Authentication → Policies，確認每個 table 都有 RLS policies。如果某個 table 顯示「No policies」，你的資料正在裸奔
• GitHub Secret Scanning：Repository → Settings → Code security → 確認 Secret scanning 已啟用，且沒有 open alerts
• Lovable Security Scan：Dashboard > Security > Run Scan（如果你用 Lovable）。看到 Critical 或 High 等級的 warning 就立刻停下來修
• 確認 .env 不在 git history：執行 git log --all -- .env，如果有結果代表 secret 可能已被記錄
• 前端環境變數檢查：確認 NEXT_PUBLIC_ 或 VITE_ 開頭的環境變數沒有包含任何 secret（service role key、API secret key 等）

優先級 2：本週內完成

• Auth logic 測試：用錯誤 token 嘗試訪問所有 private API endpoints，預期收到 401/403，如果收到 200 代表 auth 有問題
• Rate limiting：加入 API rate limiting（Upstash Redis + Vercel middleware 是最快的方案）
• CORS 設定：確認只允許你的 domain，不是萬用字元 *
• Error monitoring：設定 Sentry 免費方案，至少能收到 crash alert
• Service role key 位置確認：確認 Supabase service role key 不在前端程式碼中（搜尋整個 repo 中的 service_role）

優先級 3：Launch 前必須完成

• AI-assisted security review：讓 Claude 審查你的主要 API routes 和 auth logic。示意 prompt：「請審查以下程式碼的安全性，特別檢查 auth logic、input validation、SQL injection 和 XSS 風險」
• Load test：用 k6 免費方案模擬 100 個並發用戶，觀察 response time 和 error rate
• DB backup 機制：確認有備份方案（Supabase 付費方案有每日備份）
• Incident response 計畫：出事了誰負責？用戶怎麼聯絡？有沒有公告機制？
• 高風險 app 外部 audit：如果你的 app 處理金融交易、醫療記錄、或其他高敏感個資——找有 security 背景的人做正式 audit，checklist 不夠

Vibe Coding 可以上生產環境嗎？誠實框架

答案是：可以，但有條件。

vibe coding 出來的東西不是天生不能上 production——問題在於大多數人跳過了上述的安全檢查。做完 15 點 checklist 的 vibe-coded app，和一個沒有做 security review 的傳統開發 app，前者可能更安全。

根據實際操作過多個 vibe-coded 專案的經驗，我的判斷框架是：

可以直接上線的情境：個人工具、內部使用的 dashboard、prototype / MVP 測試（有限用戶群、不處理敏感資料）——但即使是這些情境，優先級 1 的 checklist 仍然建議做。

需要完整 checklist 的情境：任何收集用戶個資的 app、有登入系統的 app、處理金流的 app——必須做完優先級 1 + 2。

需要外部 audit 的情境：金融服務、醫療數據、教育資訊（涉及未成年人）——checklist 是基本功，但不夠。需要有 security 背景的專業人士介入。

核心原則：vibe coding 的速度是優勢，但你省下來的開發時間，需要有一部分投回到安全檢查上。從部署前花 2-3 小時跑完優先級 1 checklist 開始。

如果你想了解更多 AI 程式碼安全的整體框架，可以參考 AI Agent 安全防線指南。如果你正在用 Cursor、Claude Code 或 Windsurf 做 code assistant 型的開發，安全重點會略有不同——focus 在程式碼邏輯層面而非 infra 配置。