只要用自然语言输入几句话,AI 就能在几分钟内生成一个带数据库和用户管理系统的完整 Web 应用。这种被称为“氛围编程”(Vibe Coding)的新体验,让无数没有技术背景的创业者体验到了软件开发的快感。

然而,不需要写代码并不意味着安全问题会自动消失。德国安全机构 Crissy Field 与《商报》合作,对 open web archive 归档的 159,041 个 Lovable 项目进行了详细排查,结果令人捏一把汗:大量在公网上运行的应用,正在向外界毫无保留地广播用户隐私。

15 万个 AI 项目排查:护照、私信与订单全在裸奔

在这项涵盖 2025 年 12 月至 2026 年 9 月数据的大排查中,研究人员发现共有 34,545 个 Lovable 项目集成了后端数据库 Supabase。

一万多个数据表未设防,用户护照与私信记录直接在公网暴露
一万多个数据表未设防,用户护照与私信记录直接在公网暴露

尴尬的是,其中有 24,664 个网站在没有任何登录校验的情况下,只要用户首次打开页面,就会主动发送 Supabase 的数据库记录。

研究人员使用网站自带的前端 API 密钥发起只读请求,成功在 7,403 个网站的 10,560 个数据表中提取到了包含电子邮箱的敏感信息。也就是说,在被深度检测的网站中,有三成直接亮出了后端底牌。

从检索到的真实数据来看,泄露的严重程度远超预期:

  • 某德国生活方式论坛暴露了 80,000 多份用户个人资料(包含姓名、生日、性别及邮箱)以及 200,000 多条私密聊天记录。
  • 某服务商的数据表中暴露了 1,000 多条身份证明明细,其中清清楚楚写着用户的护照号码、到期日和国籍。
  • 多家餐厅和票务平台暴露了数万条餐饮与门票订单,姓名、电话、邮政地址乃至支付明细一览无余。
  • 某房产管理公司甚至直接暴露了由 AI 生成的内部敏感邮件摘要,涉及大量租客与房东的隐私。
  • 在另一个案例中,高达 280,000 封发给客户的邮件全文处于没有任何访问限制的状态。
Lovable 项目安全审计漏斗(2025.12 - 2026.09) 审计项目总数 159,041 Common Crawl 归档 集成 Supabase 34,545 占比约 21.7% 无登录主动发包 24,664 首屏暴露数据库连接 确认暴露敏感表 7,403 抽样中 30% 存风险

研究机构 Crissy Field 严谨地指出,30% 的邮箱提取率并不直接等于确诊的数据泄露率,因为部分邮箱可能是公开的客服联系方式或测试数据。但在未加防护的情况下,任何人只要顺藤摸瓜,就能把整个数据库一抽到底。

不是平台被黑,而是“氛围编程”割裂了后端防线

很多人第一反应是:是不是 Lovable 的服务器被黑客攻破了?

AI 自动配好了前端通行密钥,却漏掉了关键的后端门禁规则(剖面示意)
AI 自动配好了前端通行密钥,却漏掉了关键的后端门禁规则(剖面示意)

并不是。这恰恰是整个事件最值得深思的地方——问题不在于代码有漏洞,而在于无技术背景的开发者根本不知道后端防护为何物。

在传统的 Supabase 架构中,前端代码里暴露公开 API 密钥(Anon Key)是符合设计规范的正常操作。但 Supabase 的安全机制高度依赖一种叫作行级安全策略(Row Level Security, 简称 RLS)的规则。这套规则的作用就像是包厢门的钥匙,必须显式定义“哪位用户只能看哪张表里的哪一行数据”。

当一位完全不懂 SQL 或权限管理的创业者,用自然语言向 Lovable 提出“帮我做个用户论坛”的指令时,AI 能够完美地生成漂亮的前端界面,并自动把前端 API 密钥填好。然而,AI 并没有强行要求或自动配置好严格的 RLS 规则。

后果显而易见:前端拿着合法的公开密钥,去向后台请求未受 RLS 保护的数据表。后台认为请求合法,直接把所有私密聊天、护照明细和支付记录毫无保留地双手奉上。

漏洞成因:Vibe Coding 带来的安全断层 1. 零门槛前端生成 用户通过自然语言描述 AI 自动注入 Supabase 密钥 2. RLS 规则缺失或错配 非技术创作者不懂行级安全 数据表未阻断只读 API 请求 3. 越权拉取数据库 无需登录校验身份 全量提取私信、护照与订单

古人云:“不知者无畏,无知者无防。” AI 工具把原本需要专业程序员把关的生产力带给了大众,却并没有把配套的安全警惕性同步打包注入。

营销主打免代码,条款却把甩包玩到了极致

比技术漏洞更尖锐的,是平台方的商业态度与责任悖论。

平台高调宣传零代码开发门槛,却在条款中把安全责任全甩给用户
平台高调宣传零代码开发门槛,却在条款中把安全责任全甩给用户

Lovable 在官方营销宣传里极其高调,反复向外界灌输一个概念:“你不再需要任何技术背景或程序员,就能独立发布软件。”但在法律文件和服务条款(T&C)中,Lovable 却极其清醒地写明:所有应用的安全防护、数据合规与隐私责任,完全由用户自己承担。

安全负责人 Igor Andriushchenko 在事件发生后回应称:“应用归创作者所有,上线前的最终把关在创作者自身。”

这就形成了一个荒谬的闭环:平台靠着“零门槛、零技术要求”吸引不懂代码的用户买单;可一旦出了安全事故,平台立刻搬出条文,嘲笑用户“不懂技术为什么不检查权限”。

有人可能会想,换个平台是不是就好了?比如把代码迁移到 Bolt.new 或者 Replit?

答案是根本没用。只要底层依然连接着那套没有配置好 RLS 的 Supabase 数据库,数据依然处在裸奔状态。这并不是换个前端 AI 生成器就能解决的问题。

Supabase 虽然在 2026 年 10 月底紧急更新了策略,默认强制对新创建的数据表关闭 API 访问,但他们也明确表示:该更新不会追溯历史数据。 换言之,过去几个月由非技术用户搭建的数万个存量应用,只要没人手动补上防线,依然是一撬即开的空门。


  • 结论.真正的安全不能寄希望于“生成代码能跑通”。在将任何涉及用户个人数据的应用推向公网前,必须由懂行的专业人员对其权限架构进行二次审计,自动化扫描无法替代专业把关。
  • 风险.对于完全依赖自然语言开发产品的独立创作者,若继续忽视后端行级权限,将可能面临极其严重的合规追责与用户信任崩塌。

这起事件给整个科技界泼了一盆冷水。AI 确实抹平了写出第一行前端代码的门槛,但它并没有抹平计算机科学里那些关于鉴权、隔离和安全防范的硬性规律。

极度降低门槛的产物,往往也在极度降低防御力。

如果 AI 平台在享受“氛围编程”带来的商业溢价时,只顾着把营销海报画得花团锦簇,却把安全包袱一股脑甩给连 RLS 三个字母都没听过的新手,那么这种所谓的生产力革命,从一开始就埋下了沉重的安全代价。