資安研究機構 UpGuard 向 TechCrunch 披露，約有一萬六千個託管於開發平台 Supabase 的資料庫，在公開網絡上可被讀取到不同程度的個人資料，包括姓名、地址、電話，以及部分用戶密碼與驗證權杖。來源真實性已驗證。

報道指出，暴露個案與「vibe coding」（以 AI 快速產生應用程式）浪潮高度相關：生成程式常帶有安全缺陷，或缺少正確的資料庫存取設定，令開發者在不知情下把後端對外開放。Supabase 資訊安全長 Bil Harmer 回應稱專案「預設安全」，並強調平台與客戶共同承擔責任；公司亦會在發現問題時通知受影響客戶。本文只重寫已公開報道與官方文件要點，不構成安全審計或法律意見。

TechCrunch／UpGuard：約一萬六千個 Supabase 資料庫對外公開個資——vibe coding 助長配置失誤

二〇二六年九月二十五日（太平洋時間上午），TechCrunch 資安主編 Zack Whittaker 報道，UpGuard 在掃描託管於 Supabase 的客戶資料庫時，發現約一萬六千個庫存在可公開存取的個人資料。來源真實性已驗證：發現路徑為鎖定 RSS 清單中的 TechCrunch feed，全文核對 UpGuard 向媒體提供的規模與樣本類型、Supabase 資訊安全長 Bil Harmer 的回應原文，並以 Supabase 官方 Changelog（二〇二六年四月起收緊 Data API 預設暴露）與 Row Level Security（RLS）文件交叉說明機制，而非依賴單一轉述。

一、核心事件：萬六千庫外露，平台回應「共同責任」

技術細節

綜合 TechCrunch 已公開要點，可核對如下：

規模與託管位置：UpGuard 告訴 TechCrunch，約一萬六千個在 Supabase 託管、且可觀察到一定程度個人資料外露的資料庫。Supabase 提供網頁與應用程式開發者存放、運行資料庫的後端服務；公司今年稍早估值約達一百億美元，部分增長來自開發者把 vibe-coded 應用託管其上。
外露資料類型：研究指可公開存取的內容包括姓名、地址、電話號碼與用戶密碼；密碼與驗證權杖的數量相對較少，但仍屬高風險憑證類資料。
樣本情境（報道層）：UpGuard 舉例包括印度成人串流網站上與性工作者的私人對話紀錄、美國代客泊車服務的大量車牌、移民與搬遷服務使用者聯絡資料、某非洲政府駐法國領事館相關資料庫，以及用於攔截簡訊、竊取一次性驗證碼（OTP）以發動詐騙／釣魚的虛擬 SIM 農場資料。多數暴露資料集似乎位於美國，但 UpGuard 稱這是全球性問題。
與既有研究的關係：報道指今次發現建立在早前已公開的 Supabase 外露個案之上，當中包括 Y Combinator 新創與其他熱門應用；過去亦有單一錯誤配置即外洩數百萬筆紀錄的公開案例。
平台官方回應：Supabase 資訊安全長 Bil Harmer 表示尚未看到該研究全文，但指專案「secure by default」（預設安全），安全是公司與客戶的共同責任：「我們提供安全預設與工具，客戶則控制自身專案如何配置」；發現安全問題時會通知受影響客戶。他又稱「Security at Supabase is never finished」，會持續降低開發者安全上線的門檻。
研究動機：UpGuard 研究員 Greg Pollock 指研究旨在提高對資料外露問題的意識。

二、技術原理深度解析

Supabase 以 Postgres 為核心，並透過自動產生的 Data API（PostgREST／GraphQL）讓前端以公開的 anon 金鑰直接存取資料表。此模型在正確啟用 Row Level Security（列級安全，RLS） 並寫好政策時，公開金鑰本身並非漏洞——金鑰本來就可出現在瀏覽器；真正閘門是「哪幾列、哪幾個操作允許匿名或已登入角色執行」。

一旦資料表未啟用 RLS、政策寫成「全開放」，或新表仍沿用舊式「自動對 Data API 授權」的預設，持有專案 URL 與 anon 金鑰的任何人即可像呼叫公開 REST 端點一樣讀寫資料，無需登入、亦無需額外 exploit。AI 程式產生器與 vibe-coding 工作流往往優先讓示範流程「跑得通」，容易略過 RLS、GRANT 與密鑰分層，把本應後端保護的表直接暴露在客戶端。

Supabase 官方 Changelog 顯示平台已朝「更安全的預設」移動：自二〇二六年四月二十八日起，可選擇讓 public schema 新建資料表不再自動暴露給 Data API／GraphQL；五月三十日起該設定逐步成為新專案預設，未來新建表須明確 GRANT 才可被 Data API 看見。既有專案與已暴露的舊表並不會自動「治癒」，仍需人工盤點 RLS 與授權。這與 Harmer「共同責任」的表述一致：基礎設施可收緊預設，但線上專案的配置責任仍落在營運該應用的團隊。

