当数据库的默认配置遇上不读文档的开发者，用户数据就成了一次公开的展览。
发生了什么
TechCrunch 报道称，部分使用 Supabase 的客户正在把大量用户数据公开暴露到 Web 上，任何人不经认证即可访问。报道将这一现象与 AI 生成、所谓“氛围编程”（vibe coding）产出的应用联系起来：这些应用在配置或安全加固不到位时，会把用户数据直接泄漏出去。
Supabase 本身是 Firebase 的开源替代方案，提供 Postgres 数据库、认证、存储和自动生成的 API，在独立开发者和 AI 编程工具链中流行度很高。它的卖点之一是开箱即用，但“开箱即用”与“开箱即安全”并不是同一件事。
为什么重要
这不是某个产品的孤立漏洞，而是一类开发范式的副作用。
过去，把数据库暴露在公网需要开发者主动犯错：写错权限、忘记加认证中间件。而现在，AI 编程助手能在几分钟内生成一套完整的“前端 + 数据库 + API”应用，开发者往往并不清楚生成的代码里，数据访问控制到底落在哪一层。Supabase 的行级安全策略（RLS）如果没被正确启用，表就可能对匿名密钥完全开放——而匿名密钥恰恰是要打包进前端、公开可见的。
换句话说，风险从“写错代码”转移到了“不理解代码”。当生成速度远超审查速度，安全默认值就成了最后一道防线，而这道防线在很多模板和教程里并不显眼。
影响与看点
对开发者而言，最直接的提醒是：使用 Supabase 这类 BaaS 时，RLS 不是可选项，而是上线前的必检项。用匿名密钥从外部尝试读取每一张表，应该成为发布流程的标准动作。
对 AI 编程工具和平台而言，这是产品责任的问题。工具在生成数据层代码时，是否默认开启访问控制、是否在检测到公开可读的表时给出警告，会越来越成为差异化能力。把安全默认值做对，比多生成几个页面更有价值。
对用户来说，这类事件再次说明：你在小众 AI 应用里填写的邮箱、订单、聊天记录，其保护水平可能远低于你的预期。
一个值得记住的判断是：AI 让构建应用的门槛降到历史最低，但让“安全地构建应用”的门槛几乎没有下降。这两条曲线之间的缺口，就是接下来一段时间里数据泄露新闻的主要来源。
