我审计了50款由人工智能辅助生成的应用程序。以下是出现故障的情况。

2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家 

在过去几个月里，我审计了 50 个使用 Lovable、v0、Bolt、Cursor 和 Claude Code 开发的应用程序。其中一些是朋友的副业项目，一些是获 YC（Y Combinator，美国创业孵化器）支持的初创公司项目，还有一些是原本仅为 24 小时黑客马拉松提交的作品，却最终投入了生产环境。几乎每一个应用都存在相同的五个漏洞。

本文是对这些发现的详细总结。包含具体的 grep 命令、真实的通用漏洞披露（CVE）案例，以及实际需要修复的内容。

如果你想要文末提到的工具包：售价 10 美元，包含 50 项技能。https://rishabhvaai.gumroad.com/l/plddbd。或者你可以跳过它，因为这篇总结已经涵盖了这些模式。

漏洞 1：禁用的 Supabase 行级安全策略（50 个应用中的 44 个）

在被审计的 Lovable 应用中，70% 完全关闭了行级安全策略（RLS）。Lovable 的行级安全策略漏洞（CVE-2025-48757，通用漏洞评分系统分值 9.3，2025 年 3 月）在一个周末内影响了 170 多个生产环境应用。Lovable EdTech 泄露了 18,697 条学生记录，其中 4,538 条属于加州大学伯克利分校和加州大学戴维斯分校。更糟糕的是身份验证检查逻辑颠倒：匿名用户获得了完整的读取权限，而经过身份验证的用户却被阻止访问。

如何查找：

-- 在你的 Supabase SQL 编辑器中运行（或使用服务角色密钥通过 psql 运行）
SELECT schemaname, tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public'
ORDER BY rowsecurity, tablename;

如果任何一行显示为 FALSE，则说明存在问题。具体来说：任何拥有你项目匿名密钥（该密钥包含在你的客户端打包文件中）的人都可以读取该表的每一行数据。

如何修复：

ALTER TABLE public.your_table_name ENABLE ROW LEVEL SECURITY;

CREATE POLICY "users_select_own"
  ON public.your_table_name
  FOR SELECT
  USING (auth.uid() = user_id);

-- 根据需要为插入/更新/删除操作重复上述步骤

默认允许的策略是危险的。默认拒绝加上显式授权才是正确的安全姿态。

为何此问题持续出现：在补丁发布之前，Lovable 的模板默认未启用行级安全策略。即使在补丁发布后，使用补丁前模板生成的应用仍然被部署到生产环境。

来源：https://www.superblocks.com/blog/lovable-vulnerabilities

漏洞 2：秘密密钥暴露在 NEXT_PUBLIC_* 环境变量中（50 个中的 39 个）

这就是 Moltbook 泄露事件（2026 年 2 月，150 万个应用程序接口令牌，3.5 万封电子邮件，47GB 的代理对话历史记录）。原因：一个 Supabase 匿名密钥通过 NEXT_PUBLIC_SUPABASE_ANON_KEY 被硬编码在打包后的客户端 JavaScript 中。由于没有行级安全策略作为后盾，该密钥返回了每个表的每一行数据。

NEXT_PUBLIC_ 不是