security-review

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 项
- 整体评估：[通过 / 条件通过 / 不通过]

审查原则

1. 不粉饰问题。 有阻断级漏洞必须明确报告，不得因改动小而忽略。
2. 给出修复方向，不写完整补丁。 审查是发现问题，不是修复问题。
3. 基于实际风险校准严重度。 内网项目的某些风险可能降级；面向公网的服务从严。
4. 确认后再报告。 不要基于猜测报漏洞——确认代码确实存在该问题后再写入报告。