```
Security researchers have identified more than 16,000 misconfigured Supabase databases left publicly accessible, creating a sprawling landscape of exposed sensitive data. The findings, reported by BleepingComputer, point to a pattern of developers carrying permissive development-time settings into production without applying the platform's built-in security controls.
The exposed instances contained readable personally identifiable information, hashed passwords, and authentication tokens. Researchers attributed the scale of the problem not to a flaw in Supabase itself, but to a persistent gap between rapid prototyping defaults and the hardened configurations required for production deployments.
Supabase, an open-source Backend-as-a-Service platform built on PostgreSQL, ships with permissive defaults intended to lower the barrier for new projects. That convenience becomes a liability when developers deploy to production without explicitly tightening access controls. Three misconfigurations emerged as the most common and consequential across the affected databases.
Row-Level Security left disabled. PostgreSQL's Row-Level Security (RLS) feature allows developers to write granular access policies that restrict which rows a given user can read or modify. In Supabase's default configuration for new projects, RLS is off, meaning any authenticated or even anonymous request can reach every row in a table. Researchers found thousands of instances where RLS was never activated, leaving databases fully open.
Anonymous API access left unrestricted. Supabase assigns a default anon role for client-side operations. Without strict RLS policies backing it, that role effectively grants unauthenticated users broad read access to backend data. The researchers observed that many of the exposed databases had no guardrails on this endpoint, turning a development convenience into a data scraping vector.
Admin credentials left in the open. The platform's service_role key and direct database connection strings carry near-full administrative privileges. In multiple cases, researchers found these secrets committed to public version control repositories or embedded in client-side code — a fundamental credential hygiene failure.
The findings underscore the shared responsibility model that governs cloud and BaaS deployments. Supabase provides the security tooling; activating it remains the developer's obligation. The sheer volume of exposed databases — over 16,000 — suggests this is less a knowledge gap than a process failure, where deadline pressure and speed-to-market incentives repeatedly override essential configuration steps.
Remediation is neither complex nor novel. Supabase's own documentation covers each of these controls in detail. The challenge, according to security practitioners, lies in treating these steps as non-negotiable parts of the deployment pipeline rather than optional afterthoughts. Automated scanning in CI/CD workflows to detect missing RLS policies, open anonymous endpoints, and leaked credentials can catch misconfigurations before they reach the public internet.
For development teams handling personal data — particularly in jurisdictions with strict data protection requirements — the researchers' findings serve as an immediate call to action. The exposed databases represent a preventable failure, and the tools to prevent it already exist within the platform.
保安研究人員已識別出超過16,000個配置不當的Supabase數據庫被公開存取，形成了大規模的敏感數據暴露面。據BleepingComputer報道，此發現指向一種模式：開發者將寬鬆的開發環境設定直接帶入生產環境，而未應用平台內建的安全控制措施。
這些暴露的個案包含可讀的個人身份資料、經雜湊處理的密碼及認證令牌。研究人員指出，問題的規模並非源於Supabase本身的缺陷，而是源於快速原型開發的預設值與生產部署所需強化配置之間的持續差距。
Supabase是一個基於PostgreSQL的開源後端即服務（BaaS）平台，其出廠時採用寬鬆的預設值，旨在降低新項目的入門門檻。然而，當開發者在部署至生產環境時未明確加強存取控制，此便利性便轉化為隱患。在受影響的數據庫中，有三類配置錯誤最為常見且影響深遠。
行級別安全性（RLS）處於停用狀態。 PostgreSQL的行級別安全性功能允許開發者撰寫精細的存取策略，限制特定用戶可讀取或修改的資料列。在Supabase新項目的預設設定中，RLS是關閉的，這意味著任何已認證甚至匿名的請求都能存取資料表中的每一列。研究人員發現數千個個案從未啟用RLS，導致數據庫完全開放。
匿名API存取未受限制。 Supabase為客戶端操作指派一個預設的anon角色。若缺乏嚴格的RLS策略支持，該角色實際上授予了未認證用戶對後端數據的廣泛讀取權限。研究人員觀察到，許多暴露的數據庫在此端點上毫無防護，使開發便利功能變成了數據抓取的媒介。
管理員憑證被公開置放。 該平台的service_role金鑰及直接的數據庫連接字串擁有近乎完整的管理員權限。在多個案例中，研究人員發現這些機密資訊被提交至公開的版本控制儲存庫或嵌入客戶端程式碼——這是基本的憑證管理失誤。
此發現凸顯了雲端及BaaS部署所遵循的共同責任模式。Supabase提供安全工具；而啟用這些工具仍然是開發者的責任。如此龐大的數據庫暴露數量——超過16,000個——表明這與其說是知識缺口，不如說是流程缺陷。在這種情況下，截止日期壓力和快速上市的激勵措施，一再壓過了必要的配置步驟。
補救措施既不複雜也不新穎。Supabase自身的文件已詳細涵蓋每一項控制措施。根據安全從業人員的說法，挑戰在於將這些步驟視為部署管道中不可或缺的部分，而非可選的補充措施。在CI/CD工作流程中進行自動化掃描，以檢測缺失的RLS策略、開放的匿名端點及洩露的憑證，可以在配置錯誤進入公網之前將其攔截。
對於處理個人資料的開發團隊——尤其是在有嚴格數據保護法規的司法管轄區——研究人員的發現是一項立即的行動號召。這些暴露的數據庫代表了一次本可避免的失誤，而預防它的工具已存在於平台之內。