四、日常應用場景

1. 開發者與技術團隊

凡以 Cursor、Bolt、Lovable、v0 等 AI 工具生成、並預設接上 Supabase 的專案，應在合併前以「陌生人視角」測試：只用前端可見的 anon 金鑰對 /rest/v1/ 查詢敏感表名（users、profiles、orders、messages 等）。若未登入即可回傳列資料，即屬配置事故而非進階攻擊。CI 應把「RLS 已啟用且政策以 auth.uid() 等範圍約束」列為合併門檻；service_role 金鑰絕不可進入前端或公開 git 歷史。

2. 企業與隱私敏感行業

金融、醫療、法律、人力資源與政府相關系統若採用 BaaS／低碼後端，供應商問卷不能只問「是否 SOC 2」，還要問：客戶專案的 RLS／GRANT 預設、外露偵測與通知流程、以及 vibe-coded 產生碼的安全審查責任邊界。UpGuard 樣本中出現領事館與 OTP 攔截相關庫，顯示錯誤配置可同時觸及個資保護、外交與詐騙基礎設施風險。香港企業若處理《個人資料（私隱）條例》下的客戶資料，誤開公開 API 等同可預期的資料外洩途徑。

3. 一般用戶

一般用戶難以直接稽核某 App 是否誤開 Supabase 表，但可優先選擇有明確私隱政策、支援刪除帳戶、且非純粹「一夜之間 AI 做出來」的服務；對要求上傳身分證明、車牌或醫療相關資料的新創應用提高警覺。密碼一經外洩應立即在各站改用唯一強密碼並啟用多重驗證。

4. 香港與亞洲市場視角

香港與亞洲大量中小企、初創正以 AI 低碼加速上線內部工具、顧客 App 與跨境營運面板。Supabase 等後端即服務降低了基建門檻，但也把「資料庫防火牆」從傳統運維手中，部分轉移到產品工程師與 AI 提示詞。本地團隊若服務歐美或東盟用戶，外露資料可能同時觸發多司法管轄區的通報義務。採購與資安應把「BaaS 配置審計」寫進上線 checklist，而非假設雲端託管等於自動合規。

五、專業評價與潛在考量

優勢

UpGuard 以可觀測外露規模（約一萬六千庫）量化問題，TechCrunch 取得平台 CISO 具名回應，報道可核對、可追責。
問題機制清楚：公開 anon 金鑰 + 缺失／錯誤 RLS（及舊式自動暴露），屬可檢測、可修復的配置類風險，而非未知零日。
Supabase 已用 Changelog 推動「新建表不自動進 Data API」的預設轉向，顯示平台層願意用破壞性變更換取較安全的預設。

需要留意的地方

截稿時 UpGuard 尚未見獨立公開研究頁與 TechCrunch 並列；規模與樣本細節以媒體轉述的研究方陳述為主，讀者應持續留意是否有後續技術報告。
「預設安全」與「共同責任」並不自動覆蓋歷史專案：舊庫、手動建表、AI 產生的錯誤政策仍可能大面積外露。
報道聚焦客戶配置，不應解讀為 Supabase 基礎設施本身已被攻陷；但對依賴該平台的產品而言，用戶資料外洩的後果同樣嚴重。
vibe-coding 加速交付的同時，若缺少強制安全閘門，會系統性放大同類事故——單一研究數字可能只是冰山可見部分。

結語

約一萬六千個 Supabase 託管資料庫對外可讀個資，把「AI 寫得出 App」與「App 守得住資料」之間的落差，推到企業與開發者眼前。機制並不神秘：公開 API 金鑰加上未鎖 RLS，就等於把 Postgres 表掛上互聯網。平台收緊預設值得肯定，但線上專案仍須逐表驗證。

若香港團隊正把 vibe-coded 或低碼後端推向生產，需要的不只是更快的產生器，而是雲端遷移、存取控制與持續監控的工程紀律。YSK Limited 提供雲端遷移與網絡安全服務（官網刊 99.99% 高可用性相關說明），可協助企業檢視零信任架構、後端暴露面與上線前資安基線：https://ysk.hk/services/cloud-security

參考來源

TechCrunch（Zack Whittaker）：Some Supabase customers are publicly exposing reams of people’s data to the web — https://techcrunch.com/2026/09/25/some-supabase-customers-are-publicly-exposing-reams-of-peoples-data-to-the-web/
Supabase Changelog：Breaking Change: Tables not exposed to Data and GraphQL API automatically（2026-04-28）— https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically
Supabase Docs：Row Level Security — https://supabase.com/docs/guides/database/postgres/row-level-security
發現來源（鎖定清單 RSS）：TechCrunch feed — https://techcrunch.com/feed/