AI 造 App 曝出数据泄露潮：Supabase 配置错误让用户数据裸奔

9 月 25 日，多款使用 AI 编程工具和“vibe coding”方式生成的应用被发现存在严重的数据暴露问题：开发者将 Supabase 数据库直接接入生产环境，却没有正确配置访问策略，导致用户资料、认证令牌、私密消息甚至财务和医疗相关信息可以被未经授权的第三方读取。

这不是某一个应用的孤立事故，而是 AI 生成应用快速扩张后集中暴露出的工程问题。应用的界面可以在几分钟内生成，数据库也可以一键接入，但权限模型、数据隔离、密钥管理和上线前审计，仍然不会因为代码是 AI 写的就自动完成。

发生了什么：数据库能用，但不该被所有人读取

Supabase 是一个开源风格的后端即服务平台，为应用提供托管 PostgreSQL 数据库、用户认证、文件存储和实时数据同步能力。它的优势是开发者可以不搭建服务器，直接通过前端应用连接数据库，因此非常适合 AI 编程工具批量生成原型和小型产品。

问题在于，Supabase 的“能连接”不等于“访问安全”。开发者必须通过 Row Level Security（RLS，行级安全策略）限制不同用户能够读取和修改哪些数据。如果 RLS 没有开启，或者策略写成了允许所有人的规则，前端应用拿到的公开访问配置就可能成为读取整张数据表的入口。

这次事件中，安全研究人员发现，一些 AI 生成应用的 Supabase 项目允许未经身份验证的访客直接读取生产数据库，部分项目甚至保留了写入权限。攻击者不需要入侵服务器，也不需要破解复杂的身份认证，只要找到应用使用的公开接口并发送正常的数据请求，就可能浏览、下载或修改数据库内容。

从工程角度看，这属于典型的访问控制失效：系统验证了“请求格式是否正确”，却没有验证“发起请求的人是否有权访问这条数据”。

数据暴露到什么程度

目前公开信息显示，受影响应用中的数据类型并不局限于测试数据。一些暴露内容包括用户邮箱、账户资料、应用内部消息、AI 代理的认证令牌，以及能够改变公开内容的数据库记录。

此前，AI 代理社交平台 Moltbook 就曾暴露出类似问题。该产品大量依赖 AI 生成代码，安全研究机构 Wiz 发现其 Supabase 数据库存在完整的读写访问风险。公开报道提到，暴露数据包括约 150 万个 API 认证令牌、约 3.5 万个邮箱地址，以及大量 AI 代理之间的私密消息。

一旦认证令牌仍然有效，攻击者就不只是“看到了数据”，还可能冒充用户或 AI 代理执行操作，例如发布内容、修改资料、调用第三方服务，甚至进一步访问关联账户。对于包含 OAuth 凭证、支付信息或企业内部资料的应用，这种风险远高于普通的数据库误配置。

| 暴露类型 | 可能造成的后果 | 风险等级 | |---|---|---| | 用户邮箱、姓名、个人资料 | 垃圾邮件、钓鱼攻击、身份关联 | 中高 | | 私信、客服记录、工作内容 | 隐私泄露、商业机密外泄 | 高 | | API 认证令牌、OAuth 凭证 | 冒充用户、调用第三方服务 | 严重 | | 数据库写入权限 | 篡改内容、删除数据、植入恶意信息 | 严重 | | 医疗、财务和支付数据 | 合规处罚、诈骗和直接经济损失 | 严重 |

更值得警惕的是，不少应用的前端表现并不粗糙。它们拥有完整的登录页面、现代化的视觉设计和流畅的交互，甚至能在搜索引擎中正常收录。用户很难仅凭页面判断后端是否经过安全加固。

这不是 Supabase 的数据库密钥泄露

需要区分一个经常被误解的概念：Supabase 的匿名公开密钥本身并不等于管理员密钥。

Supabase 的 anon key 设计目标是允许前端应用访问数据库服务。它可以出现在浏览器代码中，真正决定数据是否安全的是数据库权限策略和 RLS 配置。相反，service_role key 具备绕过部分安全策略的高权限，原则上不应出现在浏览器端，更不能被提交到公开代码仓库。

换句话说，很多事故并不是“黑客偷走了一个本来不该公开的密钥”，而是应用把一个本来可以公开使用的访问入口，连接到了没有权限隔离的数据库。

这也是 AI 编程工具最容易掩盖的风险。模型可以生成连接 Supabase 的代码，也可以生成登录和数据查询逻辑，但它通常无法知道某张表里存放的是测试数据、用户隐私还是企业机密。更关键的是，模型生成的代码即使语法正确，也不代表权限策略符合真实业务场景。

AI 编程为什么会放大这个问题

AI 编程降低了写代码的门槛，却没有同步降低软件安全的复杂度。

传统开发流程中，数据库设计、身份认证、权限模型和上线检查通常由多名工程师共同完成。代码进入生产环境前，还会经过代码审查、自动化测试、依赖扫描和安全评估。AI 生成应用则往往采用另一种路径：用户描述需求，工具生成页面，自动创建数据库，再一键发布。

这种流程的关键缺口是“可运行性”被放在了“可负责性”之前。只要页面能打开、用户能注册、数据能写入，应用就会被判断为完成。但安全问题通常藏在默认值和边界条件里：

