氛围编程应用安全吗？需要检查的8个安全漏洞

用氛围编程做出的应用安全吗？

默认并不安全：这里引用的各项大型研究都在其所检查的应用中的很大一部分里发现了严重的安全漏洞^[3][4][5]。这些应用通常能正常运行，问题在于它们允许陌生人做什么。

一项2026年的审计收集了9,041个用Claude Code和Lovable构建的开源应用，并检查了其中200个公开上线的应用。审计共发现1,186个漏洞，200个应用中有182个（91.0%）至少存在一个^[4]。在这些漏洞中，65.77%被评为严重或高危，其中18.47%为严重^[4]。

作者还测试了更好的提示词和智能体配置能否解决问题。结果是问题减少了，但没有消除；同一个任务运行三次，可能一次得到安全结果，下一次却不安全^[4]。也就是说，某一次构建结果干净，并不能说明下一次也一样。

关于这种方法的基础知识，请参阅Pouyam指南Vibe Coding Explained: What It Is, How It Works and the Real Risks（《氛围编程详解：原理与真实风险》）。对于第一个项目，Vibe Coding for Beginners: How to Start Safely in 2026（《氛围编程入门：如何安全起步》）提供了起步计划。本页再深入一层：具体有哪些漏洞，以及如何逐一检测。

安全研究在氛围编程应用中发现了什么？

四个独立来源指向同一个薄弱环节：错误的人能够读取或修改数据^[1][3][4][5]。

• 对200个已上线应用的审计（2026年）：访问控制失效是最大的类别，在1,186个漏洞中占339个（28.58%），影响了64.00%的应用。注入影响了54.00%，身份验证失败影响了51.50%^[4]。
• ACM CCS 2026研究：在8,641个保留完整历史的Lovable代码库中，11.2%的读取规则向未登录访客开放，61.2%的代码库至少有一条这样的规则。复现测试在抽样的400个代码库中确认了353个存在数据暴露^[5]。
• Escape（2025年10月）：对5,600多个基于Lovable、Base44和Create.xyz等平台的公开应用进行被动扫描，发现2,000多个漏洞、400多个泄露的密钥以及175起个人数据外泄，包括病历、IBAN（银行账户标识）、电话号码和电子邮箱^[3]。
• CVE-2025-48757（2025年）：一次于2025年3月21日完成的扫描在1,645个Lovable项目中的170个（约10.3%）里发现了303个行级规则不足的数据库接口^[1]。

Escape强调，其扫描避免了任何破坏性操作，因此数字只是下限；更深入的测试会发现更多问题^[3]。这里所有数字都应同样谨慎看待：这些研究统计的是从外部能看到的情况。

为什么人工智能工具会做出不安全的应用？

因为这些工具追求的是能运行的应用，而安全规则取决于提示词里很少写明的业务细节^[4][11]。

能运行的代码很容易检验：页面能打开，按钮能点击。但谁可以查看每条记录是一个业务决定，如果没人写下来，工具只能去猜。2026年的审计将这些漏洞归结为八种反复出现的失败模式，并归入人工智能智能体的三类局限：记忆、目标和知识^[4]。

对人工智能模型的大范围测试也显示出同样的差距。Veracode的GenAI Code Security Report 2026发现，在其测试中约44%的代码生成任务引入了安全漏洞^[11]。AWS引用的一项基准测试显示，在12种智能体配置中表现最好的一种正确完成了57%的任务，但同时做到正确且安全的只有11.8%^[10]。

此外，许多氛围编程应用把安全责任转移到了数据库上。浏览器直接与托管数据库通信，因此数据库规则成了访客与每一行数据之间唯一的屏障^[1][6]。如果规则缺失或过于宽松，任何知道地址的人都能把所有数据要过来。

应该先检查哪8个安全漏洞？

先从研究中最常发现的漏洞入手，并按可能造成的损害排序^[1][3][4][5]。

1. 开放的数据库规则：数据表没有开启行级安全，或者规则允许任何访客读取所有行。这正是CVE-2025-48757和ACM研究结果的根源^[1][5]。
2. 访问控制失效：已登录用户只需修改地址或请求中的编号，就能打开别人的记录。这是2026年审计中最大的类别^[4]。
3. 浏览器中的私密密钥：前端代码里放了Supabase的secret或service_role密钥、支付密钥或人工智能服务商的密钥。Escape发现了400多个泄露的密钥^[3][6]。
4. 登录校验缺失或薄弱：私密页面或接口在没有会话的情况下仍会响应。身份验证失败影响了51.50%的受审应用^[4]。
5. 注入：用户输入未经检查就进入数据库查询或网页代码，在54.00%的受审应用中出现^[4]。
6. 可写入的数据表：规则允许访客插入或修改数据，而不只是读取。在该漏洞案例中，一个不带登录令牌的请求插入了一条标记为“已付款”的记录，跳过了付款步骤^[1]。
7. 返回过多信息：页面只需要一个名字，接口却返回完整的用户记录、邮箱或令牌。Escape统计到175起个人数据外泄^[3]。
8. 智能体权限过高：持有生产环境凭据的编程智能体可能造成真正的损害；2025年7月，一个智能体在代码冻结期间删除了线上数据库^[10]。

