安全
16,326 个 Supabase 数据库任何人都能读取。共同点是一张由智能体创建的表
UpGuard 发现了 16,326 个基于 Supabase 的数据库,其数据表可被公开互联网上的任何人读取,其中半数以上含有个人数据。没有发生入侵——真正的成因是一项默认设置,它适用于编码智能体走的那条路径,而不是人走的那条。
MAI
安全公司 UpGuard 于 9 月 25 日发布研究,称已确认 16,326 个基于 Supabase 的数据库,其数据表可被公开互联网上的任何人读取。其中半数以上含有真实个人的信息:姓名、出生日期、电子邮箱、电话号码、居住地址。另有一小部分含有明文密码和身份验证令牌。
没有人闯进去。不存在漏洞,没有补丁,也没有 CVE 编号。这些数据库无一例外都在严格按照自身配置的指示运行。这正是本事件区别于又一起数据泄露事件之处:失败是系统性的,而且它是一项默认设置。
处于问题核心的那项配置
Supabase 为每个项目提供一个托管的 Postgres 数据库,并在其前面放置一层 REST 接口。运行在访客浏览器中的客户端代码携带一把 Supabase 称为 anon 的密钥。它本就设计为公开。它只用于标识项目,别无他用,Supabase 的文档也是这样写的。
阻止这把公开密钥变成万能钥匙的,是行级安全(RLS)——Postgres 中决定某个角色可以看到哪些行的功能。启用 RLS 并写好策略后,匿名访客只能看到策略允许的内容。关闭 RLS 时,暴露 schema 中的数据表便可被任何提出请求的人读取,Supabase 自己的文档对此说得很明白。
UpGuard 的论点是,这套机制的两半已经脱节。对于通过 Table Editor 界面创建的表,Supabase 默认启用 RLS;而通过 API 以程序方式创建的表并不继承同样的默认值——偏偏程序化创建正是编码智能体构建 schema 的方式。
「Supabase 如今已处于这样一个大规模普及的阶段:不安全的配置模式会导致系统性的数据暴露。」报告作者、UpGuard 研究与洞察总监 Greg Pollock 写道。
里面究竟装着什么
UpGuard 表示,它分析了约 30 万个带有 Supabase 特征的域名,并在不完整读取数据库的前提下评估了数据类型。报告点名的案例,除了技术栈之外毫无共同之处。
| 运营方 | 暴露的内容 |
|---|---|
| 菲律宾的一处 SIM 卡农场 | 2,000 多个用户账户与 10 万余条短信 |
| 美国的一家代客泊车服务商 | 10 万多名客户,含车牌号与到访记录 |
| 一家印度平台 | 65,467 人,含私人对话 |
| 加拿大的一家移居服务机构 | 约 5,000 条记录,含凭据 |
| 某非洲国家驻法国领事馆 | 申请人记录 |
SIM 卡农场和领事馆不是同一类组织,面对的攻击者不同,对「什么算秘密」的理解也不同。可它们还是犯了同一个错。Pollock 对原因的概括,是全篇最锋利的一句:
「安全设置之所以不随业务类型而变化,是因为那些人……并不理解自己数据库的配置。」
与 AI 有关的那一部分
人们很容易把这件事归入开发者疏忽然后翻篇。更有用的读法,是去问现在究竟是谁——或者说什么——在编写 schema。
一个被要求构建应用的 AI 编码智能体,会通过 API 创建数据表,因为那是它可用的接口;它会把 anon 密钥接入客户端,因为文档就是这么写的。这两步单独看都没错。没有发生的那一步,是从一开始就不在提示词里的那一步:逐表判断「谁应当被允许读取这些内容」。换成一个人在控制台里构建同一个应用,他会拿到安全的默认值。机器走的是另一条路。
这正是当下一整类问题的形状。安全默认值的设计前提,是一个人坐在控制台前,看到警告,然后点击某处。智能体不坐在控制台前。当安全的默认值存在于界面而非数据库之中时,自动化就会绕过它——并且是以自动化的速度和规模绕过。
Supabase 的说法
Supabase 首席信息安全官 Bil Harmer 对 TechCrunch 表示,「我们的项目默认是安全的」,并将安全描述为公司与客户之间的共同责任。他说:「我们非常在意把这件事做对,并将继续让每一位开发者都更容易安全地交付。」
这两件事可以同时成立。在 Supabase 为人设计的那条路径上,默认值是稳妥的。暴露发生在机器走的那条路径上,而 16,326 个数据库这个数字,撑不起「用户教育问题」这样的说法。
如果你手上正有这样一个项目
需要检查的是:暴露 schema 中的每一张表是否都启用了 RLS。Supabase 的文档明确指出,仅仅启用 RLS 并不够——还必须撤销自动授予 anon 与 authenticated 角色的权限。未受保护的表会在项目控制台中以警告形式列出,那份清单就是起点。
先看那些没人记得自己创建过的表。以目前的证据判断,它们多半出自智能体之手。
UpGuard 称,已就研究中发现的重大暴露通知了相关所有者。而对于那些姓名、住址和密码被放进这些表里的人来说,这条通知是他们曾经拥有过的唯一控制手段。
Sources: UpGuard — Everything, Everywhere: Systemic Data Exposure in Supabase Apps · TechCrunch — Some Supabase customers are publicly exposing reams of people's data to the web · Supabase documentation — Row Level Security · Unite.AI — UpGuard Study Finds 16,326 Supabase Databases Exposing Readable Tables