氛围编程的170个后门：一个曾经失败的工程师深挖Lovable安全漏洞事件

“能跑，但漏洞一堆”——在1,645个应用上得到了证明

昨天我还在泛泛地写氛围编程的陷阱。然后一组具体的数字直接把我打懵了。

Superblocks的调查报告显示，对氛围编程平台Lovable上的1,645个应用进行扫描后，发现170个存在严重安全漏洞。占总数的10.3%。暴露的脆弱端点多达303个。

十个里有一个。请停下来想想这意味着什么。

泄露的数据内容更让人震惊：Google Maps和Gemini的API密钥、eBay的认证令牌、用户个人信息、金融交易数据。The Register的报道还提到，仅一个应用就造成18,000名用户的数据暴露。

我写这篇文章不是为了抨击Lovable。昨天我写的”能跑但已经坏了”综合症——那个我描述为理论风险的东西，以超出我预期的规模成为了现实。这才是真正震撼我的地方。

这篇文章会准确梳理发生了什么，并给出今天就能对自己代码进行检查的3个步骤。关于要不要用氛围编程的争论已经结束了。现在进入的是”如何安全使用”的阶段。

CVE-2025-48757：到底发生了什么

让我用通俗语言解释一下技术层面的问题。

这个漏洞被赋予了正式编号CVE-2025-48757。CVE是全球安全漏洞数据库的编号体系，这意味着它不是”小bug”，而是国际认定的严重问题。

发现者是安全研究员Matt Palmer。根据他的公开声明，他于3月21日联系了Lovable CEO Anton Osika。Lovable于3月24日确认收到。但在45天的披露宽限期内，实质性修复迟迟未到，于是他选择公开披露。

CVE-2025-48757从发现到公开披露的时间线：3月21日研究员联系Lovable → 3月24日确认收到 → 45天宽限期 → 5月29日公开披露

根本原因：缺少RLS配置

问题的核心是RLS（行级安全，Row Level Security）未设置。

RLS是在数据库行级别进行访问控制的机制。它让你可以设定”这个用户只能看自己的数据”或”只有管理员才能查看全部数据”这样的规则。没有它，数据库基本上就是大开门户。

Lovable使用Supabase作为后端。数据库连接用的认证令牌（anon key）存放在前端JavaScript中——这本身是设计允许的，前提是RLS已正确配置。

但Lovable的AI在创建数据库表时，并未设置RLS策略。它会创建表，会配置读写功能，但”谁能访问什么”的规则却空着。结果是：只要拥有anon key，任何人都能读写数据库中的所有数据。

SecurityOnline对这一结构性问题进行了详细报道。

作为有CS背景的人，我可以这样类比：这就像给Web门户精心制作了一个登录页面，却留了一个直接输入URL就能进入管理后台的入口。前门上锁了，后门大开着。这就是我把它们叫作”170个后门”的原因。

Lovable 2.0的”安全扫描”不够用

Lovable于2025年4月24日发布了带有内置安全扫描功能的”Lovable 2.0”。但desplega.ai的分析发现，扫描器只检查RLS是否”已启用”，并不验证它是否”正确运行”。

于是，一个形同虚设的RLS策略仍然会显示为”已配置”。用户获得了错误的安全感。批评者将其称为创可贴，而非治疗。

这不只是Lovable的问题——而是氛围编程的结构性缺陷

“我不用Lovable，所以跟我没关系。“我最开始也这么想。但越查越发现，这是个更大的问题。

Escape.tech的研究触目惊心。他们不只分析了Lovable，还分析了Base44、Create.xyz、Bolt.new等多个平台上的5,600多个应用。（值得注意的是，其中约4,000个应用来自Lovable，因此平台间存在样本偏差。）

结果如下：

发现2,000多个漏洞
400多个秘密信息（API密钥、密码）暴露
175条PII（个人身份信息）泄露，包括医疗记录、银行账号、电话号码和电子邮件地址