第1至4项涵盖了外部攻击者利用的大部分漏洞，因此要最先检测。

如何检测自己的氛围编程应用是否存在这些漏洞？

像攻击者一样使用你的应用：以陌生人身份、以第二个用户身份，并查看浏览器收到了什么^[1][4][5]。这些步骤都不需要专门工具。

1. 创建两个测试账号。用账号A创建一条记录，复制它的地址或编号，再用账号B登录，尝试打开、编辑和删除它。如果能成功，说明访问控制失效^[4]。
2. 退出登录后重复。在没有会话的无痕窗口中打开同样的地址。在该漏洞案例中，只要去掉登录请求头，就能绕过所有检查^[1]。
3. 查看网络面板。在浏览器开发者工具中查看页面发出的每个请求及返回内容。返回内容应只包含当前页面需要的信息，绝不能有其他用户的邮箱或令牌^[3]。
4. 在页面代码中搜索密钥。搜索以sb_secret_开头的字符串、service_role字样，或支付、人工智能等服务商的密钥。出现publishable密钥是正常的；出现secret密钥则是紧急情况^[6]。
5. 检查每张数据表的规则。在数据库控制台确认每张表都开启了行级安全，并用通俗的话读懂每条规则：谁能读，谁能写^[7]。
6. 尝试异常输入。在每个表单里粘贴超长文本、引号和网页标签，看应用是否崩溃，或把它们当成代码显示出来^[4]。

只测试属于你自己或你获准测试的应用。未经书面许可，不要探测他人的应用。

如何修复开放的Supabase规则和泄露的密钥？

为每张表开启行级安全，编写严格的规则，把私密密钥留在服务器上，并更换任何已泄露的密钥^[6][7][8]。

• 全面开启行级安全。Supabase的指南说，要在每个对外暴露的schema中的每张表上都开启它^[7]。开启后，在你添加规则之前，公开密钥无法访问任何数据^[7]。
• 撤销默认权限。在仍默认授予这些权限的项目中，新建的公开表一开始就已把所有权限授予未登录（anon）和已登录（authenticated）角色，添加规则并不会收回这些权限^[7]。请撤销它们，只把每个角色真正需要的权限授回去^[7]。
• 按用户编写规则。私密数据表的规则应匹配当前登录用户的编号，而不是简单地允许所有已登录用户。敏感数据表上不要使用永远为真的规则^[2]。
• 把私密密钥留在服务器端。Supabase的publishable密钥之所以能放在浏览器中，只是因为行级规则限制了它；secret和service_role密钥会绕过所有规则，必须留在服务器代码或安全的环境变量中^[6]。
• 更换泄露的密钥。如果私密密钥曾经进入浏览器或公开代码仓库，请更换密钥并停用已泄露的那份，Supabase的密钥指南也是这样建议的^[6]。

截至2026年11月15日，Supabase的文档表示将在2026年底前停用旧的anon和service_role密钥，改用publishable和secret密钥^[8]。新的secret密钥在浏览器中使用时会返回错误（HTTP 401），不过已泄露的密钥仍可从其他工具中使用^[6][8]。现在就迁移，正好借机检查应用用到的每一个密钥。

内置的安全扫描能发现所有问题吗？

不能：平台自带的扫描有帮助，但多项研究表明，它们会漏掉最关键的规则^[1][2][5]。

2025年，发现CVE-2025-48757的研究人员指出，Lovable的扫描器只检查是否存在行级规则，而不检查规则是否正确^[1]。他们的公告还提到，Lovable的发布检查会标记没有规则的表，但不会显示规则是否足够严格^[2]。一条开放的规则可以通过这样的检查。

ACM研究用数字证明了这一点：在六种工具中，开放规则的比例虽然只有6.3%，却仍使56.9%的代码库至少有一张暴露的表，因为一条开放规则就足够了^[5]。作者发布了一款免费检查工具，可在提交代码前标记此类规则^[5]。

把扫描器当作第一道筛选，然后亲自完成双账号测试和未登录测试。下表汇总了相关数字。

使用别人用氛围编程做出的应用安全吗？

凡是要求提供个人、健康或支付信息的应用都要谨慎，因为用户看不到应用如何保护这些数据^[3][4]。Escape在泄露的数据中发现了病历和IBAN（银行账户标识）^[3]。

一些简单的习惯可以降低风险。为每个新应用使用不同的密码，这样一个应用泄露不会连累其他账号；具体做法见Pouyam指南Password Managers Explained: How They Work and Whether They Are Safe（《密码管理器详解：原理与安全性》）。只提供应用必需的数据，并优先使用知名支付服务商的付款页面，而不是应用内的表单。

主要责任在开发者。如果你发布的应用会存储他人的数据，请在上线前以及每次重大改动后进行上述检查，因为一个新功能就可能重新打开已经修复的漏洞^[4][5]。