Lovable平台这次出的事，可不是小打小闹。
2026年2月27日，安全研究员Taimur Khan发布了一份详细的漏洞披露报告。报告指出，在Lovable平台上，一款由AI生成的学生考试与成绩查看应用，被发现了多达16个安全漏洞。其中，6个漏洞的严重程度被评定为“严重”（Critical）。这款应用的直接用户包括来自加州大学伯克利分校、戴维斯分校的大学生，甚至还有K-12阶段的中小学生。最终确认泄露的数据量触目惊心：18，697条用户记录被暴露，其中870名用户的完整个人信息一览无余。
这起事件，可以说是“vibe coding”（氛围编码）世界迎来的第一起有完整记录和披露的真实安全事故。安全问题，不再是“理论上可能发生”，而是“已经实实在在地发生了”。
逻辑反转：AI亲手装了一扇装反的门
这起事故最值得我们深思的，恰恰是漏洞的本质。它不是什么高深莫测的零日漏洞（0-day），而是一个极其基础的、堪称“滑稽”的逻辑错误。
这款应用的后端由Supabase驱动，负责处理用户认证、数据存储和数据库交互。AI在生成后端代码时，编写了一个访问控制函数。这个函数的初衷再明确不过：“拦截未登录的用户，放行已登录的用户”。然而，AI却把逻辑给写反了：结果是，已登录的用户被挡在门外，而未登录的访客却能长驱直入。
Taimur Khan在报告中这样写道：“这是一个人类代码审查员一眼就能发现的错误。但AI代码生成器只追求‘代码能跑’，就直接把它推向了生产环境。”
“代码能跑”和“代码安全”是截然不同的两件事。AI非常擅长生成能通过基础功能测试的代码，但功能测试绝不等于安全审计。当认证逻辑被完全翻转，从普通用户的视角来看，一切似乎都很正常——点击登录，然后就进去了。只有当你专门去测试“在未登录状态下，我究竟能看到什么？”时，这个致命的漏洞才会浮出水面。
10万浏览量的“明星应用”，安全审计谁来负责？
这起案例中，还有一个令人细思极恐的细节：这款存在严重漏洞的应用，当时正展示在Lovable平台的“Discover”（发现）页面上，浏览量超过10万，收获了大约400个点赞。
“Discover”页面是平台用来展示优质案例、相当于获得官方推荐的地方。这就意味着，一款被官方推荐的、由vibe coding打造的“明星应用”，同时也是一款携带16个漏洞的危险产品。这两件矛盾的事情，在同一个产品上同时成立。
这暴露了当前vibe coding平台一个结构性的问题：平台的激励机制完全围绕着“帮助你快速将想法变成产品”，但对于“产品是否安全”这件事，平台文档里的普遍说辞是“用户需在发布前自行负责”。
发布一款应用的技术门槛，确实从“会不会写代码”降到了“会不会写提示词（prompt）”。然而，安全审计的专业门槛并没有同步降低。结果就是，一大批缺乏安全背景的创作者，正在用他们自己可能都看不懂的代码，构建面向真实用户的产品。
安全公司Veracode近期的研究也印证了这一点：由AI辅助生成的代码所引入的安全漏洞，正在以可测量的速度增长。Lovable的这次事件是“第一个被完整披露的案例”，但它很可能并非“第一个出现的案例”。
Vibe Coding 的安全“技术债”正在累积
坦率地说，类似的问题我早有预感，只是不确定第一个具体案例会在何时、以何种形式出现。
Vibe coding 的核心承诺是“消除从创意到产品之间的障碍”，这个承诺是真实的，工具也确实做到了。但它同时也移除了一个关键的“过滤器”：技术门槛曾是一道隐性的安全关卡。在过去，只有懂代码的人才能上线产品，而不懂安全的代码往往很难通过团队内部的技术评审。
现在，这道关卡消失了。任何人都可以快速上线产品，而安全意识与安全知识，则变成了一项依赖于个人自觉的“软性要求”，而非“硬性门槛”。
更深层次的问题是：即便使用者具备基本的安全意识，他们有能力去审查AI生成的代码吗？Taimur Khan能发现这个漏洞，是因为他拥有软件工程背景，知道要去深入查看认证函数的具体实现逻辑。而普通的vibe coder，大概率根本不会想到去审查“认证逻辑是否被写反了”这种底层问题。
教训与应对：下一步该怎么办？
这次安全事故，给所有希望使用vibe coding工具构建真实、可用产品的开发者敲响了警钟。以下几点值得牢记：
第一，涉及用户数据的应用，安全绝不能仅依赖AI自动保证。 无论是Lovable、Replit还是其他任何低代码/AI编码平台，对于用户认证、权限控制、数据访问这几个核心安全模块，必须引入人工审查环节，或者至少使用专业的自动化安全扫描工具进行全面检查。
第二，务必开启并正确配置平台提供的安全默认设置。 以本次事件中的Supabase为例，它提供了强大的“行级安全”（Row Level Security， RLS）功能，可以在数据库层面直接限制数据行的访问权限。在Lovable的案例中，如果RLS策略被正确启用，很多漏洞的实际影响范围将会被大幅缩小。遗憾的是，在默认情况下，许多由vibe coding生成的项目并不会主动开启这些高级安全特性。
第三，上线前，务必亲自做一次“未登录态”测试。 这是最简单、也最有效的安全测试之一：退出所有登录状态，以完全匿名访客的身份，尝试访问你应用的各个页面和API端点，看看哪些数据依然可以被看到。这十分钟的测试，很有可能帮你发现应用中最严重的逻辑漏洞。
Vibe coding不会因为这起事故而消失，其工具价值是真实且巨大的。但“快速产出产品”与“安全地构建产品”之间的内在张力，将会变得越来越突出和不可回避。对于技术社区而言，如何在享受生产力革新的同时，建立与之匹配的安全意识与保障机制，是接下来需要共同面对的课题。欢迎在云栈社区的安全技术板块交流更多关于代码安全与审计的实践经验。
发表于 12 小时前
|
查看: 2|
回复: 0
