資安公司 UpGuard 在 2026 年 9 月 25 日發布研究：他們從約 30 萬個疑似使用 Supabase 的網域中，實測發現 16,326 個資料庫的資料表可被任何人公開讀取，其中超過一半帶有個人可識別資訊（PII）跡象。根本原因不是 Supabase 被駭，而是透過 API／AI 代理建資料表時，行級安全性（RLS）預設不會被開啟。
這件事離台灣開發者有多近？
近到不行。只要你的 Side Project 是用 Cursor、Claude Code、Codex 這類工具「講需求就生出來」，並且後端挑了 Supabase（Claude Code 官方最常推薦的資料庫方案），那你的專案就在這次研究的掃描母體裡。
Supabase 在 2026 年 6 月完成 Series F、估值達 100 億美元，成長動能正是來自大量 Vibe Coding 專案把資料塞進它的託管 Postgres。UpGuard 研究總監 Greg Pollock 在報告裡用加州淘金熱比喻：淘金的人沒致富，賣鏟子的人致富了——而 Supabase 就是 AI 時代最成功的那把鏟子。鏟子賣得越好，沒挖好坑的人就越多。
UpGuard 到底掃了什麼？研究方法與核心數據
| 項目 | 數字／做法 |
|---|---|
| 掃描母體 | 約 300,000 個具 Supabase 特徵的獨立網域 |
| 資料來源 | BuiltWith 技術指紋 + BigQuery 上的 Chrome UX Report（CrUX）原始 JS 檔 |
| 測試方式 | 對每個網域查詢常見的 users 資料表，觀察回應 |
| 可讀資料庫數 | 16,326 個資料庫存在可公開讀取的資料表 |
| PII 比例 | 超過一半有 PII 跡象；少數含密碼、驗證 token；極少數疑似信用卡資料 |
| 研究發布 | 2026-09-25，作者 Greg Pollock（CISA 認證研究員） |
他們的判斷邏輯很簡單：Supabase 的資料庫位址和 API key 都藏在網站的前端 JavaScript 裡，因此可以用技術指紋工具批次撈出候選名單，再一個一個問「你有 users 表嗎」。回應有三種：
- 拒絕存取（RLS 生效或資料庫已下線）。
- 沒有
users表，但告訴你有哪些表可以讀 —— 這是 PostgREST 的「hint」機制，等於自動把可讀表名報給你。 - 直接回傳資料頁 —— 這就是 UpGuard 鎖定的目標。
第三種狀況就是本文要談的問題核心。附帶一提，第二種狀況的意義是：「資料表名稱取得很怪就沒人找得到」這種隱蔽式安全完全行不通。
根本原因：RLS 在 UI 建表會開，用 API 建表不會
Supabase 的資料庫是標準 Postgres，權限控管靠 RLS（Row Level Security）。RLS 的設計是：沒有對應 policy 的資料列，就算你拿得到連線也讀不到。
問題出在預設值不一致：
- 在 Dashboard 的 Table Editor 用滑鼠點出來的表 → Supabase 會自動開啟 RLS。
- 透過 API、Migration 腳本、SQL 指令建出來的表（也就是 AI 代理實際操作的路徑）→ 預設不開 RLS。
再加上絕大多數 Vibe Coding 專案會把 anon / publishable key 直接寫進前端程式碼。這本身不是錯（那是設計上給前端用的低權限金鑰），但只要資料表沒開 RLS，任何拿到這把公開金鑰的人就能透過自動生成的 REST API 讀走整張表。
也就是說，一個「照著 AI 給的指示、能跑、能上線、看起來一切正常」的網站，可能同時是一個公開的客戶資料庫。而人類開發者往往不知道這件事——因為程式是 AI 寫的，設定也是 AI 下的。
五個實際外洩案例
UpGuard 對高風險案例抽樣驗證，並通知了應用擁有者。以下資料全部來自該報告：
| 案例 | 地區 | 外洩內容 |
|---|---|---|
| 類 OnlyFans 成人串流平台 | 印度 | users 表 65,467 人（姓名、Email、生日、地址、駕照、護照、PAN 卡號、Aadhaar 後 4 碼）＋ 收款帳號（PayPal、Payoneer、Zelle、加密錢包、銀行、Stripe 卡號後 4 碼）＋ messages 表 10 萬則以上創作者與用戶私訊 |
| OTP 簡訊 / SIM Farm | 菲律賓 | 2,000+ 使用者帳號、10 萬則以上簡訊（含 OTP、sender ID、SIM 卡號），其中 2,000～2,400 則是真實的叫車司機與乘客對話（號碼循環使用被無辜牽連） |
| 代客停車 CRM 後台 | 美國東北部 | 10 萬+ 客戶（全數含電話，約 43,000 含 Email 與全名，約 78,000 含車牌號碼）、VIP 到訪紀錄、小費歷史、備註欄；另有 665 筆員工紀錄。外洩 Email 中 **4,560 個（11%）**屬企業網域，含大學與 Fortune 500 |
| 駐法國領事館 | 非洲某國 | 25,000 人的 PII 與實際住址，且有欄位標註個人目前的緊急安置住房地點 |
| 移民／搬遷諮詢服務 | 加拿大 | 近 5,000 筆申請者紀錄（姓名、Email、電話、生日），其中 884 筆密碼以明文儲存 |
另外報告也提到 Wiz 在 2026 年 2 月發現的 Moltbook（號稱 AI Agent 的社群網站）事件：整個 Supabase 被看光，35,000 個 Email 加 150 萬個 API 驗證 token。
值得注意的是，外洩與商業模式無關。研究明確指出：B2B、B2C 的資料暴露種類沒有差別，因為「知道自己在做什麼生意的人」跟「知道自己資料庫設定的人」是兩群人。
這不是第一次：一年半的研究軌跡
| 時間 | 研究單位 | 發現 |
|---|---|---|
| 2025-03 | 開發者 Matt Turner（CVE-2025-48757） | Lovable 生成的 Supabase 資料庫缺乏 RLS，任何使用者都能查詢 |
| 2025 | Modern Pentest | 掃 107 家 Y Combinator 新創，28% 暴露 PII |
| 2025–2026 | Symbiotic Security | 掃 1,072 個 Vibe Coded 應用，39 個可用公開金鑰直接讀表 |
| 2026 | Escape | 約 1,400 個應用中，175 個資料庫洩漏 PII |
| 2026 | Red Access | 掃 380,000 個 URL，找出 5,000 個可存取應用，其中 **2,000 個（40%）**暴露敏感資料 |
| 2026-09 | UpGuard | 16,326 個可讀資料庫（本次） |
Supabase 的回應與已經做過的安全補強
Supabase 資訊安全長（CISO）Bil Harmer 回覆 TechCrunch 時表示，公司還沒看到這份研究，但強調 Supabase 專案「預設即安全（secure by default）」，安全是平台與客戶的共同責任：「我們提供安全的預設值與工具，客戶控制自己專案的設定」，並會在發現問題時通知受影響客戶。他補充：「Supabase 的安全永遠沒有完成的一天。」
從官方《2025 年安全回顧》（由 CISO Bil Harmer 與執行長 Paul Copplestone 共同署名）看，平台這一年其實補了不少洞：
- 可整站關閉 Data API，或把預設 schema 從
public改成api，縮小自動生成 REST／GraphQL API 的曝露面。 - 新版 API key 模型：以 publishable key（低權限）與可撤銷的 secret key 取代長效 JWT 的
anon/service_role，支援非對稱 JWT 與即時輪替；舊金鑰預計 2026 年底退場。 - GitHub Secret Scanning 自動撤銷：偵測到 secret key 出現在公開 repo 就直接撤銷並通知。
- Dashboard 建表預設開啟 RLS，並提供 Event Trigger 一鍵設定，讓「用 API／Migration 建表」也能自動強制開 RLS。
- Table Editor 對未開 RLS 的表顯示警告標籤，並寄送 Email 警示。
- Security Advisors（以開源 Postgres linter
Splinter為底）掃描未開 RLS 的表、過寬的 policy、敏感欄位暴露，每週寄摘要，也能透過 MCP server 在開發環境直接掃描與修復。 - Dashboard Assistant 可用自然語言生成並套用 RLS policy SQL。
- HackerOne 漏洞回報計畫累計已處理 139 份來自 96 位研究員的報告。
值得注意的是：「Dashboard 預設開 RLS」這件事，對 AI 代理沒有幫助——代理走的是 API 建表路徑，這正是 UpGuard 報告認為問題會持續發生的原因。
台灣開發者現在就能做的六步自我檢查
如果你手上有一個 Supabase 專案（尤其是請 AI 寫的），建議今晚就照這個順序跑一遍：
1. 開 Security Advisors
到 Supabase Dashboard 的 Security Advisors 頁面，看有幾條 rls_disabled 或 policy 過寬的警告。
2. 用 SQL 一次查出所有沒開 RLS 的表 在 SQL Editor 執行：
select schemaname, tablename, rowsecurity
from pg_tables
where schemaname = 'public' and rowsecurity = false;
只要有一列回傳，那張表就是公開的。
3. 補上 RLS 與最小權限 policy
alter table public.orders enable row level security;
create policy "users can read own orders"
on public.orders
for select
using (auth.uid() = user_id);
4. 加上 Event Trigger，讓未來建的表自動開 RLS Supabase 官方文件已提供現成的 Event Trigger 範例與 Dashboard 一鍵設定；設好之後，就算是 AI 代理用 API 建表也會被強制套用。
5. 檢查金鑰型態並輪替
前端只留 publishable key；secret key 一律放後端環境變數。若曾經把 service_role 或 secret key commit 進 Git，直接輪替（rotate），別只刪 commit——歷史紀錄還在。
6. 用公開金鑰自我滲透測試
拿你官網 JS 裡那把公開 key，對 https://<project>.supabase.co/rest/v1/<table>?select=* 發一個請求。如果回傳資料，就是 UpGuard 掃到的那種情境。
補充：企業級設計還要考慮「關掉沒用到的 Data API」、「設定 IP allowlist」、「開啟 fail2ban（Supabase 全託管資料庫已預設開啟）」與備份以外的資料落地策略，這些在官方安全回顧中都有對應設定。
產業意義：S3 桶子與 GitHub 的老故事，換個地方重演
UpGuard 的結論下得很直白：資料外洩 = 技術的易錯程度 × 使用者規模。同時滿足這兩件事的技術沒幾個，而滿足它們通常代表商業上的巨大成功——Amazon S3 靠預設好讀寫拿下了市場，也留下延續至今的成千上萬個公開桶子；GitHub 當年預設公開（私有 repo 還要付費）帶來無數憑證外洩。Supabase 現在站上了同一個位置。
對企業的實務啟示有三點：
- 共同責任模型不是免責聲明，是分工表。 平台負責「安全預設值與工具」，專案的存取控制責任在客戶身上。用 AI 加速開發，不能順便把設定檔也外包給 AI。
- 把 RLS 檢查放進 CI。 Security Advisors 支援 MCP server，代表這件事可以被自動化：部署前掃一次，比事後通知客戶便宜太多。
- Vibe Coding 的速度優勢，要用可觀測性換。 資料庫設定不會出現在程式碼 review 裡，但會出現在網路上。
最後一句給正在做 Side Project 的讀者：你的網站有沒有被這次研究掃到，取決於一張表有沒有多打一行 enable row level security。這行 SQL 的成本是 30 秒，代價差距則是 25,000 人的緊急安置地址會不會出現在公開網路上。
站內延伸閱讀
- Supabase 完整教學 2026：108K 星開源 Firebase 替代品，Postgres 資料庫、Auth、Storage、Edge Functions 一次學會
- Supabase 作為後端平台的全貌與選型考量
- LLM 模型路由完整指南 2026：成本、延遲與可靠度怎麼權衡
原始來源
- UpGuard Research, Everything Everywhere: Systemic Data Exposure in Supabase Apps（2026-09-25）：https://www.upguard.com/blog/everything-everywhere-systemic-data-exposure-in-supabase-apps
- TechCrunch, Some Supabase customers are publicly exposing reams of people’s data to the web（2026-09-25）：https://techcrunch.com/2026/09/25/some-supabase-customers-are-publicly-exposing-reams-of-peoples-data-to-the-web/
- Supabase, Supabase Security Retro: 2025：https://supabase.com/blog/supabase-security-2025-retro