Supabase刚获100亿美元估值，研究人员就数出16326个人人可查的托管数据库

一万六千扇门，一个房东

在菲律宾，一个用来截获一次性验证码的SIM卡农场，后端是一个任何人都能查询的Supabase数据库。库里存着10万余条短信，其中95%是验证码；另有几千条普通网约车聊天记录，司机和乘客与这桩骗局毫无干系²。UpGuard发现，共有16326个由Supabase托管的数据库存在可从公网读取的数据表，这个项目只是其中之一；UpGuard称这项研究是同类研究中规模最大的一次↗^{1 2}。

泄露搭上了融资的东风

就在Supabase完成5亿美元F轮融资↗三个月后，这份统计出炉。该轮融资由GIC领投，投前估值100亿美元^{3 4}。驱动这轮融资的引擎与酿成泄露的引擎，是同一台机器：一年间，数据库创建量增长600%；新增数据库中，超过60%由某种AI工具创建³。如今，平台上已聚集近1000万开发者³。

默认安全，账单记在别人头上

首席信息安全官Bil Harmer表示，Supabase的项目“默认安全”，而“客户自行掌控项目的配置方式”¹。公司安全页面↗划出同一条界线：基础设施的安全由Supabase负责，行级安全策略、API密钥和访问控制的安全由客户负责⁵。问题恰恰出在Supabase自家文档↗里：文档写道，未启用RLS的数据表“可被任何持有授权的角色读写”；在既有项目中新建公开数据表，一开始就把全部权限授予全部三个角色，包括匿名角色⁶。据这项研究，RLS默认只覆盖在表格编辑器里创建的表，不覆盖通过API创建的表，而编程智能体建表走的正是API²。估值给速度定了价；记录中没有任何数字给泄露定过价。

数据表里存了什么

超过半数遭暴露的数据库带有个人数据特征：姓名、地址和电话号码，其中密码和身份验证令牌数量较少^{1 2}。美国一家代客泊车服务商暴露了约7.8万名客户的车牌号；一名为赴加拿大移民提供移居指导的教练，在近5000条记录中留下884个明文密码；某个非洲国家领事馆的数据库录有2.5万人，每人都有一个标注安置地点的字段²。此前几次规模更小的扫描也一再发现同样的问题，且规模逐次扩大²。

两个阵营，一笔没人买单的账

Supabase有充分的理由回应：配置不当的数据库早在AI之前就已存在；问题浮现时，公司会通知受影响的客户；其安全态势已通过SOC 2、HIPAA和ISO 27001认证^{1 5}。UpGuard通知的是应用所有者；被写进数据表里的当事人不在通知之列，记录中也没有任何数字为他们暴露的代价定过价²。UpGuard自己的算式点明了风险：泄露量，是一项技术容易被配错的程度与其用户规模的乘积²。盯紧下一轮扫描——它将决定16,326是峰值，还是基线。