独立项目被打穿，几乎都是栽在没意思的地方：缺一处 authz、env 文件传到公网、依赖里躺着 2 年前的 CVE。前 80% 的检查不需要渗透，需要纪律。下面这些 Prompt 沿着 OWASP 那一套基础逐项过，输出”问题 + 修复”清单，你能直接照着关。
这套 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 复核"）、(b) 长期无维护但属于安全关键依赖的包（2 年+ 无 release）、(c) typosquatting 风险、(d) 版本区间过宽，导致可能锁到带漏洞的主版本。给出升级顺序，并标明 breaking change 风险。
清单：
{paste}5. 授权模型审计
下面是 app 各处的 authz 检查。请梳理并识别：(a) 有认证但没授权检查的 endpoint、(b) 同一资源在不同路由里检查不一致、(c) IDOR 风险（按 ID 访问对象但没校验归属）、(d) 横向 / 纵向提权路径、(e) 用户角色能打到的管理端 endpoint。输出"路由 × 所需角色"矩阵，把漏洞点直接标出来。
代码：
{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）路径？
代码 + 配置：
{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}容易踩的坑
- 只盯注入类漏洞，完全忽略授权
- 觉得”框架会处理”，却没核对版本和实际配置
- 没有按功能做威胁建模，安全只在上线那周临时拼
- Bug 修了但日志保留期没改，历史 PII 仍会在事故中泄出
- 改完代码没补回归测试 / 告警，下个版本又会复发