Vibe 编码安全：我们在 AI 生成应用中检查的问题

Vibe 编码安全主要关注 AI 生成应用遗漏的内容：每个记录上的服务器端授权、客户端之外的密钥、锁定的数据库规则、经过验证的输入、安全的支付 webhook 和速率限制。在发布之前审查这些信任边界，因为应用看起来可能已经完成，但任何登录用户都可以读取所有人的数据。

这是我们从原型到生产工作的检查清单级别。有关整体加固顺序，请参阅如何将 Lovable 或 v0 原型转化为生产应用程序。对于代理，请参阅仅使用 vibe-code 工具构建代理的限制。在这里，我们列出了在 AI 构建的 Web 和移动应用中寻找的具体问题，这些问题基于常见的信任边界模式和 ImadDhin 门户实现。这里没有任何关于违规统计数据的声明。

为什么 AI 生成的应用存在可预测的漏洞

AI 编码工具经过优化，可以生成在您尝试时能正常工作的东西。当您尝试某项功能时，安全属性大多是不可见的。显示您自己订单的页面看起来与服务器是否检查所有权或仅仅返回浏览器请求的任何订单 ID 相同。

构建者也以单个用户（通常是所有者）的身份进行测试，拥有完全访问权限。每个流程都有效，因为从未被拒绝。当出现权限错误时，最快的解决提示通常是放宽规则，而工具也会照做。

生成的代码还继承了教程和入门模板中的模式，其中密钥位于客户端配置中，数据库规则为了方便而保持开放。这些模式对于演示来说没问题，但对于客户来说是错误的。

团队对 AI 生成代码安全有哪些误解？

大多数错误将平台、界面或 AI 工具本身视为安全审查。常见的错误包括：

• 假设托管平台或后端即服务默认使应用程序安全
• 在界面中隐藏按钮并将其视为授权
• 询问同一个 AI 工具其代码是否安全并接受其答案作为审查
• 放宽数据库规则以修复权限错误而不是修复查询
• 计划在发布后进行安全审查

平台提供了良好的构建块，但配置和授权逻辑由您负责。审查必须由寻找故障的人员进行，而不是由编写代码的工具进行。

vibe 编码安全检查清单包含哪些内容？

该检查清单涵盖了八个信任边界，从身份验证到操作，每个项目都指明了一个应仔细验证的边界。授权之所以排在首位，是因为 OWASP Top 10 中的 A01_2025-Broken_Access_Control/ 位于榜首。

身份验证和账户

• 密码重置和电子邮件验证流程不能被重放或跳过
• OAuth 重定向 URL 仅限于已知域
• 管理员等角色来自服务器控制的来源，绝不能来自用户可以编辑的配置文件字段
• 会话过期，注销会使应失效的内容失效

每条记录的授权

• 每次读取和写入都在服务器或数据库规则中检查所有权或租户身份
• 更改请求中的 ID 不能返回或修改其他用户的记录
• 管理员路由和 API 端点受服务器端保护，而不仅仅是隐藏在导航中
• 列表端点按当前用户或租户进行过滤，而不仅仅是按页面显示的内容进行过滤

数据库和存储规则

• 行级安全或等效规则在每个公开的表或集合上启用
• 没有规则允许为了方便而进行无限制的读取或写入
• 创建规则验证新记录的形状和所有权
• 文件存储桶有自己的规则，不允许公开列出

对于 Supabase 项目，这是一个独立的主题，涵盖在AI 构建应用中的 Supabase 行级安全错误中。

密钥和配置

• 客户端代码或公共环境变量中没有服务角色、管理员或支付密钥
• 提交的文件（包括历史记录）中没有密钥
• 生产源映射不暴露服务器逻辑或密钥
• CORS 受限制，并设置了安全头

输入、输出和 AI 功能

• 每个输入都有服务器端验证，而不仅仅是表单中
• 渲染为 Markdown 或 HTML 的用户内容经过净化
• 文件上传检查类型和大小，并存储在 Web 根目录之外
• 获取 URL 的功能无法访问内部网络地址，这是经典的服务器端请求伪造风险
• 模型输出被视为不可信，未经检查不能触发操作
• 模型提供商密钥仅在服务器上使用

支付和权益

• 价格和计划 ID 在服务器上设置，绝不从客户端获取
• Webhook 签名在任何处理之前都经过验证
• Webhook 处理程序是幂等的，因此重试事件不会两次授予访问权限
• 访问权限从经过验证的支付事件中授予，而不是从到达成功页面中授予

滥用和成本

• 登录、注册、密码重置和 AI 端点的速率限制
• 配额和信用计数器原子更新
• 公共表单具有与其风险成比例的机器人保护

依赖项和操作

• 每个添加的包都存在，是预期的包，并且得到维护
• 调试路由、种子端点和测试账户已删除
• 显示给用户的错误不包含堆栈跟踪或查询
• 安全相关事件（例如登录、角色更改和管理员操作）在不包含密钥或不必要个人数据的情况下进行日志记录

如何对 AI 构建的应用进行安全审查？

