估值刚刚站上 100 亿美元的开源后端平台 Supabase，正被卷入一场波及全网的数据暴露风波。根据 TechCrunch 报道，网络安全公司 UpGuard 指称该平台上托管的约 16,000 个数据库直接向公网敞开，泄露内容涵盖姓名、密码哈希、身份令牌，乃至领事馆往来邮件与短信接码记录。面对指责，Supabase 首席信息安全官 Bil Harmer 坚称底层平台默认安全，将事故归咎于用户的权限配置失误，称这是典型的“责任共担”。
这并不是一起黑客攻破云端内网的传统渗透事件，更不是前端代码泄露了机密私钥。它的本质是自然语言辅助编程（Vibe Coding）带来的繁荣假象：当非专业开发者依赖大模型在几小时内拼凑出全栈应用，Supabase 直连数据库的架构设计直接抹平了传统后端防火墙，让缺乏行级权限保护的数据库在互联网上静默裸奔。
迷雾下的数字：16000 个暴露源自何处
报道中提及的约 16,000 个数据库暴露，在数据溯源上存在显著的放大痕迹。公开核查表明，截至 2026 年 9 月 15 日，UpGuard 官方对 Supabase 给出的安全评级维持在 B 级（755 分），但在其公开研究库中并未检索到题为 Everything Everywhere 或明确列举出 16,000 个暴露实例的独立技术白皮书。历史上这一规模特征，与 2017 年 1 月爆发的 MongoDB 未授权访问及勒索攻击事件数据高度重合，外媒报道很可能杂糅了历史扫描数据或第三方探测器的汇总结果。
然而，统计口径的疑点丝毫不能淡化现实漏洞的严重性。多项来自一线渗透测试机构的抽样调查，还原了更为惊人的真实暴露面：
安全机构 ModernPentest 对 71 家采用 Supabase 的 Y Combinator 初创公司进行了渗透测试，在暴露的 20,118,887 行数据中，仅有 39%（28 家）配置了完善防护，多达 8 家初创团队直接将密码哈希与支付凭证暴露给公网。另一家工具方 LaunchGuard 对 96 个线上应用的实测同样显示，42% 的项目允许匿名访问邮箱、个人资料及账单，直接流出 237 万条记录。数字或有出入，但大批采用该平台的应用正在失控却是不争的事实。
致命的误解：anon key 是标识，RLS 才是命门
很多初创团队在事发后陷入恐慌，误以为是前端代码里的 anon key（匿名密钥）泄露引发了灾难。这种技术误解掩盖了更致命的架构风险。
在 Supabase 的体系中，anon key 从设计之初就不是保密凭证，而是客户端向 PostgREST API 声明身份的公共通行证，必须打包进前端文件。系统真正依赖的安全防线，是底层 PostgreSQL 的行级安全机制（Row Level Security, 简称 RLS）。
在传统全栈工程中，数据库被严密包裹在应用服务器后方，无论接口写得多糟糕，外界都无法直接发起任意 SQL 查询。但 Supabase 将强大的关系型数据库搬到了浏览器面前。开发者只要在后台勾选创建数据表，该表就会自动映射为公网接口。
此时，如果开发者忘记开启 RLS，或者为了调试方便随手写入 USING (true) 这样全量放行的宽泛规则，客户端就能通过合法的 anon key，轻而易举地把整张数据表拖回本地。
代码能跑通不代表防护有效，BaaS 架构正在剥离安全工程师最后的容错垫。
在一项针对 1,072 个 AI 辅助构建应用的学术扫描中，98% 的应用存在安全缺陷。AI 编程工具偏爱最少阻力路径，为了让界面迅速展示出动态数据，大模型往往会指导用户关闭权限拦截，或自动生成毫无过滤能力的放行规则。没有任何安全背景的独立创业者，误以为功能上线即大功告成，丝毫未察觉底层大门早已洞开。
责任共担的黄昏：从宽松开放到被迫锁死
平台方长期奉行的责任共担模型，正在遭遇技术范式变革的冲击。在专业工程师时代，平台提供底层基座、开发者配置访问规则是行之有效的商业契约。但在全民靠提示词编程的周期里，复杂的数据库权限管理对非专业人员构成了巨大的认知陷阱。
横向对比同类产品，各家的安全权衡截然不同：
| 平台方案 | 权限基线 | API 暴露机制 | 针对小白的安全约束 |
|---|---|---|---|
| Supabase (历史) | 依赖表级 RLS | 建表默认挂载公网 API | 极低，完全依赖手动配置 SQL 规则 |
| Firebase | 规则引擎判定 | 显式强制模式切换 | 提供 Locked / Test 模式，超时强制告警 |
| Appwrite | 默认拒绝 (Deny-by-default) | 必须显式声明文档角色 | 默认禁止外部一切读写，强制授权 |
面对愈演愈烈的泄漏事件，Supabase 不得不打破过往对极简开发的妥协，启动强硬的 Breaking Change 纠偏机制。平台自 2026 年 5 月 30 日起，调整了新项目的安全默认项，新创建的数据表默认不再自动接入公网 Data API；而针对存量老项目的强制隔离节点，则被硬性划定在 2026 年 10 月 30 日。
- 提醒.所有正在运行 Supabase 的团队必须在 10 月底前全面核查数据表属性与 RLS 规则，否则在存量项目强制收紧后，将面临接口断流或关键数据持续裸露的双重代价。
这一调整宣告了开箱即用与绝对自由的平衡期终结。当自然语言将软件生产的门槛砸碎，基础设施服务商必须意识到：不能再假设敲击键盘的是一名熟读安全手册的资深工程师。如果底层架构不能做到默认阻断，那么高效的 AI 工具产出的就不是生产力，而是成倍膨胀的安全债务。