Getautonoma的报告更直白：AI生成代码中的53%存在安全漏洞。超过一半。

为什么AI会”忘记”设置安全配置

这才是核心问题。

AI在写能运行的代码方面确实表现出色。让它构建用户注册功能，它会一口气完成表单、验证和数据库写入。但安全配置不影响功能运行——所以除非你明确要求，否则它就会被跳过。

没有RLS，应用照样能跑。数据照样能存。界面照样能显示。这就是”能跑但已经坏了”综合症最字面意义上的体现。

还记得我昨天写的那个没有SQL注入防护的Slack Bot吗？结构完全一样。AI实现功能，但不实现防御。因为没有人要求它这么做。

vietanh.dev的指南将这种”功能实现与安全实现的不对称性”指为氛围编程的根本性问题。

# AI被要求"构建用户注册功能"时生成的代码示例
# 功能上完全正常运行，但RLS未设置

# Supabase建表语句（AI容易生成的版本）
# → RLS策略为空 = 任何人均可访问
create_table_sql = """
CREATE TABLE users (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  email TEXT NOT NULL,
  name TEXT,
  created_at TIMESTAMPTZ DEFAULT now()
);
"""

# 安全写法：从一开始就启用RLS
secure_table_sql = """
CREATE TABLE users (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  email TEXT NOT NULL,
  name TEXT,
  created_at TIMESTAMPTZ DEFAULT now()
);
-- 启用RLS
ALTER TABLE users ENABLE ROW LEVEL SECURITY;
-- 策略：已认证用户只能读取自己的数据
CREATE POLICY "users_read_own"
  ON users FOR SELECT
  USING (auth.uid() = id);
"""

这两段代码在注册功能上表现完全一致，都能将用户写入数据库。但前者是”后门大开”，后者是”上了锁”。就是多出来的几行代码，决定了18,000人的数据是否安全。

现在就能做的3项自查

接下来是实操环节。以下是今天就能完成的3个步骤，帮你回答”我的代码安全吗？“

检查一：在Supabase控制台查看表列表

如果你在使用Supabase，登录控制台。从左侧菜单打开”Table Editor”，查看每张表的”RLS”列。如果有表显示”Disabled”，那就是一个后门。

三步操作：

登录Supabase控制台
左侧菜单进入”Authentication”→“Policies”
确认每张表都配置了至少一条策略

如果有表完全没有策略，需要立即处理。还要注意这种情况：RLS显示”已启用”但没有任何实际策略——看起来有保护，实际上形同虚设。这正是Lovable 2.0扫描器漏掉的模式。

检查二：在前端源码中搜索API密钥

打开浏览器开发者工具（F12），进入”Sources”标签，在JavaScript文件中搜索以下关键词：

// 在浏览器开发者工具中需要搜索的关键词
// 只要命中任何一条，该密钥就处于暴露状态

sk-          // OpenAI API密钥前缀
AKIA         // AWS访问密钥前缀
AIza         // Google API密钥前缀
ghp_         // GitHub个人访问令牌
stripe_sk_   // Stripe密钥

找到Supabase的anon key是正常的——它本来就是公开设计的。问题在于上述密钥类型如果出现在前端，需要立即将其移入环境变量。

浏览器开发者工具Sources标签中搜索API密钥的示意图：搜索框输入"sk-"，JavaScript源码中显示高亮匹配结果

检查三：让AI以攻击者视角审查你的代码

这个方法我在昨天的文章里提过，但结合今天的背景，这里给出更具体的提示词：

请以攻击者的视角审查这个应用的安全性。
重点检查以下三个方面：

1. 数据库访问控制
   （RLS策略是否已正确配置？）
2. API密钥和秘密信息的暴露情况
   （是否有内容直接嵌入前端？）
3. 用户输入的清理处理
   （SQL注入和XSS防御是否充分？）

对于每个方面，如果存在漏洞，
请给出具体的代码修复方案。

