feat(mp): 积分商城 V2 重设计 — design-handoff 全流程
- 新增 4 个 UI 组件: PointsCard/ProductCard/CheckinCalendar/CheckinModal - 商城首页 V2: 积分卡 + 快捷操作 + 分类标签 + 商品网格 - 商品详情 V2: 大图 + 信息卡 + 库存/余额状态 + 底部操作栏 - TabBar 新增商城入口(5 Tab: 首页/健康/商城/助手/我的) - 设计原型 docs/design/mp-05-mall-v2.html + SPEC.md 交付包 - CLAUDE.md 安全规范加固: 新增 §3.7 安全规范 6 条 + Feature DoD 安全清单扩展
This commit is contained in:
iven
76
CLAUDE.md
76
CLAUDE.md
@@ -177,8 +177,13 @@
|
||||
|
||||
- [ ] 新增端点有权限声明（默认拒绝，不是默认放行）
|
||||
- [ ] 敏感数据有脱敏/加密处理（PII 字段走 AES-256-GCM）
|
||||
- [ ] 用户输入已验证和消毒（防 SQL 注入、XSS）
|
||||
- [ ] 无 CORS 通配符、无硬编码密钥
|
||||
- [ ] 用户输入已验证和消毒（防 SQL 注入、XSS、命令注入、路径穿越）
|
||||
- [ ] 无 CORS 通配符、无硬编码密钥、无 fallback 默认密钥
|
||||
- [ ] 日志中无敏感数据输出（密码、token、身份证号、手机号等）
|
||||
- [ ] 文件上传有 MIME 类型验证 + 大小限制 + 路径穿越防护
|
||||
- [ ] API 响应不暴露内部实现细节（数据库错误、堆栈跟踪、文件路径）
|
||||
- [ ] 速率限制已配置（认证端点更严格）
|
||||
- [ ] 密钥通过环境变量注入，`.env.example` 已同步更新
|
||||
|
||||
#### 文档一致性
|
||||
|
||||
@@ -224,7 +229,7 @@
|
||||
|
||||
#### 新增 API 端点安全检查（强制）
|
||||
|
||||
> 历史数据：25 次安全 fix 中 80% 源于默认放行模式。
|
||||
> 默认拒绝是安全基线 — 绝大多数安全修复源于默认放行模式。
|
||||
> 新增端点时**必须**逐项确认：
|
||||
|
||||
- [ ] 端点已添加 `require_permission` 权限守卫（非公开端点）
|
||||
@@ -237,7 +242,7 @@
|
||||
|
||||
#### 前后端接口同步检查（强制）
|
||||
|
||||
> 历史数据：35 次 fix 源于前后端接口不一致。
|
||||
> 前后端接口不一致是高频 bug 来源 — 任何 DTO 变更必须双向同步。
|
||||
> 后端 DTO 变更时**必须**同步检查前端：
|
||||
|
||||
- [ ] DTO 字段名变更 → 前端 TypeScript 接口同步更新
|
||||
@@ -249,7 +254,7 @@
|
||||
|
||||
#### DTO 输入校验检查（强制）
|
||||
|
||||
> 历史数据：2026-05-19 全系统审计发现 44 处校验缺失。
|
||||
> DTO 输入校验是安全防线 — 缺失校验等于暴露攻击面，Update 和 Create 必须对称。
|
||||
> 新增/修改 DTO 时**必须**逐项确认：
|
||||
|
||||
- [ ] 所有请求结构体已 `derive(Validate)`（包括 Update\*Req、查询参数）
|
||||
@@ -291,6 +296,50 @@
|
||||
// 国际化文案使用 i18n key，不硬编码中文
|
||||
```
|
||||
|
||||
### 3.7 安全规范
|
||||
|
||||
#### 密钥与凭据管理
|
||||
|
||||
- 所有密钥、token、密码**必须**通过环境变量或密钥管理服务注入，**禁止**硬编码在源码中
|
||||
- 开发环境密钥**必须**与生产环境严格隔离（`cfg(debug_assertions)` 编译期防护）
|
||||
- 生产密钥**禁止**有 fallback 默认值，缺失时启动 panic
|
||||
- 新增密钥时必须同步更新 `.env.example` 和 `wiki/infrastructure.md`
|
||||
|
||||
#### 依赖安全
|
||||
|
||||
- 新增依赖前**必须**检查已知漏洞（`cargo audit` / `npm audit`）
|
||||
- 禁止引入有未修补高危漏洞的依赖版本
|
||||
- 定期更新依赖到最新安全补丁版本
|
||||
|
||||
#### 数据安全
|
||||
|
||||
- PII 数据（姓名、身份证号、手机号、地址等）**必须**加密存储（AES-256-GCM）
|
||||
- 日志中**禁止**输出 PII 数据和认证凭据（密码、token、session key）
|
||||
- 敏感操作（登录、权限变更、数据导出、批量删除）**必须**记录审计日志（操作者、时间、目标、结果）
|
||||
- 文件上传**必须**验证 MIME 类型 + 限制文件大小 + 防止路径穿越（文件名 sanitize）
|
||||
|
||||
#### 传输安全
|
||||
|
||||
- 生产环境**必须**强制 HTTPS，**禁止**降级到 HTTP
|
||||
- HTTP 响应**必须**包含安全头（HSTS、CSP、X-Frame-Options、X-Content-Type-Options、Permissions-Policy）
|
||||
- SSE/WebSocket 长连接认证 token 不通过 URL query 参数传递（使用 header 或 cookie）
|
||||
- API 响应**禁止**暴露内部实现细节（堆栈跟踪、数据库错误、文件路径、SQL 语句）
|
||||
|
||||
#### 认证与授权
|
||||
|
||||
- 密码**必须**使用单向哈希（bcrypt/argon2），**禁止**明文或可逆加密存储
|
||||
- JWT **必须**设置合理过期时间，支持 token 吊销机制
|
||||
- 敏感操作（删除数据、权限变更）需要二次确认
|
||||
- 权限检查在 handler 层执行，**禁止**仅依赖前端隐藏控制访问
|
||||
- `tenant_id` **必须**从 JWT 中间件注入，**禁止**信任客户端传递的值
|
||||
|
||||
#### 速率限制
|
||||
|
||||
- 所有 API 端点**必须**配置速率限制
|
||||
- 认证相关端点（登录、注册、密码重置）限制更严格
|
||||
- 批量操作和数据导出需要独立的速率限制策略
|
||||
- 速率限制超出时返回 429 状态码，响应包含 `Retry-After` header
|
||||
|
||||
---
|
||||
|
||||
## 4. 测试与验证
|
||||
@@ -409,17 +458,24 @@ chore(docker): 添加 PostgreSQL 健康检查
|
||||
- ❌ **不要**跳过验证直接提交 — 编译/测试/功能验证必须全部通过
|
||||
- ❌ **不要**提交后忘记推送 — 不推送等于没完成，远程仓库必须同步。每次新会话开始先检查未推送提交
|
||||
- ❌ **不要**忘记更新文档 — 涉及架构、接口、模块变化时必须同步更新相关文档
|
||||
- ❌ **不要**连续 5 个代码提交不更新 wiki — wiki 是团队唯一真相源，过期数据比没有数据更有害（5 月实测：89 fix 仅 11 有 wiki 更新，关键数字迁移数差 8 个）
|
||||
- ❌ **不要**连续 5 个代码提交不更新 wiki — wiki 是团队唯一真相源，过期数据比没有数据更有害
|
||||
- ❌ **不要**修复 bug 后跳过症状导航更新 — 每个修复都应该帮助未来遇到同类问题的人快速定位根因
|
||||
- ❌ **不要**新增功能后不更新 wiki 关键数字 — 迁移数/路由数/实体数/测试数必须与代码同步，否则 wiki 指标表就是废数据
|
||||
- ❌ **不要**一次性输出长文档 — 超过 200 行的文档必须分步编写（先大纲 → 逐章 → 整合），否则会因上下文过长卡死
|
||||
- ❌ **不要**忽略讨论记录 — 每次发散式讨论结束后必须建立文档到 `docs/discussions/`，不要口头确认后就忘
|
||||
- ❌ **不要**跳过 Feature DoD — 每个功能标记"完成"前必须通过 §2.6 检查清单，不全面验证就提交 = 后续 5 次 fix（媒体库教训）
|
||||
- ❌ **不要**新增端点时默认放行 — 所有端点默认拒绝访问，必须显式声明权限（安全教训：25 次 fix 源于默认放行）
|
||||
- ❌ **不要**后端 DTO 变更不同步前端 — 字段名/路径/类型变更时必须同步更新前端 TypeScript 接口（35 次 fix 教训）
|
||||
- ❌ **不要**写 Update DTO 时省略校验 — Update*Req 必须与 Create*Req 校验对称（44 处缺失教训：Update 无 Validate derive / 枚举字段无 custom 校验 / Vec 无 min=1 / 密码无 max）
|
||||
- ❌ **不要**跳过 Feature DoD — 每个功能标记"完成"前必须通过 §2.6 检查清单，不全面验证就提交将导致后续反复修复
|
||||
- ❌ **不要**新增端点时默认放行 — 所有端点默认拒绝访问，必须显式声明权限
|
||||
- ❌ **不要**后端 DTO 变更不同步前端 — 字段名/路径/类型变更时必须同步更新前端 TypeScript 接口
|
||||
- ❌ **不要**写 Update DTO 时省略校验 — Update*Req 必须与 Create*Req 校验对称（Validate derive / 枚举 custom / Vec min=1 / 密码 max=128）
|
||||
- ❌ **不要**URL 字段不做 SSRF 防护 — 禁止 localhost/127.0.0.1/内网地址，仅允许 http/https 协议
|
||||
- ❌ **不要**handler 层跳过 `.validate()` — 所有 `Json<T>` handler 函数体第一行必须调 `req.validate().map_err(\|e\| AppError::Validation(e.to_string()))?`
|
||||
- ❌ **不要**在日志中输出敏感数据 — 密码、token、身份证号、手机号等 PII 信息禁止写入日志
|
||||
- ❌ **不要**信任客户端传递的 `tenant_id` — 必须从 JWT 中间件注入，客户端可伪造
|
||||
- ❌ **不要**在生产代码中使用 `unwrap()` — 必须处理所有错误，使用 `?` 或 `map_err`
|
||||
- ❌ **不要**将内部错误信息返回给客户端 — 数据库错误、堆栈跟踪、文件路径等必须转换为用户友好的错误消息
|
||||
- ❌ **不要**使用 HTTP 传输敏感数据 — 生产环境必须 HTTPS
|
||||
- ❌ **不要**跳过依赖安全检查 — 新增依赖前运行 `cargo audit` / `npm audit`，禁止引入有高危漏洞的版本
|
||||
- ❌ **不要**文件上传不做安全处理 — 必须验证 MIME 类型 + 限制大小 + sanitize 文件名防路径穿越
|
||||
|
||||
### 场景化指令
|
||||
|
||||
|
||||
Reference in New Issue
Block a user