一句話結論
德國資安公司 Crissy Field 掃描 159,041 個 Lovable 專案，發現大量以 Supabase 為後端的應用，在沒有登入的情況下就能讀到資料庫紀錄，其中包括護照號碼與 20 萬則私人訊息；研究者同時強調，30% 這個數字不是外洩率，樣本也不代表全部 Lovable 應用。
研究到底掃了什麼
這份報告由 Crissy Field GmbH 與德國商業日報《Handelsblatt》合作進行，記者 Lina Knees 於 2026 年 11 月 2 日先刊出報導；完整研究報告後續上線，並更新了部分數字。方法是從公開網頁典藏 Common Crawl 撈出 2025 年 12 月至 2026 年 9 月之間建立的 Lovable 專案，再逐一觀察兩件事：頁面第一次載入時送出了什麼、以及用同一把 API key 再發送唯讀請求時還能拿到什麼。
| 階段 | 數量 | 說明 |
|---|---|---|
| 辨識出的 Lovable 專案 | 159,041 | 來自 Common Crawl，2025-12 至 2026-09 |
| 使用 Supabase 的專案 | 34,545 | 研究只檢驗 Supabase 整合，未含 Lovable 自家資料庫功能 |
| 一載入就送出資料庫紀錄 | 24,664 | 不需要登入、不需要任何互動 |
| 後續唯讀請求可讀到含 email 的資料表 | 10,560 張表、分布於 7,403 個站 | 佔 24,664 個站的 30% |
值得注意的是，第一層的「一載入就送出紀錄」本身不是漏洞——有些網站本來就要公開展示資料。真正的問題發生在第二層：研究團隊用同一把 key 再做唯讀請求時，仍然讀到不該公開的內容。這個「同一把 key 可以推向更多張表」的特性，也是為什麼問題會從單一網站擴散成一個族群的問題。
五個寫進報告的實際案例
研究報告列出的案例不是抽象統計，而是具體到資料欄位：
| 案例類型 | 可讀到的內容 |
|---|---|
| 德國生活風格論壇 | 80,000 多筆會員資料（全名、email、生日、性別），外加 200,000 則以上聊天訊息 |
| 活動主辦方與餐廳 | 數萬筆票券與餐飲銷售紀錄，含 email、電話、地址、付款資訊、票券代碼 |
| 物業管理公司 | AI 生成的內部郵件摘要，內容涉及租客、屋主與商業夥伴的敏感資訊 |
| 某服務供應商 | 1,000 多筆身分證件資料，含護照號碼、到期日、國籍 |
| 其他 | 數萬份合約、發票、私人相簿、內部 WhatsApp 對話；另有 280,000 封寄給客戶的 email 可被讀取 |
研究者指出，這些資料可用於釣魚、票券詐騙與身分盜用，但無法確認是否已經被實際濫用。
資訊分三層：事實、當事人說法、還在調查
這則新聞很容易被寫成「Lovable 外洩 15 萬個專案」，那是錯的。把三層切開看：
| 層級 | 內容 |
|---|---|
| ✅ 已證實（研究報告與一手文件） | 159,041 / 34,545 / 24,664 / 7,403 這組數字；五個案例的資料型態；研究者未公開存取細節以免擴大風險 |
| ⚠️ 當事人說法（媒體轉述） | Lovable 向《Handelsblatt》表示這是「整個產業共通的設定問題」，不是平台本身被駭。此說法目前只有媒體轉述，未見完整原文 |
| 🔍 仍在調查／無法證實 | 30% 是否等於「三成 Lovable 應用外洩」；是否有任何一筆資料被濫用；Lovable 自家資料庫功能是否有同類問題（研究明確排除） |
Lovable 的服務條款把應用程式與資料處理的責任放在客戶身上，而它的行銷強項正是「不需要技術背景也能做專案」。這兩件事放在一起，就是報告最想指出的落差：平台承諾了低門檻，卻沒有承接低門檻之後的安全責任。
為什麼「Supabase 設定失誤」會變成 Lovable 的頭條
關鍵在於 Supabase 的設計。前端應用需要一把 anon key 才能呼叫資料庫 API，這把 key 本來就會出現在瀏覽器裡、本來就該被視為公開資訊——真正的門禁是資料庫上的 **Row Level Security（RLS）**政策。RLS 沒開，anon key 就等於一張可以讀整張表的通行證；RLS 開了但政策寫成 using (true)，效果一樣。
Lovable 讓建立 Supabase 專案變成幾句話的事，於是同一個錯誤設定會在全平台上大量複製。報告用了一個很具體的說法：攻擊者對一個應用有效的探測方式，換到下一個應用幾乎不用額外成本。對沒有受過權限模型訓練的使用者來說，這種錯誤不會有任何畫面提示。
Lovable 官方文件其實寫得很清楚
值得注意的對照是，Lovable 自己的 Supabase 整合文件早就明講：
在正式上線前，請確認每一張表都有 RLS 政策限制誰能讀寫哪一列……缺少 RLS 政策是應用資料外洩最常見的原因。
文件同時說明平台會在 schema 變更後執行自動化安全檢查（含 RLS 覆蓋率），並提醒使用者自己到 Supabase 後台複核。換句話說，「該做什麼」並不是未知，落差在於自動檢查與實際防護之間還有一大段要靠人判斷的空間——而這正是研究者主張「自動化檢查不能取代專業安全評估」的依據。
研究者自己列出的五個限制
判斷這則新聞的份量時，這五點必須一起讀：
- 用 email 當判準：含 email 的紀錄較可能是個資，但也可能是公開聯絡信箱或測試資料；同時會漏掉沒有 email 的個資。兩個誤差方向部分互相抵銷，但無法量化。
- 樣本不具代表性：Common Crawl 只收錄被爬到的網站，不等於全部 Lovable 應用。
- 只取部分資料：研究團隊沒有把資料集整包下載，實際外洩量可能更多。
- 未檢驗 Lovable 自家資料庫：2025 年底推出的原生資料庫功能不在檢驗範圍，同類錯誤可能存在但未知。
- 未證實濫用：沒有證據顯示這些資料已被使用。
因此「30%」只能讀成「在 24,664 個進一步檢查的網站中，有 30% 讀到含 email 的資料表」，不能讀成外洩率。這一點在研究報告與多數外媒報導裡都被特別標註。
台灣使用者今天就能做的五件事
如果手上的專案是 Lovable、Bolt、v0 這類工具生成、而且接了 Supabase，下面五步可以直接照做：
- 先分清兩把 key：
anon出現在前端是正常的；service_role一旦出現在前端或 repo 就是重大問題，必須立刻輪替。 - 逐表確認 RLS 已啟用。在 Supabase SQL Editor 跑：
select schemaname, tablename
from pg_tables
where schemaname = 'public' and rowsecurity = false;
回傳任何一列，就代表那張表沒有門禁。
- 檢查政策內容，不只看開關。
using (true)等於對所有人開放；auth.uid() = user_id這類條件才有實際隔離。 - 把敏感表搬到 Edge Function 後面：金鑰、付款、身分證件這類資料不該由前端直接查詢。
- 上線前做一次外部視角測試：登出、開無痕、只帶
anonkey 打一次 API，看拿到什麼。這一步最接近研究者做的事。
站上先前整理的 Supabase 1.6 萬個資料庫外洩事件，講的是同一種失效模式，可以對照著看檢查清單。
這件事的意義不在 Lovable
把責任全推給一個平台，會漏掉真正的訊號：AI 讓「做出一個有資料庫的應用」變成十分鐘的事，但沒有讓「判斷誰能讀哪一列」變成十分鐘的事。當同一套樣板被複製十萬次，一個設定的疏忽就會變成一個族群的疏忽，而受害的是那些以為「平台會處理好」的一般使用者。
對開發者而言，結論很朴素：低門檻工具不改變安全責任的分配，只改變它被發現的時間。
站內延伸閱讀
（本文無聯盟連結；引用數字以 Crissy Field 公開報告與《Handelsblatt》2026-11-02 報導為準。）