AI 生成应用上线前的常见安全缺口

作者扫描了 334 个由 Lovable、Bolt 和 v0 构建的公开 GitHub 仓库，发现 32% 至少有一项上线前需要修复的问题，主要集中在凭据暴露和数据权限。这个结果提醒我们：AI 能把页面和功能搭起来，不代表应用已经具备上线条件。

不过，这份报告更适合用来整理检查清单，不能直接拿来给三个工具排安全名次。样本来自公开仓库，检查只读代码，而且作者自己也在开发提供这项检查的 Launchpad。

能跑起来之后，还有哪些东西会泄露或失控

这次检查关注的是应用上线后可能出问题的地方，而不是页面是否好看、交互是否完整。作者报告了六类发现：

• 23% 的应用提交了 .env 文件。
• 19% 存在允许任何人修改数据的策略。
• 7% 的数据表没有启用行级安全（Row Level Security，RLS）。
• 6% 在浏览器代码中使用了 Supabase admin key。
• 1% 向浏览器暴露了秘密信息。
• 1% 把秘密密钥提交到了仓库。

这些比例可能重叠，不能相加当作问题应用的占比。

其中，两组问题尤其值得程序员分开看。一组是凭据放错了位置：仓库公开了不该公开的文件，或者浏览器拿到了不该持有的密钥。另一组是数据权限过宽：用户能访问页面，不等于应该有权修改任意数据。

.env 被提交，也不自动证明其中有有效密钥；没有启用 RLS 的表，实际风险还取决于它是否对外开放、是否有其他访问控制。原文没有给出逐项判定细则，因此这些数字首先代表扫描发现，不能全部等同于已经确认的可利用漏洞。

功能验收通过，不能替代凭据和数据权限检查。

三个工具的差距，为什么不能直接当作排名

样本取自最近两个月更新过的公开仓库，作者称是在符合条件的仓库中随机抽取，并通过各工具导出 README 时留下的文本识别来源。

总体结果是：上线评分中位数为 80/100；33% 达到作者定义的「可上线」标准，即 90 分及以上；32% 至少有一项上线前需要修复的问题。这两个比例不是互补关系，原文也没有完整解释评分与问题判定如何对应。

分工具看，差距很大：

来源工具	应用数量	评分中位数	上线前有问题的比例
Bolt	115	90/100	12%
Lovable	108	55/100	79%
v0	111	85/100	7%

最容易误读的是 Lovable 的 79%。它说明这批被识别为 Lovable 产物的仓库，在这套检查下更常触发问题，不能单凭这一点推导出工具自身更不安全。

作者也明确提醒：这些工具构建的应用差异很大，比较的是用户最终交出的应用。原文没有按应用复杂度、后端类型、是否接入数据库等条件做对照，也没有给出差异的原因分析。

另外，公开仓库未必已经部署。把结果表述为「32% 的线上应用存在漏洞」，超出了这次检查能证明的范围。

我的判断

我认可这份报告把注意力从「生成得快不快」转向「上线前还缺什么」。凭据位置、数据库策略和浏览器权限，确实值得独立检查；它们很难仅靠点一遍页面发现。

但这还不是一份足以支持工具选型的对照研究。原文没有公开评分权重、误报验证结果，也没有说明各类问题如何影响分数。代码扫描还看不到控制台里的配置，实际状态可能与代码呈现不同。

和人工检查部署配置、实际验证访问权限相比，这类扫描适合先筛出需要复核的位置，不能覆盖全部上线验收。

作者披露自己参与开发 Launchpad by Axonscape，并提供同款检查，免费、无需账号，报告每月更新。这是应当保留的商业背景。它不直接否定数据，但也不能把「90 分以上」理解成独立认证。

能拿来做什么

• 给 AI 生成的项目增加一次上线前检查，至少逐项核对 .env、仓库密钥、浏览器代码中的秘密信息和数据库权限，不要只验收页面与功能。
• 使用 Supabase 时，专门检查浏览器代码是否包含 admin key，再确认数据表的 RLS 和策略是否符合预期；不要因为登录流程正常，就认定数据访问已经受控。
• 把扫描发现作为复核入口，结合部署控制台和实际权限验证判断风险。选 Lovable、Bolt 或 v0 时，可以参考这份样本结果，但应优先检查自己的应用。