| name | security-review |
| description | 安全审计——对代码变更进行六项安全检查，发现漏洞和安全隐患。触发词：「安全审查」「安全检查」「security review」「audit」「有安全风险吗」。 |
| allowed-tools | ["Read","Grep","Glob","Bash(git *)"] |
安全审查
对代码变更执行结构化的安全审计。审查不修改代码——只报告发现。
六项检查清单
1. 注入攻击（Injection）
检查是否存在以下风险：
- SQL 注入： 是否使用了参数化查询？拼接 SQL 字符串是严重的阻断项。
- 命令注入： 是否将用户输入直接传给
exec、spawn、system、os/exec 等？
- 路径遍历： 文件路径是否由用户输入拼接？是否校验了
../ 等跳转序列？
- XSS： 用户输入渲染到 HTML 时是否做了转义？是否使用了
dangerouslySetInnerHTML、innerHTML、v-html？
- 模板注入： 服务端模板引擎中是否混入了用户输入？
2. 密钥与凭证（Secrets）
- 硬编码密钥： 是否在源码中出现了 API Key、Token、密码、证书私钥？
- 环境变量暴露：
.env 文件是否在提交范围内？前端代码是否暴露了不应公开的配置？
- 调试凭证： 是否遗留了开发环境的默认密码或 Test Token？
- 日志泄露： 日志中是否 print 了 Token、密码、用户敏感数据？
3. 认证与授权（Authentication & Authorization）
- 越权风险： 操作前是否校验了用户对该资源的权限？
- 会话管理： Token 是否设置了合理的过期时间？刷新逻辑是否安全？
- 密码处理： 是否使用了安全的哈希算法（bcrypt、argon2）而不是 MD5/SHA1？
- CSRF： 状态变更操作是否有 CSRF 防护？
4. 数据暴露（Data Exposure）
- 响应数据： API 是否返回了不必要的敏感字段（密码哈希、内部 ID、手机号全号）？
- 错误信息： 生产环境的错误响应是否泄露了堆栈信息、SQL 查询或内部路径？
- 前端存储：
localStorage / sessionStorage 中是否存储了敏感 Token？
- 文件上传： 上传的文件是否校验类型、大小？存储路径是否可控？
5. 依赖安全（Dependencies）
- 已知漏洞： 新引入的依赖及其版本是否有已知 CVE？
- 非官方源： 是否从非官方 registry 或 Git 分支引用依赖？
- 过度权限： 新依赖要求的权限是否必要？
6. 不安全配置（Insecure Configuration）
- CORS： CORS 配置是否过于宽松（
Access-Control-Allow-Origin: * + credentials）？
- CSP： 内容安全策略是否缺失或配置不当？
- TLS： API 调用是否使用 HTTPS？
- 调试模式： 生产构建中是否开启了 debug 模式？
严重度分级
| 级别 | 含义 | 示例 |
|---|
| 阻断（Critical） | 可被直接利用的漏洞 | SQL 注入、硬编码生产密钥、绕过认证 |
| 高（High） | 高风险但利用条件稍高 | XSS、越权、敏感数据暴露 |
| 中（Medium） | 有安全影响但不致直接危害 | 宽松 CORS、日志泄露 Token |
| 低（Low） | 最佳实践偏差 | 密码哈希算法较弱（但非明文） |
审查输出格式
## 安全审查报告
**审查范围**：[文件列表 或 diff 范围]
**审查日期**：[日期]
### 阻断（必须修复）
- `file.ts:42` — SQL 注入：用户输入直接拼接到查询字符串 — 使用参数化查询
### 高风险
- `api.ts:88` — 越权：未校验订单归属即返回详情 — 添加所有权检查
### 中风险
- `config.ts:15` — CORS 配置 `origin: '*'` 与 `credentials: true` 同时使用
### 低风险
（无）
### 审查结论
- 阻断：N 项
- 高风险：N 项
- 中风险：N 项
- 低风险：N 项
- 整体评估：[通过 / 条件通过 / 不通过]
审查原则
- 不粉饰问题。 有阻断级漏洞必须明确报告，不得因改动小而忽略。
- 给出修复方向，不写完整补丁。 审查是发现问题，不是修复问题。
- 基于实际风险校准严重度。 内网项目的某些风险可能降级；面向公网的服务从严。
- 确认后再报告。 不要基于猜测报漏洞——确认代码确实存在该问题后再写入报告。
