审计50个AI Agent应用：揭秘最常见的五大安全漏洞

在过去的几个月里，我们对50款基于Lovable、v0、Bolt、Cursor和Claude Code等平台构建的AI Agent应用进行了深入审计。这些应用涵盖了从个人爱好项目到YC支持的初创公司，甚至包括24小时黑客松后直接投入生产的产品。令人惊讶的是，几乎所有这些应用都重复出现了五种相同的安全漏洞。

本文将详细揭示这些漏洞的具体细节、提供实用的检测命令（如grep），并指出实际的修复方案，帮助开发者避免潜在的安全风险。

漏洞1：Supabase行级安全（RLS）未启用 (50个应用中的44个)

我们审计的Lovable应用中，有70%完全关闭了行级安全（RLS）。 Lovable RLS漏洞（CVE-2025-48757，CVSS 9.3，2025年3月）在一个周末内影响了170多个生产应用。其中，Lovable EdTech暴露了18,697条学生记录，包括4,538条来自加州大学伯克利分校和戴维斯分校的数据。更糟糕的是，其认证检查是反向的：匿名用户获得了完全的读取权限，而认证用户反而被阻止。

如何检测：

在Supabase SQL编辑器（或使用服务角色密钥的psql）中运行以下SQL查询：

SELECT schemaname, tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public'
ORDER BY rowsecurity, tablename;

如果任何行的rowsecurity字段显示为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);

根据需要，对INSERT、UPDATE和DELETE操作重复创建类似策略。

默认允许的策略非常危险。正确的安全姿态应该是默认拒绝，然后显式授予权限。

为何此问题持续存在：在相关补丁发布之前，Lovable的模板并未默认启用RLS。即使补丁发布后，使用旧模板生成的应用仍然可能带着这个漏洞上线。有关更多信息，请参阅：https://www.superblocks.com/blog/lovable-vulnerabilities

漏洞2：秘密密钥暴露在NEXT_PUBLIC_*变量中 (50个应用中的39个)

这导致了Moltbook泄露事件（2026年2月），造成150万个API令牌、3.5万封电子邮件和47GB的Agent对话历史被泄露。其根本原因是一个Supabase匿名密钥通过NEXT_PUBLIC_SUPABASE_ANON_KEY被硬编码到捆绑的客户端JavaScript中。在没有RLS保护的情况下，该密钥可以返回每个表的每一行数据。

NEXT_PUBLIC_不是一个简单的命名约定，它是一个构建指令。所有带有此前缀的变量都会被打包到分发给每个访问者浏览器的JavaScript文件中。如果它是一个秘密，那么一旦被这样处理，它就不再是秘密了。

如何检测：

1. 审计代码库中所有的NEXT_PUBLIC_*变量：

grep -rE "NEXT_PUBLIC_[A-Z_]+" app/ pages/ components/ lib/ --include="*.ts" --include="*.tsx" --include="*.js" | sort -u

2. 审计构建输出中是否包含已提交的秘密信息：

grep -rE "sk_live_|pk_live_|sk_test_[a-zA-Z0-9]{24,}|sb_secret_|AKIA[A-Z0-9]{16}" .next/ public/

（原文在此处中断，后续内容缺失。）