独立项目很少栽在精巧的 0day 上，几乎都是栽在没意思的地方：少一处归属校验、.env 传进了 git、依赖里躺着两年前的 CVE。在 OWASP Top 10:2025 里，访问控制失效（Broken Access Control）依然是头号风险，约 3.7% 的受测应用中招，同一年 SSRF 也被并进了这一类。前 80% 的攻击面不需要请渗透，需要的是有纪律、可复用的检查。下面这 12 个 Prompt 沿着 OWASP 的基础逐项过一遍，输出一份你能在上线前直接照着关掉的”问题 + 修复”清单。
一句话总结
- 把每个 Prompt 喂给上下文窗口大的模型，让它读完整文件、而不是片段。截至 2026 年 6 月，Claude Opus 4.7 和 Sonnet 4.6（1M token）、Gemini 3.1 Pro（1M）最合适；GPT-5.5 Thinking 适合较短的文件。
- AI 替代的是”第一遍”,不是整次审计。每一个”ok”都当成”看着没问题，去核实修复并补一个测试”。
- 依赖类发现一律用真扫描器复核（
npm audit、pip-audit或osv-scanner）——大模型会瞎编 CVE 编号。 - 下面把每个 Prompt 对应到 OWASP Top 10:2025 的分类，让你的覆盖面可审计，而不是凭感觉。
各 Prompt 对应的 OWASP 风险
| OWASP Top 10:2025 | 覆盖它的 Prompt |
|---|---|
| A01 访问控制失效（含 SSRF） | 5（授权）、2（输入里的 SSRF） |
| A02 安全配置错误 | 7（CORS）、11（CSP / 安全头） |
| A03 软件供应链失效 | 4（依赖） |
| A04 加密失效 | 1（token / JWT）、3（密钥） |
| A05 注入 | 2（输入校验）、6（上传） |
| A06 设计不安全 | 12（STRIDE 威胁建模） |
| A07 认证失效 | 1（认证流） |
| A08 数据完整性失效 | 10（webhook 签名） |
| A09 安全日志与告警失效 | 8（PII 日志）、9（滥用） |
| A10 异常处理不当 | 8、10（失败时的行为） |
这套 Prompt 适合用在哪
- 上线前安全 pass
- API / endpoint 评审
- 认证 / 授权流审计
- 依赖与供应链审计
- 事故后加固
1. 认证流审计
请审计下面的认证流。每项给出状态（ok / 有风险 / 已破）、证据（引用行号）、修复方案：token 存储位置、refresh token 轮换、session 过期策略、多设备处理、密码重置链接熵 + TTL、暴力破解 / 限流保护、OAuth state 与 PKCE、JWT 算法与 audience 校验、登录错误是否泄露账号存在性。输出 markdown 表格。
代码：
[paste]2. 输入校验审计
审计下面 endpoint 的输入校验。每个 endpoint 列：(a) 每个参数是否做了校验（类型、范围、白名单）、(b) 不校验时可能的攻击（SQLi、XSS、路径遍历、SSRF、命令注入、原型污染）、(c) 推荐的最小修复 + 库。问题按 critical / high / medium 排序。
代码：
[paste]3. 密钥处理审计
请审计下面代码和配置中的密钥处理。检查：硬编码的 API key / token / 密码、前端 bundle 或 source map 里的密钥、被 git 提交的 .env、任何级别日志里出现的密钥、走 URL query 传的密钥、是否有轮换策略。输出：文件:行号、严重度、修复方案。如果有 critical，再给一份"60 分钟内紧急处置"清单（≤5 行）。
代码 + 配置：
[paste]4. 依赖漏洞检查
下面是 package.json / requirements.txt / Gemfile / go.mod。请识别：(a) 已知 CVE 的包（按你训练数据知识，但标注"需以 npm audit / pip-audit / osv-scanner 复核"）、(b) 长期无维护但属于安全关键依赖的包（2 年+ 无 release）、(c) typosquatting 风险、(d) 版本区间过宽，导致可能锁到带漏洞的主版本。给出升级顺序，并标明 breaking change 风险。
清单：
[paste]模型给的 CVE 列表只是起点假设，不是结论。一定要重跑真扫描器：
npm audit、pip-audit（PyPA / Trail of Bits 维护）、或者多生态仓库用osv-scanner——它们是对照 OSV.dev 数据库匹配，而不是靠猜。
5. 授权模型审计
下面是 app 各处的 authz 检查。请梳理并识别：(a) 有认证但没授权检查的 endpoint、(b) 同一资源在不同路由里检查不一致、(c) IDOR 风险（按 ID 访问对象但没校验归属）、(d) 横向 / 纵向提权路径、(e) 用户角色能打到的管理端 endpoint。输出"路由 x 所需角色"矩阵，把漏洞点直接标出来。
代码：
[paste]6. 文件上传安全审计
下面是文件上传相关代码。请审计：文件类型不限 / 缺 magic byte 校验、文件名路径遍历、content-type 伪造、双扩展名绕过、单文件大小 + 总配额限制、文件存储位置（web 根目录里？S3 公开 ACL？）、病毒 / 恶意文件扫描、图像处理 CVE 暴露面（ImageMagick、sharp）。每个发现给代码级修复。
代码：
[paste]7. CORS 与 CSRF 审计
下面是 CORS + CSRF 配置和一批改状态的 endpoint。请审计：(a) 过度宽松的 Access-Control-Allow-Origin（`*` 带 credentials、regex 绕过）、(b) 改状态 endpoint 是否缺 CSRF token 或 SameSite=Lax/Strict cookie、(c) preflight 处理、(d) WebSocket 的 origin 检查、(e) 允许列表里的子域接管风险。每项给出具体配置修复。
配置 + 路由：
[paste]8. 日志与 PII 审计
下面是日志语句和日志保留配置。请识别：哪些日志会输出 PII（邮箱、手机号、全名、IP、设备 ID）、凭据（token、session ID、密码重置 URL）或业务机密。每条给修复建议（哈希、截断、脱敏，或直接删行）。再检查：日志是否上送到第三方？有没有数据主体删除请求（DSAR）路径？认证失败是只记录还是也会告警（OWASP A09）？
代码 + 配置：
[paste]9. 服务端限流与防滥用审计
请审计下面 endpoint 的限流。每个 endpoint 列：有没有限流、是按 IP / 按用户 / 按 API key、是全局还是单 endpoint、缺限流时的"被滥用代价"（LLM token、短信、邮件、贵查询）。把任何能耗光预算或触发账号锁定式 DOS 的 endpoint 标出来，并给出带理由的限流值建议。
Endpoint：
[paste]10. Webhook 与对外 API 审计
请审计入站 webhook 和公开 API。检查：(a) 签名校验（HMAC + 常时间比较、时间戳 + nonce 防重放）、(b) 幂等键、(c) 可用时的源 IP 白名单、(d) payload 大小限制、(e) 签名校验失败时的行为（静默 200？日志 + 告警？）。再核对密钥轮换流程。
代码：
[paste]11. 前端 / 浏览器侧安全审计
请审计前端代码：(a) 是否设置了 Content-Security-Policy 以及漏洞（unsafe-inline、通配源）、(b) 敏感数据放在 localStorage 还是 httpOnly cookie、(c) XSS 注入点（dangerouslySetInnerHTML、v-html、innerHTML 拼用户输入）、(d) postMessage 的 origin 检查、(e) 第三方脚本供应链（任何不可控域名的 script 标签缺 SRI）。每项给修复。
代码：
[paste]12. 单功能的威胁建模
为下面描述的功能跑一遍 STRIDE 威胁建模。每类（伪造身份、篡改、否认、信息泄露、拒绝服务、提权）给 1-2 个针对本功能的具体威胁、受威胁的资产、现有缓解（或"无"）、推荐的控制。结尾列出上线前必须修的 3 个最高风险。
功能描述：
[paste]选对模型和工具
上面的审计 Prompt 与模型无关，但读出来的质量随上下文窗口和推理能力一起涨。
| 方案 | 适合 | 备注（2026 年 6 月） |
|---|---|---|
| Claude Opus 4.7 / Sonnet 4.6 | 全仓、跨文件授权梳理 | 1M token 上下文；Opus 在 CyberGym 漏洞复现拿到 73.1% |
| Gemini 3.1 Pro | 大型 monorepo、便宜的批量过 | 1M 上下文；API 每百万 token 2/12 |
| GPT-5.5 Thinking | 单文件深挖 | Plus 应用内约 320 页，完整 1M 仅 $200 Pro 档 |
| Claude Code Security | 终端里自动扫整个仓库 | 2026 年 2 月起内置于 Claude Code，无需复制粘贴 |
如果你常驻终端，Claude Code Security（2026 年 2 月上线）能自动跑上面很多检查——Anthropic 称在测试中它已在开源仓库里发现 500+ 高危问题。日常工作流可参考 什么是 Claude Code 和 代码审查 Prompt。
容易踩的坑
- 只盯注入类漏洞、完全忽略授权——可在 2025 榜单里，A01 访问控制失效排在 A05 注入之前。
- 觉得”框架会处理”，却没核对版本和实际配置。
- 没有按功能做威胁建模，安全只在上线那周临时拼。
- Bug 修了但日志保留期设成永久，历史 PII 仍会在事故中泄出。
- 把模型给的 CVE 编号当真，而不去重跑真扫描器。
- 改完代码没补回归测试 / 告警，下个版本又会复发。
常见问题
AI Prompt 能替代真正的渗透测试吗？ 不能。它们覆盖可复用的前 80%——配置、明显的授权缺口、泄露的密钥、过期的依赖；但抓不到业务逻辑滥用、组合利用链和运行时问题。凡是涉及支付或健康数据的，上线前都该预算一次人工渗透，把这些 Prompt 当成便宜的前置筛查。
AI 给出的依赖发现有多准？
当假设有用，当结论不可靠。大模型经常瞎编 CVE 编号和版本区间。一定用 npm audit、pip-audit 或 osv-scanner 复核——它们是对照 OSV.dev 数据库匹配，而不是靠猜。
该用哪个模型？ 挑能把整份文件塞进上下文的那个。截至 2026 年 6 月，仓库级审计选 Claude Opus 4.7 / Sonnet 4.6 或 Gemini 3.1 Pro（各 1M token）；单文件用 GPT-5.5 Thinking 即可。常驻终端的话，Claude Code Security 能自动扫。
把代码粘进聊天框安全吗？ 别粘真密钥——先把 key 脱敏，并优先用厂商的数据控制选项或 API（API 默认不拿来训练）。私有仓库最安全的做法是本地或自托管模型。无论哪家厂商，跑审计 Prompt 前都先抹掉真实凭据。
上线前过一遍的正确顺序是什么？ 先过密钥（3）和依赖（4），因为它们利用成本最低；再过授权（5）和认证（1）；接着输入 / 上传 / CORS（2、6、7）；然后日志与滥用（8、9）；最后对最高风险的两个功能做一次单功能威胁建模（12）。