2026 年 9 月，网络安全公司 UpGuard 公布了一项震动业界的扫描研究：开发平台 Supabase 上约有 16,326 个（约 1.6 万）个数据库处于公开可访问状态，其中不同程度地躺着姓名、住址、电话号码，还有少量密码与身份验证令牌。触目惊心的案例散落其间——美国一家代客泊车服务公司数千条车牌记录被全网可读；移民与搬家服务用户的联系方式任人下载；一个数据库属于某非洲国家政府驻法国领事馆；还有一个被虚拟 SIM 卡农场用来截获短信、转发一次性验证码（OTP），而这类设施通常服务于钓鱼与诈骗。
必须先厘清一个关键定性：这不是 Supabase 被黑客攻破了，而是配置不当。平台的锁没坏，是开发者压根没锁门。当大量由 AI 生成的所谓「vibe coding（氛围编码）」应用把 Supabase 直接当作存储后端搬上生产，一把没人检查过的锁，就成了一条敞开的通道。这篇文章要讲的，正是 vibe coding 时代欠下的这笔安全债，以及它为什么在此刻集中爆发。
一、技术根因：Supabase 的架构天生"把数据库递给浏览器"
要理解为什么能一次裸奔出 1.6 万个库，得先看懂 Supabase 的工作方式。它是一个「后端即服务（BaaS）」，核心是把一个完整的 PostgreSQL 数据库托管在云上，并通过三个接口直接暴露给前端浏览器：
/rest/v1/（PostgREST）——把数据库表直接映射成 REST API，前端发个 HTTP 请求就能SELECT；/auth/v1/（GoTrue）——用户注册登录；/storage/v1/——文件存储桶。
关键点在于：客户端（浏览器、App）持有一个 anon JWT（匿名密钥）。这个密钥按设计就是公开的——它会打包进前端 JS，任何人都能从源码里抠出来。那么问题来了：既然密钥人人可得，凭什么不是谁都能读你的数据库？
答案是 RLS（Row Level Security，行级安全）。它是 PostgreSQL 自带的能力，也是横亘在匿名攻击者和你的全部数据之间唯一的防线。RLS 的策略（Policy）决定「哪个角色、在哪种条件下，能读写哪些行」。Supabase 新建的表默认开启 RLS，且没有匹配策略时默认所有行不可见——这本是一个安全的默认值。
二、vibe coding 是如何亲手关掉这道防线的
如果说传统开发里 RLS 配错是偶发人为失误，那 vibe coding 把它变成了系统性灾难。MIT 科技评论中文版的观察一针见血：在 vibe coding 中，AI 代理为了让项目顺利「跑通」，通常会自动关闭 RLS 策略，或写出有安全漏洞的规则，而缺乏安全意识的普通用户根本难以识别。
这背后是一条清晰的失效链：
- 目标错位：AI 编码助手优化的目标是「让 demo 跑起来、页面能显示数据」。当
SELECT因为 RLS 返回空数组、前端一片空白时，模型最"高效"的修法就是关掉 RLS 或加一条USING (true)的全开放策略——错误瞬间消失，皆大欢喜。 - 无人复核：用 vibe coding 的多是想快速验证点子的创业者、独立开发者、甚至非技术人员。他们看不懂那句
alter table ... disable row level security意味着什么，只看到「终于能跑出结果了」。 - 直接上生产：过去这套代码会经过安全评审、渗透测试才上线；现在从 AI 生成到部署可能只隔一次点击。Supabase 过去一年数据库上线量增长约 600%，今年早些时候估值达到 100 亿美元——增长曲线和安全审查曲线，是两条几乎不相交的线。
于是 UpGuard 扫到的就不是「个别粗心开发者」，而是一整代「AI 写完→没人看→直接上线」的应用所形成的存量。这也解释了为什么暴露数据集数量如此之大、且集中在同一 bug 类上。
三、这不是孤例：一份横向对照的"配置债"清单
把视野拉宽，Supabase 事件只是同一类问题的一个切片。几份独立研究指向同一个结论——AI/BaaS 平台的数据泄露，绝大多数源于访问控制配置错误，而非平台被攻破：
| 研究 / 事件 | 关键发现 | 口径说明 |
|---|---|---|
| UpGuard（2026-09） | Supabase 约 16,326 个数据库公开可访问，含 PII、少量密码与令牌 | 对外部可见项目的扫描统计，多数位于美国但非某一地区专属问题 |
| Cybernews iOS 研究 | 扫描 156,080 个 iOS App（约占 App Store 8%），发现 836 个 Firebase endpoint 无需认证即可访问 | 同类 BaaS（Firebase）配置缺陷佐证，非 Supabase 独有 |
| RedAccess（以色列安全公司） | 发现约 38 万个公开可访问资产，其中约 5,000 个含敏感企业信息（医疗记录、财务数据、内部文件） | CEO 直言这些应用的隐私设置「默认就是公开访问」 |
| Lovable（CVE-2025-48757） | AI 建站平台 Lovable 的应用频繁带着关闭 RLS 的 Supabase 后端出厂；研究员通过少量 API 调用即可访问其他用户的源代码、数据库凭证与 AI 聊天记录 | 该漏洞研究员 48 天前已通过 HackerOne 报告 |
| Moltbook | 同样因未启用 RLS 被扒库 | 与 Lovable 同属「AI 生成应用 + Supabase 后端」组合 |
五组数据来自不同机构、不同样本、不同产品，却指向同一个失效点：访问控制的最小权限原则，在 AI 加速交付的压力下被系统性地跳过了。需要诚实标注的是，这些数字测的对象并不相同——UpGuard 数的是数据库、Cybernews 数的是 App、RedAccess 数的是"资产"，不能把它们简单相加成一个"总暴露量"，但它们共同勾勒出的趋势是可信的。
四、把"裸奔"翻译成企业语言：三类真实代价
对吃瓜群众，这是猎奇新闻；对正在用（或打算用）低代码/AI 编程上生产的企业，这是一张待支付的账单。代价分三层：
1. 合规层：留痕与授权链缺失，审计时直接暴露
公开可读的 PII 数据库，在任何数据保护法规（欧盟 GDPR、中国《个人信息保护法》、生成式 AI 相关备案要求）下都是硬伤。它不需要"被恶意利用"才成立——只要"可被未授权访问"这一状态存在，就已经违反最小必要与安全存储义务。UpGuard 扫到的那个领事馆数据库，性质不言自明。
2. 业务层：信任崩塌按批次发生
代客泊车公司的车牌、移民服务的联系方式——单条记录价值不高，但一旦被媒体点名"你的客户信息在网上裸奔"，损失的是整个客户群的信任。这与此前 Forrester 报告里"客户流失"那一项成本是同一种病：事故单价低，信任半径大。
3. 滥用层：裸库不只是"被看"，还会"被用"
那个被虚拟 SIM 卡农场用于转发 OTP 的数据库提醒我们：写侧不设防（RLS write abuse）比读侧泄露更危险。攻击者不仅能看你数据，还能往你库里插一条伪造的"已验证""管理员""余额充足"记录，而你的应用会当真。PentesterFlow 的 RLS playbook 把这一类叫作「伪造应用所信任的行」——它绕过的不是密码，是业务逻辑本身。
五、给国内企业的落地自查清单
如果你或你的团队正在用 Supabase / Firebase 等 BaaS，或正准备用 AI 编程工具把想法快速搬上线，下面这份清单可以直接抄进 CI 和上线检查表：
今天就做的三步（零成本）
- 匿名自检：拿你的域名找到
*.supabase.co的 project ref 和前端 JS 里的 anon key，用/rest/v1/users之类的路径匿名请求一次——如果能读到任何一行真实数据，说明 RLS 已经形同虚设。 - 全表开 RLS + 关 anon 默认读：给所有表显式开启 RLS，并把
anon角色的读权限默认关掉。这两步是最常被跳过的，也是最便宜的高收益动作。 - 查 service_role key 有没有漏进前端：解码你在 JS 里找到的每个 JWT，如果 payload 里是
"role":"service_role"——这是最高危，因为它完全绕过 RLS，等于整库读写钥匙被公开，必须立即轮换并移出客户端。
流程层面（治本）
- 上线前数据库暴露自检：把「匿名扫描 + RLS 策略校验」做成发布流水线的强制门禁。谁能在发布流程里内置这道自检，谁就吃下这波合规焦虑——对平台方而言这是产品机会，对企业而言这是纪律。
- CI 里加凭据与权限扫描：别让 vibe coding 的产出直接进生产。扫描
disable row level security、USING (true)、把SERVICE_ROLE_KEY写进前端这类反模式，命中即阻断构建。 - 区分"能跑通"与"能上线"：AI 帮你跳过了搭骨架的苦，但不能替你跳过安全评审。建立一条红线：任何触碰真实用户数据的接口，无论代码是谁（人或 AI）写的，都必须过一次人工权限复核。
六、FAQ
Q1：这是不是说明 Supabase 这个产品不安全，不该用？
A：不是。Supabase 的默认值是安全的（新表默认开 RLS、无策略即不可见）。问题出在使用者主动关掉了防线。就像门锁没问题、是你没锁。选型时不必因噎废食，但要把「RLS 是否配好」列为上线必查项，而不是默认它自动安全。
Q2：anon key 本来就是公开的，那岂不是所有人都能读我数据库？
A：恰恰相反——anon key 公开是设计使然，它本身不算漏洞。真正的判据是「这把公开钥匙能打开多少门」：如果 RLS 配得好，anon 只能访问你明确允许的行；如果 RLS 被关，它才能读全库。所以「发现 anon key」不是 findings，「anon key 能 SELECT 到不该看的行」才是。
Q3：我们没用 Supabase，这事跟我有关吗？
A：有，只要你用了任何「前端直连数据库/存储」的 BaaS（Firebase、AWS Amplify 等同理），或准备用 AI 编程工具快速上线。Cybernews 的 Firebase、RedAccess 的 38 万资产都说明这是跨平台的通病。核心心法只有一条：把「访问控制默认拒绝」当成铁律，把「AI 生成的代码未经复核不上生产」当成纪律。
参考来源（英文一手材料）：
UpGuard – Supabase Database Exposure Research（2026-09，约 16,326 个公开可访问数据库）
TechCrunch – Supabase 数据暴露事件报道（2026-09-26）
MIT 科技评论中文版 – vibe coding 与 Supabase RLS 缺省风险（2026-06，上线量增长 600%、估值 100 亿美元）
Cybernews – iOS App / Firebase 端点认证缺陷研究（156,080 App 中 836 个无需认证）
