Supabase逾1.6萬資料庫公開可讀：開發團隊應先檢查RLS與資料表權限

圖片：TechLab 自製資訊圖

TechLab 編輯部（譯）·2026-10-13

掃描發現大量公開資料庫，但不代表全部資料已遭濫用

iThome 報道，資安公司UpGuard在掃描約30萬個使用Supabase的網域後，發現16,326個資料庫有存取控制設定問題，資料表可被公開讀取。Supabase常被用作網站及手機app的託管PostgreSQL資料庫和後端服務，因此受影響的範圍不只限於單一類型產品，也可能涉及需要快速推出會員、訊息、預約或交易功能的團隊。對開發者而言，問題的焦點不在於是否採用Supabase，而是在於資料庫的實際讀取規則有否隨功能上線而被正確收緊。

iThome 指出，在UpGuard發現的暴露資料庫之中，逾半數包含可識別個人身分的資料；部分更有明文密碼、身分驗證權杖及一次性密碼，少數資料表疑似載有信用卡資料。不過，這項研究屬於外部掃描和抽查結果，能證明部分資料表曾經公開可讀，卻不能直接推論每一個資料庫已被入侵、所有資料已被下載，或資料一定已被犯罪者濫用。評估風險時，團隊要同時避免淡化公開暴露，也不應把掃描數字誤寫成已確認的大規模資料外洩。

RLS被略過，會令「能連上」變成「誰都能讀」

iThome 報道引述UpGuard的判斷，資料暴露主要與資料列層級安全性（Row-Level Security，RLS）未啟用、設定不當，以及公鑰使用不當有關。RLS的意義，是讓資料庫按每一列資料及存取者身分執行規則；例如用戶理應只可讀取自己的帳戶或訂單，而管理人員才可查看更廣範圍資料。若這類限制沒有生效，一張原本只為app功能而設的資料表，便可能在未登入或不應有權限的情況下被讀取。

這個風險特別容易出現在快速開發流程。團隊為了先完成註冊、登入、聊天或表單等功能，可能先讓前端順利取得資料，再把權限收緊工作留待其後處理；但當資料表已有真實用戶資料，延後檢查就可能把暫時安排變成長期暴露。從iThome報道列出的案例可見，外洩內容不只限於基本聯絡資料，亦可延伸至車牌、消費紀錄、私人訊息、住址、緊急安置點和OTP。資料欄位本身看似平常，合併後卻可能提高詐騙、帳戶接管或人身安全風險。

UpGuard抽查到的個案遍及不同地區和行業，包括領事館、代客泊車公司、移民服務商、內容平台及短訊驗證服務。iThome 報道提到，其中一個加拿大移民服務商近5,000筆使用者紀錄中，有884筆含明文密碼；一個菲律賓短訊驗證服務則有超過10萬則含OTP的短訊公開可讀。這些案例說明，資料庫權限錯誤的後果取決於表內資料類型：同一項設定疏忽，放在測試資料中或許只是品質問題，放在認證資料及通訊紀錄中，便會迅速升級為保安事故。

自查應由資料表和實際角色開始

對採用Supabase的團隊來說，首要工作是建立已上線資料表清單，將用戶資料、認證相關欄位、私人內容、交易或位置資訊列為較高優先級，逐一確認哪些資料理應可公開讀取，哪些只應由登入用戶、資料擁有人或後台人員存取。這一步不宜只看介面是否正常運作；介面把按鈕隱藏，並不等於資料層已拒絕請求。較穩妥的做法，是以未登入帳戶、一般用戶及管理角色分別測試讀取結果，確認每個角色只能取得業務所需的最少資料。

其次，應逐表檢視RLS是否已啟用，以及規則是否真正對應產品情境。開發團隊可把「用戶只能讀寫自己資料」、「私人訊息只向相關帳戶開放」、「管理功能不能由一般用戶呼叫」這類要求寫成可驗證的存取情境，再在部署前和功能改動後重新測試。若資料表本來需要公開內容，也應將可公開的欄位與內部欄位分開處理，避免為了展示名稱或文章列表，連同電郵地址、電話、權杖或其他不必要資料一併回傳。

公鑰的處理同樣不能只視為前端設定細節。既然iThome 報道指出公鑰使用不當是成因之一，團隊便應盤點前端程式、流動應用程式設定與公開程式碼庫中使用的連線設定，確認它們不會配合寬鬆的資料表規則取得超出預期的內容。重點不是單純把所有資訊由前端移走，而是要把每個公開可用設定與資料庫規則一併檢視：若資料庫端沒有足夠限制，任何看似方便的公開存取入口都可能擴大敏感資料暴露的範圍。

把權限測試納入發布流程，減少設定隨功能漂移

從工程管理角度看，這次事件反映資料庫保安不能只在專案初期設定一次。新加欄位、複製資料表、調整登入流程、引入客服後台，甚至為了除錯而放寬讀取條件，都可能令原有權限假設失效。團隊可把存取測試視為發布檢查的一部分：每次涉及資料表、認證或角色的改動，都重新驗證匿名、普通帳戶及管理帳戶的可見資料。這類測試未必能杜絕所有錯誤，卻可及早發現「功能能用但權限過闊」的常見問題。

對香港的初創、代理商和內部開發團隊而言，iThome報道未列出本地受影響個案，因而不能據此斷言香港已有同類資料外洩。不過，採用雲端後端服務和快速迭代產品的團隊，同樣應把事件視為一次設定檢查的提示。尤其當系統由原型階段投入實際營運後，應優先覆核含個人資料、登入資訊、私訊和驗證資料的資料表，並保留權限規則與測試結果的紀錄，方便日後追查改動來源。

下一步值得觀察的是，使用Supabase的開發團隊會否把RLS檢查、公開資料表盤點及角色權限測試制度化。UpGuard的掃描結果提醒業界，雲端平台能降低建立後端的門檻，但不會自動替每個專案判斷哪些資料應公開。對已上線產品來說，及早找出可公開讀取的敏感資料，通常比在事故後才逐一確認影響範圍更實際。