我先核实这次 Lovable 数据暴露的范围、根因、发现方和官方回应，再按固定结构写成技术解析。
核心数据已确认：159,041 个项目、24,664 个 Supabase 实例零认证可读。接下来补充 Lovable 的最新回应与报告原文，避免把 “平台被黑” 和 “客户配置错误” 混在一起。
Lovable 大量应用暴露敏感数据：没有发生平台被攻破，问题在 Supabase RLS 没有开启
这次事件的原因是大量用 Lovable 生成的 App 把 Supabase 数据库直接暴露在公网，并没有发生在 Lovable 自己被攻破上。Crissy Field 与德国《Handelsblatt》用 Common Crawl 扫了 159,041 个 Lovable 项目（2025 年 12 月–2026 年 9 月），其中 34,545 个用了 Supabase，24,664 个在页面加载时就返回数据库记录；研究人员用页面本来就发给浏览器的同一个 key 做只读请求，在 7,403 个站点的 10,560 张表里读到邮箱，约占细查样本的 30%。泄露内容包含 1,000+ 条护照号 / 有效期 / 国籍、80,000 条用户资料、200,000 条聊天记录、订单 / 票务 / 支付信息、合同 / 发票 / 内部 WhatsApp。根因是 Supabase 的行级安全（RLS）缺失：浏览器里的 anon/publishable key 本来就是公开的，RLS 没开，等于把整张表交给任何访客。Lovable 安全负责人对《Handelsblatt》表示，这是行业已知问题，应用安全是共同责任；但 “无代码建站” 的营销和 “责任在客户” 的条款之间，确实有一道安全鸿沟。
一、事件全貌：对未设访问控制的数据库发起了正常读取
| 指标 | 数字 | 含义 |
|---|---|---|
| 扫描项目 | 159,041 个 | 通过 Common Crawl 找到的公开 Lovable 项目 |
| 使用 Supabase | 34,545 个 | 约占 21.7% |
| 零登录返回记录 | 24,664 个 | 页面加载时就把数据库记录发给访客 |
| 暴露邮箱的站点 | 7,403 个 | 占细查 24,664 个站点的 30% |
| 涉及表 | 10,560 张 | 邮箱出现在多张表里 |
| 护照记录 | 1,000+ 条 | 含护照号、有效期、国籍 |
研究人员强调，他们只用了网站正常提供给浏览器的只读请求，没有利用漏洞，也没有绕过认证。换句话说，这不是 “黑客撬锁”，而是 “门本来就是开的”。
二、泄露了什么：从护照到内部聊天
| 数据类型 | 具体例子 | 风险 |
|---|---|---|
| 身份证件 | 1,000+ 条护照号、有效期、国籍 | 身份盗用、开户 / 出行欺诈 |
| 用户资料 | 80,000 条姓名、邮箱、生日、性别 | 精准钓鱼、骚扰 |
| 私密聊天 | 200,000+ 条消息、内部 WhatsApp | 勒索、商业秘密泄露 |
| 订单 / 票务 | 电话、地址、支付信息、有效票码 | 门口诈骗、冒领 |
| 合同 / 发票 | 数万份合同、发票、私人相册 | 商业情报、客户隐私 |
| 内部邮件 | AI 生成的租户 / 业主 / 合作伙伴摘要 | 物业、法务、谈判信息泄露 |
还有报道提到某服务商泄露 28 万条客户邮箱。这个数字来自 DEV Community 的整理，不是 Crissy Field 报告原文的统计口径，引用时要注明。
三、根因拆解：anon key 不是秘密，RLS 才是门锁
Supabase 的架构是：浏览器直接通过 REST API 访问 Postgres。页面里带的那把 anon（或新的 publishable）key 是设计上就要公开的，它只代表 “未登录访客” 这个角色；真正决定能读哪些行的，是 RLS 策略。
| Key | 能否绕过 RLS | 该放哪 | 泄露后果 |
|---|---|---|---|
| anon / publishable | 不能 | 浏览器、前端代码 | 正常，关键看 RLS |
| service_role / secret | 能 | 只在服务端 | 灾难，等于数据库管理员 |
RLS 没开时，anon 角色没有任何过滤，GET /rest/v1/profiles?select= 就能把整张表拉走。登录框只是 UI 装饰，数据在 API 后面；攻击者不需要登录，只需要页面里那把公开 key。
四、为什么 AI 建站特别容易犯这个错
| 环节 | AI 做了什么 | 漏了什么 |
|---|---|---|
| 建表 | 生成 profiles、users、orders 等表 | 不主动生成 RLS 策略 |
| 写查询 | 让页面能读数据、能登录 | 不验证 “未登录能不能读” |
| 修报错 | 用 using (true) 让查询通过 | 把表变成 “所有人可读” |
| 上线 | 一键发布 | 没有安全检查门禁 |
| 责任 | 平台提供工具 | 条款把配置责任归客户 |
AI 生成代码的默认目标是 “能跑”，不是 “安全”。非技术创始人不知道 RLS 是什么，看到登录框能挡住页面，就以为数据安全了；实际上，API 根本不看登录框。更麻烦的是，Supabase 集成模式高度重复，一种错误配置会在几千个独立站点上同时出现，攻击者不需要逐个找漏洞，只要批量试同一个模式。
五、责任边界：Lovable、创作者、监管
| 角色 | 说法 | 应该做什么 |
|---|---|---|
| Lovable | 提供安全构建工具；应用如何配置，责任在创建者；这是行业已知问题，安全是共同责任 | 默认开启 RLS、发布前扫描、对高危配置弹窗 / 阻断 |
| 创作者 | 我用了 “无代码” 工具，以为平台会管安全 | 上线前做 RLS / 密钥 / 存储三项检查 |
| 监管 | GDPR/CCPA 对个人数据泄露有通知与整改要求 | 确认是否构成 “个人数据泄露”，评估通知义务 |
Crissy Field 报告自己留了三个重要限定：30% 不是确认泄漏率（邮箱可能是公开联系人或测试数据）；Common Crawl 样本不代表全部 Lovable 应用；没有确认这些数据被滥用。所以，不能把 “7,403 个站点有邮箱” 直接等同于 “7,403 起数据泄露事件”。但 “1,000+ 本护照”“200,000 条聊天” 这种级别的内容，已经足够触发合规审查。
六、更大的背景：vibe coding 的安全债
| 研究 | 样本 | 发现 |
|---|---|---|
| Crissy Field | 159,041 个 Lovable 项目 | 24,664 个零登录返回记录，7,403 个暴露邮箱 |
| RedAccess | 约 380,000 个 vibe-coded 应用 | 约 5,000 个泄露敏感数据 |
| Escape | 5,600 个生产应用 | 2,000+ 漏洞、400+ 暴露密钥、175 起个人数据泄露 |
| 行业统计 | AI 生成代码 | 40%–62% 含漏洞；91.5% 的 2026 Q1 vibe-coded 应用至少一个 AI 幻觉相关缺陷 |
这些数字口径不同，不能简单相加，但方向一致：AI 把 “建站” 的门槛降到零，却没有把 “安全默认值” 一起降下来。Lovable 不是唯一一家，Bolt、Replit、Base44 也有类似模式；差别只在 Lovable 这次被系统性扫了 16 万个项目。
七、30 分钟自查与修复清单
| 步骤 | 动作 | 验收 |
|---|---|---|
| 1. 盘点 | 列出所有 Supabase 项目、表、Storage bucket | 知道哪些表存了 PII |
| 2. 查 RLS | 跑下面的 SQL，看 rowsecurity 是否为 false | 所有 public 表都是 true |
| 3. 开 RLS | ALTER TABLE ... ENABLE ROW LEVEL SECURITY; | 表不再对匿名全开 |
| 4. 写策略 | 用 auth.uid() = user_id 限定行；敏感表不给匿名读 | 登录用户只看到自己的数据 |
| 5. 查密钥 | 前端只留 publishable/anon；service_role 移到服务端 | 客户端 bundle 搜不到 service_role |
| 6. 查存储 | 护照 / 合同 / 照片 bucket 设为 private，用签名 URL | 匿名不能列举 / 下载 |
| 7. 测匿名 | 退出登录，curl 请求 ?select=* | 返回 401 / 空，不返回数据 |
| 8. 轮换 / 通知 | 若已泄露，轮换密钥、看日志、评估通知 | 有记录、有整改 |
查 RLS 的 SQL：
select schemaname, tablename, rowsecurity
from pg_tables
where schemaname = 'public'
order by rowsecurity, tablename;
匿名测试：
curl "https://.supabase.co/rest/v1/profiles?select=" \
-H "apikey: " \
-H "Authorization: Bearer "
如果退出登录还能返回数据，这张表就是公开的。别用 using (true) 糊弄报错，那等于把门锁拆了让 App 跑起来。
八、给不同角色的建议
| 角色 | 现在做什么 | 别做什么 |
|---|---|---|
| 非技术创始人 | 上线前做 RLS / 密钥 / 存储三项检查；找安全顾问复核 | 以为 “有登录框” 就等于数据安全 |
| 开发者 | 把 RLS 策略写进 migration；加匿名读测试到 CI | 把 service_role 塞进前端 |
| 平台 | 默认开 RLS；发布前扫描；高危配置阻断 | 只用条款把责任推给客户 |
| 企业采购 | 把 vibe-coded 应用纳入安全评审 | 让业务部门直接上线处理 PII 的应用 |
【常见问题】
问题 1：Lovable 大量应用暴露敏感数据，是 Lovable 被黑了吗？
回答 1：不是。Crissy Field 的调查指向 Lovable 生成的 App 在 Supabase 数据库上缺少 RLS 配置，而不是 Lovable 平台本身被入侵。研究人员只用了网站正常发给浏览器的公开 key 和只读请求，没有利用零日漏洞；问题在于应用把数据库 “默认开放” 了。
问题 2：为什么 Supabase 的 anon key 公开了，数据就会被看光？
回答 2：anon/publishable key 本来就是设计给浏览器用的，它只代表 “未登录访客”；能否读数据取决于 RLS 策略。RLS 没开时，anon 角色没有行过滤，任何人拿页面里的 key 请求 profiles?select= 就能拉走整张表。真正的秘密不是 key，而是你有没有写 RLS 策略。
问题 3：用 Lovable 做的应用，怎么快速检查有没有暴露敏感数据？
回答 3：先跑 pg_tables 查 rowsecurity，所有 public 表都应为 true；再退出登录，用页面里的 anon key curl 请求 ?select=，如果还能返回数据，就是暴露。重点查 profiles、users、orders、payments、tickets 和 Storage bucket；发现暴露就开 RLS、写按用户过滤的策略、把 service_role 移到服务端。
问题 4：Lovable 说配置责任在创建者，这个责任到底该由谁承担？
回答 4：法律上要分数据控制者 / 处理者，平台上很难一刀切；产品上双方都有责任。Lovable 应该默认开 RLS、发布前扫描、对高危配置阻断；创建者必须在上线前做安全配置。把 “无代码” 当成 “无责任”，才是这次 Lovable 数据暴露事件里最危险的误解。
【参考资料】
[2026-11-15]（Lovable Leak Exposes Passports and 200K User Messages）Tech Bytes
[2026-11-14]（Lovable AI platform lets thousands of apps expose passport data and private messages）Grafy News
[2026-11-14]（Lovable Study: 30% of Checked Apps Left Email Records Open）FourWeekMBA
[2026-11-14]（Lovable-Apps legen sensible Daten offen）Trending Topics
[2026-11-13]（Lovable Data Leak 2026: 24,664 AI Apps Exposed 80,000+ User Records via Supabase）DEV Community
[2026-11-09]（Your Lovable app shows everyone's data. Here's the 10-minute Supabase RLS fix）DEV Community
[2026-11-05]（Vibe-coded app data exposure — Lovable, Bolt, Replit, Base44 pattern issues）Vibe Coding Security
[2026-11-04]（Apps built on Lovable AI expose passport details and 200,000 chat messages）Cybernews
[2026-11-04]（Built With a Sentence, Readable by Anyone: Crissy Field Finds Passports, Payments and 200000 Chats Open in Lovable Apps）al-ice.ai
[2026-05-11]（38 万应用暴露、2000+ 应用泄密，AI 编程把 “内网” 变公网）36 氪
免责声明
本文基于 Crissy Field/Handelsblatt 报告及 Cybernews、Grafy、FourWeekMBA、DEV Community、36 氪等公开报道整理。报告明确说明：30% 不是确认泄漏率，Common Crawl 样本不代表全部 Lovable 应用，且未确认数据被滥用；文中已区分 “平台被攻破” 与 “客户配置错误”。RLS 修复建议为通用安全实践，不构成法律意见；如涉及欧盟 / 加州用户或个人数据泄露，请按 GDPR/CCPA 及当地法规评估通知、整改与罚则。