分四步进行：简短的威胁模型、外部测试、按影响范围排序的修复，以及保持修复到位的自动化检查。从威胁模型开始：应用程序持有哪些数据，谁应该看到它，攻击者想要什么，以及哪些操作会花费金钱。一个小时的威胁模型可以集中其余的审查。

然后像外部人员一样进行测试。创建两个普通账户，并尝试通过界面和直接通过 API 读取、更改和删除彼此的数据。在注销状态下使用公共客户端密钥查询数据库。在构建的客户端包中搜索任何看起来像密钥的东西。重放支付 webhook。快速多次发送相同的请求。这些测试比单独阅读代码能发现更多实际问题。

按影响范围修复：首先是暴露的密钥和开放的数据库规则，因为它们会同时影响所有用户；然后是授权漏洞；然后是支付；然后是滥用限制和加固。轮换任何曾经暴露过的密钥，即使是短暂暴露，而不仅仅是从代码中删除。

最后，让修复生效。将跨账户测试添加到您的自动化套件中，将规则文件置于审查之下，并向存储库添加密钥扫描，这样下一个 AI 生成的更改就不会悄悄地重新打开相同的漏洞。

安全审查的成本以及何时可以放宽要求

审查在发布前需要几天时间，并且会影响一些依赖开放访问的功能，其深度应与所涉及的数据和金钱相匹配。严格的数据库规则有时会破坏依赖开放访问的功能。这种破坏是有用的：它显示了哪些查询依赖于漏洞。修复查询比恢复开放规则需要更多的工作，而且这是唯一能持久的修复。

对于大多数原型来说，彻底的审查会使发布延迟几天，而不是几个月。另一种选择是在客户信任应用程序并提供数据后发现相同的问题，届时修复还需要通知、轮换和清理。

并非所有发现都值得付出相同的努力。一个内部使用的带有测试数据的原型所需的审查比一个接受支付的公共应用程序要少。将审查的深度与所涉及的数据和金钱相匹配。

我们在自己的规则和代码审查中看到的模式

这些是来自 ImadDhin 门户配置和建议的审查检查的代码级观察，而不是关于客户端事件的声明。

门户的数据库规则默认拒绝访问，没有包罗万象的规则。聊天会话、消息、保存的内存和使用记录完全拒绝客户端访问，仅由服务器路由处理。几个公共接收集合允许创建但不允许读取、更新或删除，并带有验证函数检查每个新记录的形状。

一个有启发性的失败模式是接收规则接受任何创建，因为服务器通过客户端 SDK 写入该集合。数据库规则无法区分使用客户端 SDK 的服务器和浏览器，因此为允许服务器进入而编写的规则会允许所有人进入。将这种模式视为一个发现：使用管理凭据从服务器写入并拒绝客户端写入，或者添加与其他集合相同的形状验证。

使用计数器是第二种模式。一个计数器在单独的步骤中读取当前计数然后写入递增值，而不是在事务中，这使得两个并发请求都通过了限制检查。对于少量免费额度，暴露的风险很小，但同样模式保护的付费信用余额是一个真正的漏洞，这正是通过快速审查的代码类型。

服务器密钥在服务器上运行时解析，首先来自环境配置，然后来自密钥管理器，并且没有使用公共前缀。部署忽略规则是一个有用的后盾，但更强的习惯是将凭据文件完全放在存储库之外，这样单个配置错误的规则就不会暴露它们。

哪些测试能发现 AI 构建应用中的安全漏洞？

• 以用户 B 身份登录，并通过 API 请求用户 A 的记录 ID
• 在注销状态下使用公共客户端密钥查询每个表或集合
• 在生产包和源映射中搜索看起来像密钥的字符串
• 重放支付 webhook 并确认访问仅授予一次
• 编辑您的个人资料以添加管理员角色并检查它是否无效
• 在配额限制下发送并行请求并确认其保持不变
• 将脚本标签粘贴到其他地方渲染的文本字段中

何时可以采用更轻量的安全设置？

如果应用程序是一个带有虚假数据的内部原型，最简单的安全措施是不要公开它：在准备好真实数据之前，将其置于身份验证或私有网络之后。

如果应用程序只需要登录和几个页面，请使用您平台的托管身份验证和最严格的默认规则，并且在需要之前避免自定义角色。功能越少意味着需要审查的信任边界越少。有时最好的安全修复是删除没有人使用的功能。

在客户发现漏洞之前完成审查

运行检查清单，使用两个账户和一个已注销的客户端进行测试，并按影响范围进行修复。如果您希望我们为您完成审查和修复，请参阅 ImadDhin 的vibe-code 救援实践，通过项目简介发送您的存储库详细信息，或预订30 分钟通话。

如何在评估之前探索网络安全风险？

交互式网络安全实验室使用合成请求来演示结账操作、伪造支付事件、租户隔离、暴露的密钥和 AI 工具批准。触发故障，启用一个防护措施，然后重播相同的事件，然后再启用其余的。保护价格并不能确立订单所有权，将密钥移动到服务器并不能撤销暴露的副本。

网络安全展示中的 Xion 是允许、阻止和批准决策的概念演示。它不监控或保护您的应用程序。对于您的平台，证据必须来自对实际授权、支付和数据边界的范围测试。使用实验室来确定审查问题，然后在相关环境中验证实施。