AI编程安全实践：为氛围编码应用构建三层防御体系 1. 项目概述为“氛围编码”应用构建安全基线如果你和我一样是个喜欢用 Cursor、Copilot 这类 AI 编程工具快速构建原型的开发者那你一定对“氛围编码”不陌生。所谓“氛围编码”就是给 AI 一个大致的产品描述和氛围让它帮你生成大部分代码你只需要微调和整合。这种方式能极大提升开发速度让想法在几小时内变成可运行的 Demo。但速度的背后往往隐藏着巨大的安全隐患。卡内基梅隆大学的研究一针见血AI 生成的代码61% 在功能上是正确的但只有 10.5% 是安全的。这意味着我们快速搭建起来的应用很可能是一个满是漏洞的“纸房子”。这正是benavlabs/vibe-check这个项目要解决的问题。它不是一个复杂的漏洞扫描器而是一套专门为“氛围编码”工作流设计的、可操作的安全检查清单。它的核心目标非常务实在你用 AI 生成代码的同时就植入安全规则防止漏洞被写进去在项目完成后再用 AI 帮你做一次全面的安全审计最后再补上一些 AI 目前还无法完全替代的人工检查。这套组合拳旨在将我们从“只求跑通”的思维惯性中拉出来在享受 AI 高效的同时为应用建立起最基本的安全防线。无论你是独立开发者、初创团队的技术负责人还是任何使用 AI 辅助编程的人这套方法都能帮你避免那些已经让无数真实公司“翻车”的低级安全错误。2. 核心设计思路三层递进式防御体系vibe-check的设计哲学非常清晰安全不是一次性事件而应贯穿于编码、审计和验证三个阶段。它的三层结构没有重叠各司其职共同构成一个从预防到检测再到补救的完整闭环。2.1 第一层实时防护规则第一层是AGENTS.md文件。你可以把它理解成给 AI 编程助手定制的“安全编码规范”。它的工作原理是“预防优于治疗”。当你把这份文件复制到项目根目录并提交后像 Cursor、Claude Code 这类工具在生成代码时会主动读取并遵循其中的规则。例如规则里会明确要求“所有数据库查询必须使用参数化查询或 ORM 的安全方法禁止拼接 SQL 字符串。” 这样当 AI 为你生成一个用户登录的 API 接口时它就会自动写出db.execute(“SELECT * FROM users WHERE email ?”, email)这样的安全代码而不是f”SELECT * FROM users WHERE email ‘{email}”这种存在 SQL 注入风险的代码。注意不同 AI 工具读取的规则文件名可能不同。对于 Cursor、Copilot 等它们通常认AGENTS.md而 Claude Code 则需要CLAUDE.md。最稳妥的做法是两个都复制过去。这个文件的内容是静态的、可读的规则列表它不执行任何扫描只是静静地躺在那里潜移默化地影响 AI 的代码生成行为。2.2 第二层自动化 AI 安全审计第二层是AI-CHECKLIST.md。如果说第一层是“边写边查”那么这一层就是“写完总检”。它是一个精心设计的提示词用于指挥你的 AI 助手对整个代码库进行一次系统性的安全审计。这个过程是交互式和自动化的你只需要将整个提示词发给 AI例如在 Cursor 的 Chat 界面粘贴AI 就会像一名初级安全工程师一样开始工作。它的审计流程设计得非常细致调查AI 会逐一检查 17 类常见漏洞在代码库中的存在情况。报告对每个漏洞类别AI 会生成一份调查报告指出在哪些文件、哪些行发现了疑似问题。修复计划针对发现的问题AI 会制定具体的修复方案。实施修复AI 会直接修改代码应用修复方案。验证AI 会说明如何验证修复是否有效例如运行某个测试或检查某个配置。所有审计和修复的过程记录、报告都会生成在一个新的security/目录下便于你后续回顾和追踪。这个过程极大地降低了手动进行代码安全审查的门槛和耗时。2.3 第三层关键人工验证第三层是manual-checklist.md。这一层承认了当前 AI 的局限性——有些安全问题无法仅通过静态代码分析发现必须通过实际运行和交互来验证。例如“能否通过修改 URL 中的用户 ID 参数来访问他人数据” 这类逻辑漏洞需要模拟攻击者的行为进行测试。这份清单聚焦于最高风险、最常导致实际安全事件的项目。它的设计很人性化如果你时间紧迫至少完成前 5 项检查。根据项目背后的研究这前 5 项漏洞正是导致列表中每一个真实公司出现安全问题的直接原因。它们并不需要高深的攻击技术但破坏力极强。3. 漏洞清单深度解析与实操要点vibe-check聚焦的 17 项漏洞并非凭空想象而是基于对数千个“氛围编码”应用的实际扫描和真实安全事件分析得出的。理解每一项背后的原理和危害能帮助我们在使用清单时更有针对性。3.1 五大“致命”漏洞详解这五项被标记为“Critical”是因为它们极其常见且破坏性极大往往直接导致数据泄露或服务瘫痪。数据库配置错误这特指像 Supabase 或 Firebase 这类后端即服务中未正确配置行级安全策略。默认情况下这些服务的数据库可能是完全公开可读写的。AI 在生成代码时很容易只关注前端如何调用 API而忘记在后端设置“哪个用户能访问哪条数据”的规则。实操要点每次创建一张新表第一件事就是去 BaaS 的控制台编写 RLS 策略。一个简单的策略模板是CREATE POLICY “用户只能操作自己的数据” ON your_table FOR ALL USING (auth.uid() user_id)。未受保护的 API 路由AI 可能会为你快速生成一系列 RESTful API 端点如GET /api/users、POST /api/posts。如果这些路由没有添加身份验证中间件那么任何人都可以直接访问导致数据泄露。注意事项确保每一个处理敏感数据或执行写操作的 API 路由其处理函数的第一行都是身份验证检查。例如在 Express.js 中app.get(‘/api/profile’, authenticateToken, handler)。提交密钥到代码仓库这是最经典的错误。.env文件包含数据库密码、API 密钥等机密信息一旦被git add并推送到 GitHub这些秘密就公开了。AI 在生成.env.example或相关配置代码时很少会主动提醒你将其加入.gitignore。避坑技巧在项目初始化后立即创建.gitignore文件并加入.env、*.env.local、node_modules等条目。可以使用git check-ignore .env命令来验证.env是否已被忽略。失效的访问控制也称为不安全的直接对象引用。典型场景是前端通过/api/user/123获取用户 123 的数据但后端没有验证当前登录用户是否就是 123。攻击者只需将 URL 中的 123 改为 124就能窃取他人数据。检查方法手动测试。登录你的应用后在浏览器开发者工具的网络标签页中找到获取个人数据的请求尝试修改请求参数中的 ID重放请求看是否能返回其他用户的数据。前端代码中的秘密 API 密钥有时为了快速实现功能开发者或 AI可能会将用于调用第三方服务的 API 密钥直接写在前端 JavaScript 代码中。这意味着任何访问你网站的用户都能通过查看网页源代码轻松获取这个密钥从而滥用你的第三方服务配额。核心原则所有密钥都必须保存在后端。前端需要调用有鉴权的第三方服务时应该通过自己的后端服务器做一个代理转发由后端添加密钥并转发请求。3.2 其他高风险漏洞精讲SQL 注入与跨站脚本这两项是 OWASP Top 10 的常客。对于 SQL 注入关键动作是永远不使用字符串拼接来构造 SQL 语句而是使用参数化查询或 ORM。对于 XSS关键动作是对所有渲染到 HTML 页面的用户输入进行转义或净化。现代前端框架如 React、Vue 默认提供了部分防护但当你使用dangerouslySetInnerHTML或v-html时危险就出现了。缺少速率限制AI 生成的登录、注册、短信验证码接口通常没有速率限制。这允许攻击者进行暴力破解或通过大量请求耗尽你的资源。实现建议使用像express-rate-limit这样的中间件为敏感端点轻松添加限制例如每分钟每个IP最多尝试登录5次。“投毒”包这是一个针对 AI 开发者的新型威胁。攻击者会上传名称与流行包相似如lodashvslodashh的恶意包到 npm 等仓库。AI 在根据你的描述生成package.json时可能会错误地引用这些恶意包。防范措施仔细审查 AI 生成的package.json中的每一个依赖包名确保其拼写完全正确。安装依赖后可以运行npm audit进行基础检查。4. 完整实操流程与核心环节实现让我们以一个典型的 Node.js Express Supabase 的“氛围编码”项目为例从头到尾走一遍vibe-check的流程。4.1 环境准备与规则植入假设你的项目名为my-vibe-app已经用 AI 生成了基础框架。# 进入你的项目目录 cd path/to/my-vibe-app # 从 vibe-check 仓库克隆或下载 AGENTS.md 和 AI-CHECKLIST.md 文件到本地。 # 这里我们假设你已经下载好了这两个文件放在当前目录。 # 步骤1复制安全规则到项目根目录 cp /path/to/downloaded/AGENTS.md ./AGENTS.md cp /path/to/downloaded/AGENTS.md ./CLAUDE.md # 为 Claude Code 准备 # 立即将这两个文件加入版本控制 git add AGENTS.md CLAUDE.md git commit -m “feat: add AI security coding guidelines”现在当你后续使用 Cursor 的“Composer”功能或 Copilot 的代码补全时它们生成代码的“风格”就会受到AGENTS.md中安全规则的约束。这是一个一劳永逸的预防措施。4.2 执行 AI 自动化安全审计接下来我们进行深度检查。打开你的 AI 编程助手以 Cursor 为例在 Chat 界面中你需要做两件事将整个AI-CHECKLIST.md文件的内容粘贴到输入框。在文件内容后面追加一句清晰的指令“请根据上述清单对我的当前项目my-vibe-app执行安全审计。请逐一检查 17 个漏洞类别并按照调查、报告、修复计划、实施修复、验证的流程进行操作。”发送后AI 会开始工作。你会看到它依次列出 17 个检查项。针对每一项如“1. Misconfigured database”它会去查看你的supabase初始化代码或 SQL 迁移文件检查 RLS 是否启用。如果发现 RLS 未启用或策略不完整它会生成一份报告security/01_database_misconfig_report.md说明问题所在。接着它会生成修复计划并直接修改你的supabase/migrations/下的 SQL 文件添加正确的CREATE POLICY语句。最后它可能会建议你运行npx supabase db reset来应用迁移并验证策略是否生效。这个过程会持续一段时间AI 会遍历你的整个代码库。关键观察点你需要关注 AI 对每个漏洞的“验证”部分。它是否提出了可行的验证方法例如对于修复后的 API 认证它是否建议你用curl或 Postman 测试一下带 token 和不带 token 的请求这能反映审计的深度。4.3 人工检查清单执行实录AI 审计完成后打开manual-checklist.md。我们以最重要的前两项为例展示如何手动执行手动检查 1越权访问目标验证用户 A 是否能访问用户 B 的数据。操作在应用中注册两个测试账号userAtest.com和userBtest.com。用userA登录打开浏览器开发者工具F12- 网络Network标签页。在应用中执行一个操作比如“查看我的个人资料”。在网络标签页中找到这个请求通常是GET /api/profile或类似。右键点击该请求 - Copy - Copy as cURL。在终端中粘贴这条 cURL 命令并执行确认能拿到userA的数据。现在尝试攻击。找到请求中可能标识用户的参数比如userId: 1。假设userA的 ID 是 1userB的 ID 是 2。修改 cURL 命令中的参数或将请求在 Postman 中重放将userId改为 2。再次发送请求。预期结果你应该收到一个403 Forbidden或类似的错误而不是userB的数据。如果成功返回了userB的数据说明存在严重的 IDOR 漏洞你需要立即按照 AI 审计报告中的建议修复后端验证逻辑。手动检查 2敏感文件泄露目标确认.env等配置文件不会通过 Web 服务器被直接访问。操作启动你的开发服务器如npm run dev。打开浏览器直接访问http://localhost:3000/.env。尝试访问其他可能存在的配置文件如http://localhost:3000/config/production.json。预期结果你应该看到404 Not Found或403 Forbidden页面而不是文件内容。如果.env文件内容被直接显示说明你的静态文件服务配置有严重问题。你需要检查 Express 的express.static中间件配置确保它没有将根目录或敏感目录暴露出去。一个常见的错误是app.use(express.static(‘.’))会暴露整个项目根目录。5. 常见问题与排查技巧实录在实际使用vibe-check的过程中你可能会遇到一些典型问题。以下是我在多次实践中总结的排查技巧。5.1 AI 审计不深入或“幻觉”问题问题描述AI 在执行AI-CHECKLIST.md审计时对某些复杂漏洞如逻辑性的 IDOR检查流于表面只是简单回复“未发现该问题”或提出的修复方案存在“幻觉”即代码语法正确但逻辑错误。排查与解决提供更多上下文在发送审计指令前可以先让 AI 熟悉你的代码结构。例如先发送“请先分析本项目my-vibe-app的主要技术栈、目录结构和核心业务逻辑。” 等 AI 理解后再发送完整的审计指令。分模块审计不要一次性审计整个项目。可以按功能模块拆分指令例如“现在请专门审计项目中与用户认证和授权相关的所有代码文件重点检查AI-CHECKLIST.md中的第 2 项API 路由保护和第 4 项访问控制。”质疑与追问当 AI 给出“未发现问题”的结论时主动追问“你是如何验证/api/user/:id这个端点不存在 IDOR 漏洞的请展示你模拟的测试用例。” 这样可以迫使 AI 展示其推理过程你也能发现其检查的盲区。手动复核关键点对于 AI 标记为“已修复”或“安全”的高风险项目如数据库 RLS、API 认证一定要按照manual-checklist.md的方法进行手动验证。AI 的结论是重要的参考但不能完全替代人的判断。5.2 规则文件不生效问题问题描述已经将AGENTS.md放入项目根目录但 AI 助手在生成代码时似乎并没有遵循其中的规则仍然产生了不安全的代码模式。排查步骤确认文件位置与名称确保文件在项目的根目录下并且名称完全正确。对于 Cursor文件名必须是AGENTS.md注意大小写。可以尝试在 Cursor 中打开该文件看是否能被正常识别和索引。检查规则表述AGENTS.md中的规则需要清晰、具体、可执行。模糊的规则如“确保安全”是无效的。应改为具体的指令如“所有数据库查询必须使用 Prisma ORM 的$queryRaw模板字符串或参数化 API禁止使用字符串拼接。”测试规则触发尝试一个明确的场景。例如在代码编辑器中新建一个文件输入注释“// 创建一个用户登录函数从请求中获取 email 和 password查询数据库。” 然后触发 AI 补全。观察生成的 SQL 查询语句是参数化查询还是字符串拼接。如果仍然是拼接说明规则可能未被加载或优先级不够。工具特定配置某些 AI 工具可能需要额外配置来启用自定义规则。查阅你所用工具的官方文档确认是否有“自定义上下文”、“项目规则”或“系统提示词”相关的设置确保你的AGENTS.md文件被包含在内。5.3 人工检查遇到阻碍问题描述在执行manual-checklist.md的检查时例如测试速率限制不知道如何模拟大量请求或者测试文件上传漏洞时不知道如何制作一个恶意的测试文件。实用技巧速率限制测试使用命令行工具curl配合循环或使用专门的 API 测试工具如 Postman 的 Runner 功能、siege、ab(Apache Bench)。一个简单的 bash 循环命令是for i in {1..20}; do curl -X POST http://localhost:3000/api/login -d “emailtesttest.compasswordguess”; done。观察前几次成功后的请求是否被拒绝返回 429 状态码。恶意文件上传测试绕过扩展名检查尝试上传一个名为shell.jpg.php的文件。如果服务器仅检查最后一个扩展名.php可能会被绕过。制作测试 WebShell创建一个纯文本文件test.php内容为 。这是一个最简单的 PHP WebShell。尝试上传它如果成功并通过浏览器访问该上传地址能显示出服务器信息则存在极高风险。使用专业工具对于更深入的测试可以下载 OWASP ZAP 或 Burp Suite Community Edition 这类渗透测试工具利用其主动扫描功能它们能自动尝试多种文件上传绕过技术。检查安全头使用在线工具或浏览器开发者工具。访问你的应用打开开发者工具 - “网络”标签 - 点击任意一个请求 - 查看“响应头”。检查是否存在Content-Security-Policy、X-Frame-Options、Strict-Transport-Security等关键安全头。也可以使用curl -I https://your-app.com命令来快速查看响应头。5.4 集成到 CI/CD 流程对于追求更高自动化的团队可以考虑将vibe-check的部分能力集成到持续集成流程中。思路预防阶段在 Git 的pre-commit钩子中可以加入一个脚本检查是否有新的.env或*.key等敏感文件被意外添加到了暂存区并予以阻止。审计阶段虽然完全自动化 AI 审计较复杂但可以定期如每周手动触发一次 AI 审计并将生成的security/目录报告作为代码审查的一部分。也可以编写脚本利用像semgrep、bandit针对 Python等静态应用安全测试工具对代码库进行自动化扫描这些工具能捕捉一部分清单中的漏洞如 SQL 注入、硬编码密钥。验证阶段将manual-checklist.md中的关键检查点如前 5 项转化为自动化集成测试。例如编写一个测试用例模拟两个用户互相访问对方的数据断言请求失败。这些测试可以在每次 CI 运行时执行。vibe-check提供的是一套方法论和起点真正的安全是一个持续的过程。它成功地将那些容易被“氛围编码”忽略的基础安全知识转化为了可嵌入工作流的具体动作。记住它的核心警告这份清单能帮你堵上最常见的窟窿但绝不等同于专业的安全审计。当你的应用真正拥有用户和宝贵数据时聘请专业的安全人员进行渗透测试仍然是不可替代的最后一道防线。