---
name: security-audit
version: 1.0.0
last_updated: 2026-04-08
repository: https://github.com/312362115/claude
description: >
  服务上线前的 AI 安全审查，聚焦需要理解代码语义和业务逻辑的安全问题。
  覆盖注入防护、认证授权、敏感数据处理、配置安全、业务安全 5 个维度。
  适用于 JS/TS 前端、TS/Python 后端项目。
  CI/CD 自动化检测（依赖漏洞、敏感信息 grep）不在本 skill 范围内，由流水线承担。
  触发词：安全审计、安全检查、上线前检查、有没有漏洞、security audit。
  触发场景：release 发版前（强制）、涉及认证/支付/用户数据的改动后（建议）、用户主动要求。
---

# 安全审计（Security Audit）

> CI/CD 拦确定性问题（依赖漏洞、硬编码密钥），本 skill 审需要理解力的问题（数据流追踪、业务逻辑安全）。
> 两者互补，不重复。

---

## 第一步：确定审计范围和深度

```
收到审计请求
  │
  ├─ 快速扫描（单模块 / 局部改动 / 敏感模块修改后）
  │   选 1-2 个最相关的维度检查
  │   产出：终端输出结果，不生成报告
  │
  └─ 完整审计（release 发版前 / 新服务首次上线 / 重大安全相关改动）
      5 个维度全量检查
      产出：docs/audits/YYYY-MM-DD-<服务名>-audit.md
```

### 范围识别

1. **确定审计目标**：哪些目录/模块/服务？用 `AskUserQuestion` 确认，不要猜
2. **识别技术栈**：检测 `package.json` / `requirements.txt` / `pyproject.toml` / `tsconfig.json`
3. **识别敏感区域**：优先审查以下目录和文件：
   - 路由定义、中间件（认证/鉴权相关）
   - 数据库操作层（ORM 调用、原生查询）
   - 用户输入处理（表单、API 参数解析）
   - 配置文件（CORS、安全头、环境变量引用）
   - 支付/订单/用户数据相关模块

---

## 第二步：逐维度审查

按以下 5 个维度逐一检查。每个维度都需要**读代码**，不是凭印象判断。

### 维度 1：注入防护

**审查目标**：用户可控的输入是否经过正确处理后才进入危险操作。

**检查清单**：

| 注入类型 | 关注点 | 安全做法 |
|---------|--------|---------|
| SQL 注入 | 原生 SQL 拼接、ORM 的 raw query | 参数化查询、预编译语句 |
| 命令注入 | `exec()`、`child_process`、`os.system()`、`subprocess` | 避免拼接用户输入到命令，用参数数组 |
| XSS | `innerHTML`、`dangerouslySetInnerHTML`、模板中的未转义输出 | 输出转义、CSP 头、避免直接插入 HTML |
| 路径遍历 | 用户输入拼接文件路径、`../` 未过滤 | 路径规范化、白名单校验、`path.resolve` 后检查前缀 |
| SSRF | 用户输入作为 URL 发起服务端请求 | URL 白名单、禁止内网地址、DNS rebinding 防护 |
| 模板注入 | 用户输入直接进入模板引擎渲染 | 避免动态模板编译、使用沙箱 |

**审查方法**：
1. 找到所有用户输入入口（路由参数、query、body、header、cookie）
2. 追踪每个输入的数据流向——最终到了哪个危险函数？
3. 中间有没有经过校验/转义/参数化处理？

### 维度 2：认证与授权

**审查目标**：确保每个需要保护的资源都有正确的认证和授权检查。

**检查清单**：

| 检查项 | 关注点 |
|--------|--------|
| 认证覆盖 | 有没有接口"裸奔"——应该要登录但没加认证中间件？ |
| 授权粒度 | 用户 A 能不能通过改 ID 访问用户 B 的数据？（IDOR） |
| JWT/Session | 密钥强度、过期时间、刷新机制、注销是否真的失效 |
| CORS 策略 | `Access-Control-Allow-Origin` 是否过于宽松（`*`）？credentials 模式下的 origin 检查 |
| 密码策略 | 密码是否 bcrypt/argon2 哈希存储、是否有强度要求 |
| 权限绕过 | 前端隐藏 ≠ 后端鉴权，检查是否只在前端做了权限判断 |

**审查方法**：
1. 列出所有路由/接口，标注哪些有认证中间件、哪些没有
2. 找到"裸奔"接口，判断是否应该加认证
3. 检查授权逻辑：当前用户只能操作自己的资源吗？

### 维度 3：敏感数据处理

**审查目标**：敏感数据在存储、传输、日志中是否得到正确保护。

**检查清单**：

| 检查项 | 关注点 |
|--------|--------|
| 密码存储 | 是否用了 bcrypt/argon2？是否明文或 MD5/SHA1？ |
| 加密算法 | 是否使用了已知弱算法（DES、RC4、MD5 用于加密） |
| 日志脱敏 | 日志里有没有打印密码、token、手机号、身份证号 |
| 错误信息 | 异常响应是否泄露了堆栈、SQL 语句、内部路径 |
| 数据传输 | 敏感 API 是否强制 HTTPS？cookie 是否设置 Secure 和 HttpOnly |
| 前端存储 | token 存 localStorage（可被 XSS 窃取）还是 httpOnly cookie？ |

