數千個 Vibe Coding 應用大爆煲：企業與個人資料正在公開網絡裸奔

最近安全研究員陸續爆出一個相當難看的現象：由 AI「vibe coding」方式快速生成、再一鍵部署上線的應用程式，正在大規模地把資料庫、API key、後台端點、甚至客戶個資直接曝露在公開網絡上。數量不是幾十個、幾百個，而是數以千計。這篇文章想講清楚的重點只有一個——這波洩漏的根本原因，不是黑客技術有多高，而是 vibe coding 這種寫法本身，天然就會製造出「無認證、無檢查、無防護」的應用。

事件到底發生咗咩事

所謂 vibe coding，指的是用戶只用自然語言向 AI（例如 Cursor、Lovable、Bolt、v0、Replit Agent 等）描述需求，AI 就把整個前後端連同部署一次過生成。開發者甚至不需要理解 code 本身，按幾個掣就上線。

問題是：AI 生成的 code 預設是「先讓佢跑得起」，不是「先讓佢安全」。研究員掃描這批公開部署的 vibe-coded 應用時，發現幾類非常典型的低級錯誤反覆出現：

• Supabase、Firebase 的 service key 直接硬編碼在前端 JavaScript
• 資料庫 Row Level Security 從未啟用，任何人都可以讀寫全部 table
• 後台管理頁完全冇 auth check，網址一猜就中
• .env 檔連同 OpenAI API key、Stripe secret key 一齊 push 上 public repo
• CORS 設成 *，任何域名都可以打你 API

這些不是罕見漏洞，而是幾乎每個 vibe-coded 專案都會中招的預設狀態。

最值得警惕的四個結構性問題

這次事件真正值得記錄的，不是「有人洩漏了資料」，而是這種洩漏方式已經產業化、規模化。以下四點是我認為最值得留意的：

1. AI 幫你寫 code，但唔會幫你寫「安全預設」

當你叫 Lovable 或 Bolt 幫你整一個「客戶登記系統」，它會很順暢地生成 Supabase table、form、API。但它預設不會幫你打開 RLS，不會提醒你 anon key 只應該有極有限權限。用戶睇到嘢跑得起，就以為完成，實際上個資料庫係全世界都可以讀。

2. 部署變得太快，快到冇時間諗安全

傳統開發即使草率，中間也有 staging、code review、DevOps 檢查。Vibe coding 把「從構想到 production」壓縮到 30 分鐘內，安全審查這一步根本冇出現過。個 app 上咗線，創辦人已經去接下一單。

3. 洩漏的唔止係 side project，而係真實商業資料

研究員發現，這批曝光的應用裡面有 SaaS MVP、內部 CRM、活動報名系統、甚至醫療類 intake 表格。入面躺住的係真實電郵、電話、身分證片段、發票、Stripe customer ID。這些不是 demo data，是拎住真金白銀客戶資料在裸跑。

4. 攻擊成本極低，掃一次就成千上萬個目標

因為 vibe coding 生成的 code 結構高度相似，攻擊者只要寫一個 script 掃 /api/admin、/supabase、.env、config.js，就可以批量收割。這是一個對攻擊者極度友善、對受害者極度陌生的新攻擊面。

一個具體場景：三日整好嘅登記表

想像你係一個活動主辦方，用 Lovable 三日整咗一個報名網站，收咗 800 個參加者資料，包括真實姓名、公司、職位、電話。你以為個 form 提交後資料入咗 Supabase、只有你睇到。

實際上：前端 JS 裡面就有你個 Supabase URL 同 anon key，RLS 冇開，任何人打開 devtools 抄低嗰兩條字串，就可以用同一條 anon key 一次過 dump 曬全部 800 條紀錄。你完全唔會知，因為 Supabase console 唔會亮紅燈——嗰個 request 對佢嚟講係「合法查詢」。

這不是假設，這正是研究員在數千個站上重複驗證到的模式。

唔好將問題全部賴落 AI 身上

公道講一句：vibe coding 工具本身不是罪魁禍首。Cursor、Lovable、Supabase 都提供 RLS、環境變數、auth 模組，只係大部分用戶跳過咗。真正的問題是市場出現咗一種新型「開發者」——佢地識用 prompt，但唔識分 anon key 同 service key 有咩分別，唔知 public bucket 同 private bucket 差在邊。

對這班用戶而言，「app 跑得起」就等於「app 完成咗」。安全從來冇進入過佢地的 mental model。

如果你正在用 vibe coding，最少要做這幾件事

呢篇文唔係想叫大家唔好用 AI 寫嘢——呢個趨勢擋唔到。但如果你手上有一個 vibe-coded 應用而入面有真實用戶資料，請至少檢查：

• 打開 Supabase / Firebase 的 Row Level Security，並實測一次匿名用戶能讀到什麼
• 檢查前端 bundle，有冇 service role key、Stripe secret、OpenAI key
• 所有 /admin、/dashboard 路由必須有 server-side auth check，不是靠前端隱藏
• Git repo 檢查 .env 有冇被 commit，有的話 rotate 所有 key
• CORS 白名單化，唔好留 *

呢五樣嘢，AI 通常唔會主動提你做，但係佢地就係區分「demo」同「可以真的收客戶資料的產品」的界線。

一句總結

Vibe coding 令開發門檻低到前所未有，但同時把「安全常識」外判給咗一個唔會主動提醒你的 AI。當數千個應用同時用同一種預設出街，洩漏就唔再係個別事故，而係一種系統性風險。下一次你按下 Deploy 之前，唔該至少花五分鐘，睇一眼個資料庫係咪真係只有你自己入到。

追蹤以下平台，獲得最新AI資訊：
Facebook: https://www.facebook.com/drjackeiwong/
Instagram: https://www.instagram.com/drjackeiwong/
Threads: https://www.threads.net/@drjackeiwong/
YouTube: https://www.youtube.com/@drjackeiwong/
Website: https://drjackeiwong.com/