干了这么多年代码审计我发现一个特别扎心的现象很多人把 Cursor 当成一个“什么都会读”的安全专家结果喂进去一堆代码之后得到的反馈要么是“请确保使用参数化查询”这种教科书式废话要么就是对着无关紧要的变量命名指指点点。真正有价值的审计结论比如“这里存在一个从外部可控输入到 SQL 查询的完整污染链路且辅助函数绕过了统一鉴权”基本很难直接跑出来。原因是 Cursor 这类 AI 审计工具缺少的不是智商而是项目背景。它没有你的业务领域知识、模块边界、信任假设和历史包袱只能基于“通用最佳实践”给你贴标签。这篇文章我不讲虚的专门说清楚怎么在审计前、审计中为 Cursor 正确补充项目背景并给出一套可以照着抄的实战流程。无论你是在审查一个单体老项目还是刚接手一套微服务代码这套方法都能显著减少无效交互让审计结论真正落在代码的“要害处”。1. 代码审计翻倍的底层逻辑Cursor 缺少的不是智商是背景1.1 没有背景的AI审计只会告诉你“记得做权限校验”先做一个对比。假设你丢给 Cursor 一段 UserController.java里面有个 deleteUser 方法全代码片段大概是DeleteMapping(/users/{id}) public Result deleteUser(PathVariable Long id) { return userService.delete(id); }没有任何背景的情况下Cursor 大概率会给出这样的结论“建议增加权限校验防止任意用户删除其他用户。”这句话对不对对但没有用。因为你的真实代码库中这个接口很可能已经被一个全局拦截器保护了真正的问题反而在 userService.delete 内部——它在删除前会做一次“软删除”并回写审计日志而这个回写动作触发了数据库触发器进而把攻击者的输入拼接到了另一个查询里。这才是审计员该盯的点但如果你不给背景AI 永远不会知道那条业务链路。没有背景的审计本质上是“无差别挑刺”。它会把每个常见坏味道都列一遍四平八稳找不到真正的要害。而我们做代码审计要的是在有限时间里找到那条“从源头到汇聚点”的完整数据流而不是二十条泛泛的整改建议。1.2 背景信息如何影响审计结论的“召回率”我习惯把代码审计看成“相关性判断”而不是“规则匹配”。一个漏洞能否被确认取决于三个无关变量代码本身是否危险、运行环境是否允许攻击者触达、业务数据流是否把它带到了敏感操作点。前三者很难通过单文件分析得到答案。这就是背景信息能大幅提升效率的原因。当你告诉 Cursor“这个接口位于网关之后所有请求都会经过 Token 鉴权但白名单路径/api/v3/debug除外”它的筛选范围就立刻缩小。当你说“pendingApproval字段仅应出现在管理员后台业务端不允许读取它”AI 就能从一堆无关的读写操作中揪出越权访问。说白了项目背景是在帮 AI 建立“案件卷宗”。你提供的卷宗越完整它对某个代码位置的判断就越接近一个熟悉该项目的老审计员。拿数据说话我把一套 8 万行的老 PHP 项目拆成“无背景直接审”和“带背景定向审”两组同样问 10 个安全敏感点后者的有效结论命中率从 20% 提到了 70% 以上。这个差距就是背景带来的。2. 动手前先备料这五类背景信息你必须喂给 Cursor2.1 第一类架构与模块边界说明很多人一听到“喂背景”就想到把整个 README 丢进去这其实不够。你要给的是一份“审计导向”的架构说明而不是项目简介。核心要回答几个问题项目分成哪几个主要模块哪些是前端、哪些是后端、哪些是定时任务本次审计目标模块在整体架构中的位置是什么它依赖哪些内部服务、又为谁提供服务模块间的信任关系是什么样的是全部内网可信还是部分边界公网可达举个例子我最近审一个电商系统光说“这是一个微服务项目使用 Spring Cloud”毫无价值。我会这样补充核心模块包括 gateway、user、order、product、payment 和 log。 本次审计重点是 user 服务它对外提供 REST API同时被 order 服务通过内部 Feign 调用。 网关会统一鉴权但 /user/open 路径下的接口允许匿名访问。 内部调用之间没有二次签名验证默认信任内网来源。这段文字 120 个字却把代码审计里最关键的“信任边界”画了出来。Cursor 后续看代码时就明白用户可控输入从哪里进入、哪些内部调用可能是新的攻击入口、哪些位置一旦出现敏感操作就是漏洞。这不比你丢给它一个 5000 字的技术选型介绍强2.2 第二类业务逻辑与信任假设业务逻辑听起来很虚但对审计来说它就是判断“不可信输入”的依据。你需要告诉 Cursor 这些类型的信息系统的用户角色有哪些哪些角色可以操作哪些数据是否存在“租户”“组织”这类数据隔离维度数据权限是按用户 ID 过滤还是按租户 ID 过滤哪些业务数据是机密或敏感的比如身份证、银行卡、手机号。是否存在“越权风险点”的设计预期比如管理员可以查看所有工单但普通用户只能看自己的。我经常在一个项目的.cursor规则里写类似这样的话“本系统所有数据访问必须同时带上tenantId和userId过滤条件任何绕过tenantId的查询都视为越权漏洞。”这句话看着像开发规范但它直接改变了 AI 的审计标准。没有这句话Cursor 可能觉得一个SELECT * FROM orders WHERE user_id ?还挺正常有了这句话它就会追问tenant_id去哪了这条 SQL 是不是漏了隔离条件这就是业务假设的威力。2.3 第三类代码库的“历史包袱”与已知问题成熟项目里有一堆“技术债”比如老接口为了兼容旧客户端不允许改参数、某些公共函数被十几个地方调用导致不能轻易动逻辑、前两年的安全整改已经给某个模块加了补丁但补丁打得很难看。这些历史信息AI 不可能从代码里直接看出来但你又希望它在审计时“别在已经妥协的地方反复纠结也别因为某段代码写得烂就忽略真正可利用的路径”。所以我会整理一个“历史包袱清单”当作背景的一部分喂给 Cursor内容包括哪些接口或模块曾经出过安全事件当时是怎么处理的哪些位置的代码是“有意为之”的高风险写法例如为了兼容老设备某接口被迫在 URL 参数里传手机号。哪些依赖已长期未升级且团队接受该风险这个清单的作用是帮 AI 设定“审计容忍度基线”。我通常还会加一句提示“已知以下位置是历史遗留问题本次不必重复报告但请帮我判断现有缓解措施是否足够。”就这么一句话我少了很多来回扯皮的时间Cursor 也能把注意力放到真正未被发现的盲区上。2.4 第四类依赖、配置与运行环境很多代码审计只看源码忘了配置文件和依赖清单里藏着大量攻击面。Cursor 只看源码时根本不知道这个项目用的是旧版 FastJSON 还是带 CVE 的 Log4j 组件。所以你在准备背景时至少要给以下几样pom.xml、package.json、go.mod这类依赖清单或者其核心片段。配置文件里与安全相关的项数据库连接串、Redis 地址、加密密钥位置、认证方式等。运行时环境信息代码是跑在容器里还是物理机公网出口是否只有网关是否有权限穿越我通常不直接把整个配置文件丢给 Cursor因为噪音太多。我会先人工扫描一遍挑出和信任边界相关的部分再转成精简描述。比如应用通过 Nacos 获取配置数据库账号配置在本地 application.yml。 Redis 仅内网访问端口未暴露公网。 JWT 密钥写入环境变量但在代码中有一个默认值 dev-secret 用于本地开发。这串信息直接引导 Cursor 去检查“默认密钥是否被打包进生产环境”这类问题。没有这段背景它可能连 JWT 密钥在哪个文件都没兴趣翻。2.5 第五类本次审计的具体目标与范围最后一种背景最容易被人忽略也最实用你要告诉 Cursor 这次到底审什么、不审什么。代码审计不等于漫无目的地读代码你需要明确“审计入口”和“审计出口”。我常用的表述格式是本次审计范围用户注册、登录、订单查询这三个接口的完整调用链。 重点关注越权访问水平与垂直、SQL 注入、敏感信息泄漏。 不考虑性能问题、代码风格、非安全的可用性缺陷。别小看这个限定它能让 Cursor 在分析时自动忽略性能优化和魔法值问题把所有推理资源集中到安全问题上。我还习惯把“审计产出格式”也一并说明例如要求它“按危害程度排序每条结论必须包含入口路径、攻击步骤、受影响代码位置、修复建议”。这样它给出的结果就不是一段泛泛而谈的论述而是一份合格的审计报告草稿。3. 三个高效注入姿势从“写提示词”到“建规则”3.1 姿势一会话开场白式的“背景说明书”最直观的用法也是大多数人唯一在用的方式在新建对话时用一段结构化的“背景说明书”作为开场。这个方法操作简单但需要一些套路。我写背景说明书有个固定模板我要对一个 [项目类型] 进行代码审计。 项目背景 - 业务领域... - 技术栈... - 模块划分... - 信任边界... - 已知风险... 本次审计目标[具体目标] 请按以下步骤分析 1. 先理解背景如有疑问可以先提问不要贸然下结论 2. 分析代码时始终结合背景中的信任边界来判断数据流 3. 输出结论时附上相关的代码路径与危害分析。可能有人觉得这样写很啰嗦但实际上它很像你把一个刚入职的同事叫到工位前花三分钟交代清楚“客户是谁、系统怎么分的、哪里碰过壁”。这段时间花得越扎实后面十几次对话就越省力。一个隐藏好处是这种开场白会显著降低 Cursor 的“幻觉率”。我见过太多人上来就贴代码AI 猜不透你的技术栈就开始编造一个合理的假项目背景结果整个审计结论建立在错误假设上。背景说明书把假设条件显性化模型反而更老实。3.2 姿势二用项目规则固化长期背景如果你要在一个项目上长期做多轮审计或者团队成员都使用 Cursor 协作那就不能每次都靠开场白复读背景背景了容易漏也容易不一致。更好的方案是把“不随会话变化”的长期背景放进 Cursor 的项目规则文件里。具体做法是在项目根目录维护.cursor/rules下的规则文件或类似全局指令区域把项目架构、信任边界、敏感区域、已知技术债几类内容固化下来。这样每次打开 Cursor 时它都能自动加载这些背景不用你重复描述。比如我会在规则里写# 项目固有背景 - 本系统为多租户 SaaS数据隔离是第一优先级。 - 所有数据库查询必须带着 tenant_id 条件除 migrate 模块外。 - 网关负责统一鉴权但 /pub/ 前缀匿名可达。 - 历史遗留/v1/user/list 不做分页属于已知问题无需重复报告。 - 安全审计输出必须包含“受影响端点 攻击链路径 修复建议”。固化这些内容的好处是“稳定可复用”坏处是规则一旦写太长会把上下文窗口挤爆所以一定要克制只放“不随时间变化的项目事实”别把业务细节一骨碌全塞进去。定位、常规流程这些适合放在每次对话里说适合放在规则里的只有那些长期有效、所有会话都需要的边界条件。3.3 姿势三让 Cursor 先提问再作答减少跑偏第三个姿势是我最喜欢用的也是被很多人忽略的刻意让 Cursor 在动手审计前先向你提问。这样做有两个原因。第一AI 模型在信息不足时倾向于“编一个最合理的答案”而不是承认自己不懂。你不让它提问它就会假想一套背景然后继续分析。第二审计这件事本身是高度依赖目标的它如果连你关心的是哪条调用链都没搞清后面输出的内容往往空泛且难以复用。我会在提示词末尾直接加一行在开始分析前如果项目背景没有覆盖到以下任一信息请先向我提问 1. 本次审计最关心的数据资产是什么 2. 用户输入能到达哪一层 3. 是否存在不受网关保护的绕过路径实际用下来让 AI 先提 3 到 5 个问题往往能暴露出我准备背景时忽略的信息盲区。有一次它问“这个系统有没有定时任务会以管理员身份读取用户上传的文件” 我当场就愣住了确实有而那条任务链上藏着一个未鉴权的文件读取接口。如果没有这一步那次审计大概率会漏掉一个高危点。4. 实战复盘让 Cursor 找到一处 SQL 注入漏洞4.1 审计对象描述一个“看起来正常”的登录接口下面我会用一套简化但保留核心特征的代码完整演示“补背景 → 审代码 → 追结论”的流程。假设这是一个 Node.js Express MySQL 的老系统登录接口长这样// routes/auth.js const express require(express); const router express.Router(); const db require(../db); router.post(/login, (req, res) { const { username, password } req.body; const sql SELECT * FROM users WHERE username username AND password password ; db.query(sql, (err, results) { if (results results.length 0) { req.session.user results[0]; res.json({ success: true }); } else { res.status(401).json({ success: false }); } }); }); module.exports router;任何有经验的审计者第一眼就知道这是 SQL 注入但问题是在真实项目中这种直白的漏洞通常已经被前人修过或包过一层。为了让演示更贴近现实我给这套代码加几个干扰项项目里有一层db.js做了输入过滤但过滤不完整另有一个safeQuery函数在部分接口被使用但登录接口没有用它。4.2 给 Cursor 的背景包我不会直接把上面的片段丢给 Cursor而是先给它一段“压缩背景”项目是一个旧版 Node.js Express MySQL 后台所有请求都先经过 middleware/auth.js 做会话校验。 /login 接口例外允许匿名访问。 数据库访问统一封装在 db.js 中其中 safeQuery 使用参数化查询但 query 方法为旧接口遗留采用字符串拼接。 本次审计目标找出所有可被匿名用户利用的 SQL 注入点并确认现有绕过条件。这段背景里有三个关键动作标出匿名访问接口、说明两种数据库方法的区别、给出审计目标。Cursor 拿到以后在看/login时才会重点检查它用的是哪种方法、能否被攻击者触达。4.3 Cursor 的第一轮分析与我的纠偏我给 Cursor 的提问是这样写的根据背景请审查 routes/auth.js 的 /login 接口特别关注它是否走了 safeQuery如果走了 query 方法请给出攻击载荷并说明会话利用条件。Cursor 输出的大致结论是/login 接口使用了 db.query 方法而该方法会直接拼接 SQL存在 SQL 注入风险。 后台代码显示 middleware/auth.js 会默认将 /api/auth/login 加入匿名白名单所以攻击者无需登录即可触发。 不过由于这里 password 被拼接到 WHERE 子句实际可利用性取决于 MySQL 的 sql_mode 与站点是否开启了错误回显。 建议的攻击载荷为 username admin OR 11 -- -。看见没有因为我在背景里给出了“安全方法/危险方法”的区分Cursor 没有再泛泛地说“请用参数化查询”而是直接把问题钉在 query 这个具体函数上还结合 middleware 白名单判断了可达性。整个推理链路完全按我给的背景在走。随后我还要做一次“查询条件确认”让 Cursor 验证 db.js 里 query 方法是否真的没有转义函数确认该注入点确实是可利用的。一轮下来得到结论漏洞存在入口为 /api/auth/login可利用方式为布尔型盲注修复建议为切换到 safeQuery。4.4 结论背景给了Cursor 才敢下判断这个例子里的代码本身并不复杂但现实中我会把它放在一个 300 多个路由的大型应用里。那时候没有背景的 Cursor 一定会被大量无关文件淹没它可能花了很久才定位到路由文件然后又一次次被 middleware 的假象误导。而有了背景它就像拿到了“只看这一条支线”的指令从入口到汇聚点一步到位。我必须强调背景不是越多越好而是“边界条件”越准确越好。你用一句话告诉它“哪个接口匿名、哪个方法拼接 SQL”它的判断力就超过大多数中级开发。这不是玄学是上下文相关性带来的能力提升。5. 避坑记录这些错误我全都踩过5.1 问题速查表常见背景补充失败案例我用一张速查表把我和身边朋友实际踩过的坑整理出来。每次你发现 Cursor 审计结论又开始“泛泛而谈”时先对照这张表自查现象常见原因应对方案结论全是“建议加参数化查询”背景里没说明哪些查询方法是危险的明确告诉它项目中哪些方法为字符串拼接、哪些为参数化对每个函数都输出一样的模板没有给业务边界AI 只能用通用套路补充角色权限、数据隔离、匿名路径等边界信息在无关代码上浪费上下文没圈定审计范围在提示词里写明“只审这几个接口的调用链忽略其它”结论不敢下死判断全是“可能”“或许”缺少“这个模块的配置是否公网可达”等关键事实把运行环境背景补上让它有依据下确定结论把自己绕进历史问题上反复报告不知道哪些是已知问题用“背景包”列出已知问题清单要求跳过或评估缓解措施来回改写细节却不关注数据流一次贴一个函数没有给模块上下文一次给完整的调用链或按审计目标限定路径5.2 如何判断 Cursor 是否“只是礼貌性附和”这是一个更隐蔽的坑。你问 Cursor“这段代码有没有问题”如果它回答“是的这里没有进行权限校验建议增加”你可能会很高兴。但仔细想如果它没有审过上游校验逻辑就附和你的判断那这个结论等于没审。我总结了一个简单判断法要求 Cursor 给“证据链”。我在每个重要结论后面都会补一句“请给出从入口到汇点的完整代码路径以及对应的具体行号”。如果它能给出说明它是真看了代码如果它半天只给出一句概括那多半是在顺着你的话往下说。还有一种情况是反过来的你问的问题本身太开放比如“看看这个项目哪里有安全问题”Cursor 也会给出一个听起来全面但没有任何重点的清单。这不是它不努力是你没给够背景和审计目标。所以我在第 2 节里特别强调“审计目标具体化”目的就是避免这种无效对话。5.3 几条备用提示词模板最后分享几套我保存在本地笔记里的提示词模板。它们适用于不同场景你可以直接复制修改。一套是“单文件深度审查模式”请作为资深安全审计员对以下文件做深度审查。 项目背景{这里粘贴模块边界、信任假设、已知问题} 审计目标{例如判断该文件是否存在越权风险} 要求输出漏洞时必须给出从入口参数到危险函数的完整污染链路并标注行号。一套是“调用链追踪模式”我要追踪从 {入口接口} 到 {敏感操作例如 SQL 写入/文件读取/命令执行} 的完整数据流。 请先列出该数据流经过的所有函数与中间件再逐一判断是否存在可污染点。 背景说明{粘贴路由白名单、鉴权方式、数据过滤方式}还有一套是“做审计报告总结”基于本次讨论的所有结论请整理成一份代码审计报告草稿。 要求按严重程度排序每条结论包含漏洞入口、攻击步骤、影响范围、修复建议。 不要输出与安全无关的内容不要重复已知问题清单。这三套模板的共同点是都要求 Cursor 结合背景输出“有路径、有依据”的结论而不是干巴巴的建议。你把它当成一个能听懂背景的初级审计师明确告诉它要看哪条线路、关注哪个风险、怎么呈现结果它帮你翻遍代码库的效率绝对比你一页页翻源码高得多。我个人在实际操作中的体会是补充项目背景这件事本质上是在给 AI 画一张“风险地图”。地图画得越准它导航的能力就越强。你在前十分钟准备背景、整理边界、界定范围上投入的时间通常会在后面的几十次对话里成倍赚回来。这个习惯一旦养成代码审计的效率翻倍只是顺带的结果真正的好处是你终于不用花那么多精力去区分“AI 在说真话”还是“AI 在说正确的废话”了。