**审查方法**：
1. 搜索密码/token 相关的存储和比对逻辑
2. 搜索日志输出（`console.log`、`logger.`、`print`），检查是否包含敏感字段
3. 检查错误处理中间件，确认生产环境不返回堆栈信息

### 维度 4：配置安全

**审查目标**：安全相关配置是否合理，生产环境是否加固。

**检查清单**：

| 检查项 | 关注点 |
|--------|--------|
| 安全响应头 | X-Content-Type-Options、X-Frame-Options、Strict-Transport-Security、CSP |
| Debug 模式 | 生产环境是否关闭 debug/详细错误输出 |
| 默认凭证 | 是否存在默认密码、测试账号、admin/admin |
| 速率限制 | 登录、注册、验证码等接口是否有 rate limit |
| 文件上传 | 是否限制文件类型、大小？存储路径是否在 web 可访问目录外？ |
| 环境隔离 | 生产配置和开发配置是否分离？环境变量是否正确引用 |

### 维度 5：业务安全

**审查目标**：识别需要理解业务语义才能发现的安全风险。

**检查清单**：

| 检查项 | 关注点 |
|--------|--------|
| 越权访问（IDOR） | 修改请求中的 ID/参数能否访问他人数据 |
| 批量枚举 | 用户名/邮箱是否可被枚举（注册/登录/找回密码的不同返回） |
| 竞态条件 | 余额扣减、库存扣减、优惠券核销是否有并发保护 |
| 逻辑绕过 | 支付金额是否可在前端篡改？流程步骤是否可跳过？ |
| 重放攻击 | 关键操作是否有幂等性保护或 nonce 机制 |
| 信息泄露 | API 响应是否返回了多余字段（如其他用户的信息、内部 ID） |

**审查方法**：
1. 站在攻击者视角思考："如果我想偷数据/薅羊毛/搞破坏，我会怎么做？"
2. 检查关键业务操作的参数校验和权限检查
3. 关注"前端校验但后端没校验"的情况

---

## 第三步：风险分级

每个发现按以下标准分级：

| 等级 | 标准 | 处理要求 |
|------|------|---------|
| **高危** | 可直接导致数据泄露、未授权访问、代码执行 | **必须修复后才能上线**，给出具体修复代码 |
| **中危** | 存在利用条件但风险可控，或防御纵深不足 | **建议修复**，给出修复方向 |
| **低危** | 最佳实践缺失，短期内风险较小 | **记录待改进**，不阻断上线 |

分级原则：
- 不确定时往高了分，宁可过度警惕不可遗漏
- 但不要把所有发现都标高危——狼来了效应会降低警觉
- 已有其他防御措施的可适当降级（如 XSS 风险但已有严格 CSP）

---

## 第四步：生成审计报告

**完整审计**时，生成报告到 `docs/audits/YYYY-MM-DD-<服务名>-audit.md`：

```markdown
# 安全审计报告：<服务名>

## 审计概览
- 审计日期：YYYY-MM-DD
- 审计范围：<目录/模块列表>
- 技术栈：<自动识别结果>
- 风险摘要：🔴 X 高危 / 🟡 X 中危 / 🟢 X 低危

## 审计结论

**✅ 通过** / **⚠️ 有条件通过（需修复高危后上线）** / **❌ 不通过**

## 详细发现

### 1. 注入防护
（发现 / 无风险）

### 2. 认证与授权
（发现 / 无风险）

### 3. 敏感数据处理
（发现 / 无风险）

### 4. 配置安全
（发现 / 无风险）

### 5. 业务安全
（发现 / 无风险）

## 修复清单

| # | 等级 | 维度 | 问题描述 | 文件位置 | 修复建议 |
|---|------|------|---------|---------|---------|

## 历史审计
- [上次审计](链接)（如有）
```

每个发现必须包含：
- **具体代码位置**（文件:行号）
- **问题描述**（是什么、为什么危险）
- **攻击场景**（攻击者怎么利用）
- **修复建议**（高危给代码，中危给方向）

---

## 第五步：修复与复查

1. **高危问题**：给出具体修复代码，协助用户当场修复
2. **修复后复查**：修复完成后，重新检查对应维度确认修复有效
3. **报告更新**：在修复清单中标记已修复项

---

## 与其他 skill/流程的衔接

```
CI/CD 安全流水线（自动化，确定性）
  ├─ pre-commit: gitleaks 拦截敏感信息
  └─ PR Check: 依赖漏洞 + 静态规则扫描
         │
         ↓ 自动化通过后
security-audit（本 skill，AI 审查）
  ├─ task-finish 提示：涉及敏感模块时建议快速扫描
  └─ release 强制：发版前完整审计
         │
         ↓ 审计通过
release — 发版
```

**审计报告目录**：`docs/audits/`，命名格式 `YYYY-MM-DD-<服务名>-audit.md`

---

## 注意事项

- **不要替代 CI/CD**：依赖漏洞扫描（npm audit）、敏感信息 grep（gitleaks）是自动化流水线的事，本 skill 不重复做
- **不要过度报告**：只报告真实风险，不要为了显得全面把无关紧要的 warning 都列上
- **理解业务再审**：先用 `code-walkthrough` 或快速阅读理解业务逻辑，再做安全审查。脱离业务的安全审查是低效的
- **攻击者思维**：每个维度都要问"如果我是攻击者，我怎么利用这个？"。找不到攻击路径的问题不算高危