資安業者UpGuard於10月1日發布報告，指出該公司掃描約30萬個使用Supabase資料庫的網域後，發現16,326個資料庫存在設定錯誤，資料表可被公開讀取。Supabase是提供託管PostgreSQL資料庫及後端服務的平台，常用於為網站與行動應用程式提供後端支援。
報告指出，在這逾1.6萬個暴露的Supabase資料庫中，超過一半含有個人識別資訊，部分還包含明文密碼、身分驗證權杖及一次性密碼（OTP），少數資料表則疑似含有信用卡資料。這些都是可以直接被濫用的敏感資料，風險等級相當高。
UpGuard進一步抽查部分暴露案例，發現的實例橫跨多個國家與產業。一個非洲國家的領事館洩漏2.5萬人的個資，包括住址和緊急安置點位置等資訊；一家美國代客泊車業者有逾10萬名顧客的聯絡資料、車牌及消費紀錄可公開讀取。
另外，一個加拿大移民服務業者資料庫的近5,000筆使用者紀錄中，有884筆包含明文密碼；一個印度內容平台有約6.5萬名使用者的個資及逾10萬則私人訊息外洩；菲律賓一家簡訊驗證服務則暴露逾2,000名使用者資料，以及逾10萬則含有OTP的簡訊。
這些案例有一個共通點：受害者多半不是大型科技公司，而是把後端交給Supabase這類託管服務的中小型組織。它們通常沒有專職的資安團隊，對資料庫權限設定的細節也不熟悉，反而更容易在預設值上出問題。
UpGuard指出，導致資料庫暴露的主要原因，在於資料列層級安全性（Row-Level Security，RLS）功能未啟用或設定不當，以及公鑰使用不當等。RLS是Supabase用來控制「誰可以看到哪些資料列」的關鍵機制，一旦關閉或配錯，等於把整張資料表攤在陽光下。
這類「預設不安全」的設計爭議在開發者社群已經討論多年。Supabase為了讓新手能快速上手，預設的政策相對寬鬆，但許多開發者上線後忘了回頭收緊權限，資料庫就這樣長期暴露在公開網路上。
對使用Supabase的團隊來說，現在最該做的就是立刻檢查自己專案的RLS政策是否啟用，並確認匿名金鑰（anon key）搭配的政策沒有過度授權。UpGuard的掃描方式並不複雜，代表任何有心人士都能用同樣手法找到暴露的資料庫。
從更廣的角度看，這起事件反映的是「後端即服務」普及後的資安落差。當架設資料庫的門檻降到幾次點擊，安全設定的責任就轉移到每一位開發者身上，而多數人並沒有意識到這一點。
接下來值得關注的是，Supabase官方是否會調整預設安全政策，例如強制新專案啟用RLS，或在偵測到高風險設定時主動警告。在官方出手之前，開發者只能靠自己把關，定期稽核資料庫的公開可讀範圍，是最基本也最重要的一課。
