风险管理公司 UpGuard 披露，超过 16000 个 Supabase 数据库因配置错误导致数据表可被公开读取，泄露内容包含个人身份信息、明文密码与认证令牌。根因并非 Supabase 软件漏洞，而是开发者未正确启用行级安全策略（RLS）并误用公开密钥。
事件概述
UpGuard 从约 30 万个疑似使用 Supabase 的域名入手，逐一探测是否存在 users 表或同义表，再用表结构反推所暴露的数据类型。结果显示，超过一半的暴露数据库中可读到 PII，其中一部分还包含密码与认证令牌。研究方指出，AI 辅助开发目前已占新建 Supabase 数据库的六成以上，配置漂移与此直接相关，但扫描无法证明每一个受影响站点都由 AI 编码代理生成。
技术细节
Supabase 是基于 PostgreSQL 的后端即服务方案，其访问控制依赖开发者显式编写 RLS 策略。若跳过这一步，默认行为可能让数据表对任何知道数据库端点的人开放读取。研究还发现公开密钥（anon key）被误用的情形——该密钥本身设计为可暴露，但前提是 RLS 已正确配置；一旦 RLS 缺失，公开密钥就成了直通数据的钥匙。此类暴露没有漏洞编号，也没有补丁可打，只能由开发者自行修正配置。
影响评估
已确认的案例覆盖多个行业与地区：美国一家代客泊车服务泄露超 10 万条客户记录，含联系方式、车牌与到访历史；加拿大一家移民服务机构近 5000 条用户记录外泄，其中 884 条为明文密码；印度某创作者平台泄露身份信息、收款账户与 10 万条以上私信；菲律宾一家短信验证码服务暴露 2000 余名用户资料与 10 万条短信，其中混入大量点对点私人通信；某非洲国家领事馆 2.5 万条记录暴露，含住址与紧急安置地点。认证令牌泄露意味着攻击者可直接冒用会话、绕过登录接管账户；明文密码会被用于撞库。研究方称，仅有极少数暴露库疑似含信用卡数据。
修复建议
- 立即审计所有含敏感数据的表，确认 RLS 已启用且策略按登录身份正确限权。
- 未配置 RLS 的表应视为已公开，在策略落地并验证前不要存放敏感数据。
- 收紧公开密钥使用范围，敏感操作一律走带鉴权的服务端接口。
- 复查表级授权（GRANT）与视图定义，避免存在绕过 RLS 的读取路径。
- 把 RLS 检查纳入发布清单，参考 Supabase 安全顾问与 API 安全指南做基线核查。
- 若曾在暴露库中存储令牌或密码，立即轮换凭据并通知受影响用户。