关键就在”以攻击者的视角”这几个字。加上这句话，AI的回答就会从”看起来没问题”转变为”这里可以被利用”。还有一点很重要：在单独的会话中提出这个请求。在生成代码的同一段对话里让它审查，往往会自卖自夸。

“要不要用”的争论已经结束

让我稍微拉远视角看一下。

Semafor将Lovable描述为”黑客的活靶子”。看到这样的标题，很容易得出”氛围编程就是危险的”这一结论。

但我不这么看。

回想一下Web开发的历史。2000年代，PHP构建的网站到处是SQL注入漏洞。WordPress的安全问题现在还在每月被报出来。但这并没有演变成”别用PHP""别用WordPress”的呼声。工具成熟了，最佳实践确立了，安全防护成为标配。

氛围编程正在走同样的路。

而且行动已经开始。Escape.tech完成了1800万美元的融资，专门为氛围编程构建安全扫描工具。VibeEval作为专门面向Lovable的自动化安全测试服务也已上线。

工具端的进化同样在推进。Claude Code正在加入安全风险警告功能。Cursor也在朝代码生成时展示风险的方向演进。GitHub Copilot的新指标API让AI生成PR的质量追踪成为可能。

“要不要用”的阶段早就过去了。Barrack AI的整理统计了2025年1月以来的AI应用数据泄露事件，共20起。根本原因几乎一致：访问控制缺失、秘密信息暴露、输入验证不足。原因如此一致，对策也就有迹可循。

问题不是”氛围编程是否危险”，而是”你的代码现在有没有后门大开”。

和昨天的文章联系起来看

昨天，我写了”能跑但已经坏了”综合症的三个陷阱：安全漏洞、无法解释的代码、没有测试的沙堡。我还介绍了VibeContract作为应对方法。

Lovable事件，正是那第一个陷阱——安全漏洞——在现实世界大规模爆发的案例。而且我描述为理论风险的东西，在1,645个真实应用上得到了验证。

有一点值得说：只要在我昨天提到的VibeContract的YAML中加一行，就有可能防止这类事故中的大部分。

# 需要添加到vibecontract.yaml的内容
contracts:
  - "为所有表启用RLS并配置适当的访问策略"
  - "API密钥从环境变量获取，绝不硬编码到前端"
  - "所有用户输入必须通过参数绑定处理"

“合约里写了，AI就会自动设置。“有了这个机制，170个后门中的相当一部分就能在开门之前被关上。保留氛围编程的速度，守住代码质量。把昨天和今天的两篇文章结合起来读，就能看到完整的图景。

展示"昨天的文章（一般理论）→今天的文章（具体事件）"关系的连接图：左侧为三个陷阱图标，右侧为Lovable 170个后门图标，中央箭头标注"预测成真"

总结：关上后门，靠的是你自己的判断

从170个后门中能学到的东西，整理如下：

发生了什么：1,645个应用中的170个（10.3%）因缺少RLS而存在漏洞。API密钥、个人信息和金融数据遭到暴露。
为什么会发生：AI构建能运行的功能，但不构建防御——除非被明确要求。这是整个氛围编程领域共同的结构性问题。
今天能做什么：检查Supabase表的策略配置，在前端搜索暴露的密钥，让AI以攻击者视角进行代码审查。
中期对策：通过VibeContract将安全要求预先定义为”合约”。

我是那种信奉”能跑就行”的人。这一点没有变。但把后门大开着置之不理是另一回事。脑子里住着高手工程师的感觉是真实的——但安全判断可不会随之而来。

以前我觉得自己永远比不上专业工程师。在深层架构设计上，也许现在还是比不上。但”检查自己的应用有没有后门”这件事，我能做到。今天介绍的三项检查，不需要专业经验，五分钟就能搞定。

氛围编程是一件有力的武器。但把安全装置拆掉挥舞，只会伤到自己。170个后门不是”氛围编程很危险”的证据，而是”是时候学会安全使用它了”的信号。

今天就去检查你的应用有没有后门吧。五分钟，就这么多。