Lovable 应用安全检查清单：你的应用安全吗？

Lovable 安全吗？这是否意味着我的应用也安全？

Lovable 表示其支持 SOC 2 和 GDPR 要求，并在信任中心公布了安全文档。这涵盖的是 Lovable 的平台：它的基础设施、访问控制和员工。它不涵盖你应用内部的规则，因为那些规则是你（在 Lovable 的帮助下）写的。

Lovable 的安全扫描会在你每次发布时运行一次快速检查：数据库审查、依赖审计和 MCP 服务器检查。手动启动（Lovable Enterprise 客户可按计划启动）的深度扫描还会审查访问控制、未认证的端点、注入、泄露的密钥、支付、认证和暴露的个人数据。Lovable 自己的文档明确表示，这些工具无法保证完全安全。请把扫描当作烟雾报警器，而不是全面检查。

CVE-2025-48757 是什么？会影响我的应用吗？

CVE-2025-48757 于 2025 年 5 月发布，描述了 2025 年 4 月 15 日及之前由 Lovable 生成的网站中行级安全策略不足的问题，未经认证的攻击者可借此读取或写入数据库表。美国国家漏洞数据库将其列为严重级别，CVSS 3.1 评分 9.3，并注明 Lovable 对此有异议，理由是每位客户应负责保护自己应用的数据。

报告该漏洞的研究员 Matt Palmer 表示，他扫描了 1,645 个项目，在其中 170 个项目中发现了 303 个存在漏洞的端点，并表示 Lovable 于 2025 年 4 月随 Lovable 2.0 推出了安全扫描。无论你如何看待这一争议，实际教训都一样：如果你的应用是在那之前生成的，或者之后你改动过表，请自己检查策略。策略存在，不等于策略正确。

Lovable 安全检查清单应涵盖哪些内容？

如何修复 Lovable 应用中的 Supabase RLS 错误？

RLS 错误分为截然相反的两类，先弄清楚你遇到的是哪一类会很有帮助。

• 权限被拒绝（Postgres 错误 42501，或返回空结果）。RLS 已开启，但没有策略允许该请求。这说明 RLS 在正常工作。请编写能让功能正常运行的最窄策略，例如只允许所有者列等于当前登录用户 ID 的数据行。
• 所有人都能正常访问一切。这是更危险的情况。像 USING (true) 这样的策略，或者没打开 RLS 开关，会让任何用户通过。Supabase 的顾问会标记宽松策略（lint 0024，permissive_rls_policy），以及在 RLS 关闭时仍存在的策略（lint 0007，policy_exists_rls_disabled）。
• 读取用户元数据的策略。Supabase 警告不要基于用户可以自行编辑的元数据编写策略（lint 0015，rls_references_user_metadata）。请改用由你的服务器控制的表，例如团队成员关系表。

当你让 Lovable 修复某条策略后，请重新运行双用户测试。一条让错误消失的提示词，可能是通过放宽访问权限做到的——而这恰恰是你想要避免的故障。

在 Lovable 应用中，哪些密钥可以安全暴露？

Supabase 的文档说明，publishable（anon）密钥可以安全暴露，因为它只能访问行级安全所允许的内容。secret 密钥（包括 service role 密钥）会绕过所有 RLS 策略，绝不能出现在浏览器、已发布的应用或源代码管理中。术语表中关于 anon 密钥与 service role 密钥的条目解释了两者的区别。第三方密钥，例如 Stripe 或邮件服务商的密钥，应放在边缘函数的密钥设置中，而不是应用代码里。参见密钥管理。

线上的 Lovable 应用应该多久复查一次？

每次涉及数据、访问权限或支付的改动之后都要复查，其他方面则按计划定期复查：依赖会出现新的漏洞，密钥应当轮换，新的表也会带来新的策略。这就是为什么安全作为一种习惯，比作为一次审计更有效。在我们的方案中，每一处改动进入生产环境前都会运行安全检查、代码审查和回归测试，并由作者以外的工程师批准。