• 用户 A 是否能够查询到用户 B 的记录；
• 未登录用户是否能读取整张表；
• 普通账号能否修改管理员字段；
• 删除操作是否限制在当前用户自己的数据范围内；
• 管理员密钥是否被打包进前端 JavaScript；
• 测试数据库是否被直接当成生产数据库使用。

这些问题没有一个能通过“页面看起来正常”得到答案。

公开社区中已经出现更大规模的扫描结果。一份针对约 2 万个 vibe coding 应用的社区扫描讨论称，约九分之一的应用暴露了数据库密钥或相关配置。不过，这类统计通常依赖特定扫描规则，不能直接等同于九分之一应用都发生了真实数据泄露。它更适合作为趋势信号：大量应用正在重复使用相同的模板、默认配置和自动生成的后端结构，因此同一种错误可以被批量复制。

平台也不能把责任全部推给用户

把问题简单归结为“开发者没有正确配置权限”并不完整。

如果一个平台的核心卖点是“不需要懂代码，也能做出并发布应用”，那么它就必须为最容易出错的环节提供更强的默认保护。对于缺乏数据库经验的用户来说，RLS、匿名角色、service_role、跨租户数据隔离等概念并不属于合理的使用前提，而是平台应该主动处理的风险。

至少有几项能力应当成为 AI 应用生成平台的默认配置：

1. 新建数据表默认启用 RLS，而不是默认允许匿名访问。
2. 发布前自动扫描数据库策略，并明确展示“未登录用户可以读取哪些数据”。
3. 检测 service_role key、数据库密码和第三方令牌是否进入前端代码或公开仓库。
4. 为涉及邮箱、手机号、医疗、支付和身份信息的字段提供敏感数据提醒。
5. 在公开部署前运行跨用户访问测试，验证用户 A 无法读取用户 B 的数据。
6. 对批量导出、删除和写入操作增加速率限制、审计日志和人工确认。

尤其是发布按钮前的安全检查，不应只显示“部署成功”。用户更需要看到的是：“当前数据库有 3 张表允许未登录用户读取，其中 1 张包含邮箱字段。”这类提示比一段泛泛的安全文档更有用。

开发者现在应该检查什么

已经使用 AI 编程工具搭建应用的开发者，应优先检查数据访问边界，而不是继续优化页面样式。

第一步是确认数据库中到底存了什么。把测试数据、用户资料、认证令牌和内部配置分开盘点，删除不再需要的敏感数据。任何不清楚用途的表、字段和存储桶，都不应继续保持公开访问。

第二步是检查 RLS 是否启用，以及每条策略到底允许谁做什么。不要满足于控制台中的“已启用”状态，还要用普通用户、未登录用户和管理员账号分别测试读取、插入、更新和删除操作。

第三步是检查前端构建产物。搜索公开 JavaScript 文件、Git 仓库和部署日志中是否出现 service_role key、数据库密码、OAuth refresh token 或其他长期凭证。只要高权限凭证曾经进入前端，就应立即撤销并重新生成，不能只删除代码后继续使用原密钥。

第四步是检查多租户隔离。对于协作工具、客服系统和 AI 工作区，数据表通常带有 user_id、team_id 或 organization_id 字段。安全策略必须强制把查询范围绑定到当前登录身份，不能只依赖前端传入的 ID。

第五步是准备事故响应。发现暴露后，应立即暂停高风险接口、撤销令牌、修改数据库策略、保存访问日志，并通知受影响用户。单纯把项目改成私有，无法消除已经被下载的数据，也无法让已经泄露的凭证失效。

真正的问题是“软件责任”被重新分配

这次 Supabase 配置错误暴露的核心，并不是 AI 会不会写代码，而是谁来承担软件上线后的责任。

AI 生成工具把原本需要数天完成的原型压缩到几小时，甚至几分钟。它确实让更多人能够验证想法，也让小团队可以用较低成本做出过去需要专业团队才能完成的产品。但当应用开始收集陌生用户的数据时，它就不再只是个人实验，而是一项需要承担安全责任的线上服务。

“能跑”只是产品开发的起点，“能安全地让别人使用”才是上线标准。

对于开发者而言，AI 生成代码应当被视为未经审查的初稿，尤其是认证、权限和数据存储部分。对于平台而言，不能一边用“人人都能开发”吸引用户，一边把数据库安全知识作为事故发生后的免责条件。AI 时代真正需要降低的，不只是写代码的门槛，还包括正确配置安全边界的门槛。

这轮暴露事件的影响可能还没有结束。随着越来越多 AI 工具自动创建数据库、接入支付和处理企业资料，同类问题会从个人项目扩展到 SaaS、客服、教育和医疗场景。未来应用竞争的分水岭，不会只是生成速度和界面质量，也会是平台能否在用户点击“发布”之前，明确告诉他：哪些数据正在被谁访问，以及这种访问是否真的合理。

参考来源

• TechCrunch：Some Supabase customers are publicly exposing reams of people’s data to the web：关于多款 Supabase 客户应用公开暴露用户数据的原始报道。该链接用于事件背景核对。
• Reddit：State of Supabase exposure across vibecoding apps：社区针对约 2 万个 vibe coding 应用开展的暴露情况扫描讨论，文中已对其统计口径和结论边界作出说明。