Moltbook数据库泄露事件解析：Supabase RLS配置缺失致API密钥暴露

近日，一名开发者在检查新兴AI社交平台Moltbook时，发现其整个生产数据库在没有采取任何访问控制措施的情况下暴露在公网上。这一严重的安全漏洞意味着攻击者可以随意读取甚至修改数据库中的所有记录。

从公开的截图可以清晰地看到，泄露的数据结构完整，包含了用户的 id、name、description 以及最为敏感的 api_key（API密钥）、claim_token（领取令牌）等字段。发现此问题的安全研究员 Jamieson O‘Reilly 在社交媒体上指出，任何人利用这些泄露的 api_key，都可以轻而易举地冒充平台上任意已注册的“AI Agent”身份来发布内容或执行其他操作，潜在的受害者甚至包括了知名AI研究员 Andrej Karpathy 创建的Agent。

漏洞根源：行级安全策略（RLS）的缺失

问题的技术根源直接指向了Moltbook所依赖的后端即服务（BaaS）平台——Supabase。据社区分析，Moltbook的开发团队在部署其 PostgreSQL 数据库时，未能启用关键的行级安全策略（Row Level Security, RLS）功能。

RLS是PostgreSQL提供的一种细粒度访问控制机制，它允许数据库管理员基于执行SQL命令的用户角色，来限制其对表中行的查询、插入、更新和删除操作。当RLS未被启用时，只要连接凭证正确，客户端便拥有对整张表的完全访问权限，这正是导致此次大规模数据泄露的直接原因。

事件发生后，立即有熟悉Supabase的网友在相关讨论中给出了补救方案：只需在数据库中对关键表（如 agents 表）执行两条简单的SQL命令即可快速启用基础防护。首先是启用RLS，然后创建一个仅允许用户访问自身数据的基础策略。

-- 1. 为 agents 表启用行级安全策略
ALTER TABLE agents ENABLE ROW LEVEL SECURITY;

-- 2. 创建一个策略，例如仅允许用户查看和操作自己的数据（假设通过 auth.uid() 识别）
CREATE POLICY "用户仅能操作自己的Agent"
ON agents FOR ALL USING (auth.uid() = owner_id);

如此基础且至关重要的数据库安全配置出现缺失，在专业开发者看来实属罕见。因此，有评论毫不客气地指出：“Moltbook完全是用‘氛围编程’（vibes-driven development）开发的，这种事注定会发生”，以此调侃其开发过程中可能过于注重产品概念与用户体验，而忽略了底层基础设施的安全性。

事件响应与反思

值得肯定的是，在漏洞被公开披露后，Moltbook团队的反应相当迅速，及时介入并修复了这一问题，避免了事态的进一步扩大。此次事件也为所有开发者，尤其是采用BaaS或Serverless架构的团队敲响了警钟。

它揭示了一个深刻的教训：即便使用能够极大提升开发效率的现代云服务，开发者自身仍须对应用的整体安全模型负责。云平台提供的安全工具（如RLS）若未被正确配置和启用，则形同虚设。在快速迭代和“氛围感”之外，扎实的安全基本功和对数据权限的严谨设计，永远是守护用户信任的基石。对于这类涉及敏感API密钥和用户身份的系统，在云栈社区的数据库与安全板块中，常有关于权限设计与审计的深度讨论，值得参考。

这也引发了一个更广泛的思考：随着AI Agent等自治系统的普及，将重要的API密钥和权限直接交付给它们是否足够稳妥？至少目前看来，AI的安全边界仍需由人类开发者来谨慎定义和守护。