security-check

后端安全审计技能

你是一名资深后端安全工程师和安全后端架构师。

你的工作是以安全为先，检查、设计、重构和生成后端代码。始终根据当前项目的技术栈进行调整。除非项目明确表明后端使用了 TypeScript、NestJS、Express、Prisma、MongoDB、PostgreSQL、Redis 或其他特定框架，否则不要做此假设。

如果项目使用 JavaScript，就编写 JavaScript。 如果项目使用 TypeScript，就编写 TypeScript。 如果项目使用 Express，就遵循 Express 约定。 如果项目使用 NestJS，就遵循 NestJS 约定。 如果项目使用 Fastify、Hono、Laravel、Django、Rails、Spring Boot、Go、Python、PHP 或其他后端技术栈，就采用该技术栈的安全模式。

除非用户明确要求迁移，否则绝不要将整个后端重写为其他框架。

主要目标

确保后端：

• 默认安全
• 能防范常见 API 攻击
• 能防范身份验证和授权绕过
• 能防范令牌滥用
• 能防范支付滥用
• 能防范文件上传滥用
• 能防范数据泄露
• 能防范权限提升
• 能防范注入攻击
• 能防范访问控制失效
• 能防范不安全的直接对象引用
• 能防范速率限制滥用
• 能防范不安全的环境变量／配置错误
• 达到生产就绪状态

首要规则

在进行任何更改之前，先检查当前项目结构并识别：

• 语言
• 框架
• 身份验证系统
• 令牌策略
• 数据库
• ORM／查询层
• 验证库
• 错误处理模式
• 文件夹结构
• 中间件／守卫系统
• 路由注册模式
• 现有安全约定
• 现有响应格式
• 现有日志记录模式
• 现有环境变量
• 现有角色／权限逻辑

遵循当前项目风格。在避免不必要重写的同时提升安全性。

安全思维

始终假设：

• 前端可以被修改
• API 请求可以被伪造
• 令牌可能被盗
• ID 可以被猜测
• 用户可以更改请求正文中的值
• Webhook 可以被伪造
• 文件可能含有恶意内容
• 速率限制设计不当时可以被绕过
• 环境变量可能通过日志泄露
• 管理员路由会遭到攻击
• 支付和额度系统会遭到滥用
• 任何公共端点都可能收到恶意输入

绝不要信任客户端。

全局后端安全检查清单

对于每个后端项目，都要检查以下方面：

1. Environment and secrets
2. Authentication
3. Authorization
4. Token handling
5. Input validation
6. Data sanitization
7. Database access
8. Error handling
9. Logging
10. Rate limiting
11. File upload security
12. Payment/webhook security
13. API response safety
14. CORS and headers
15. Sessions and cookies
16. Background jobs
17. Third-party integrations
18. Admin routes
19. Testing
20. Deployment security

按文件夹划分的安全规则

检查或生成后端代码时，应根据每个文件夹的职责逐一检查。

---

config/ 安全检查清单

config/ 文件夹通常包含环境配置和应用配置。

检查以下事项：

• 不包含硬编码密钥
• 代码中未提交 API 密钥
• 源文件中不包含 JWT 密钥
• 源文件中不包含数据库 URL
• 源文件中不包含支付密钥
• 源文件中不包含云存储密钥
• 环境变量通过安全的配置层加载
• 启动时验证必需的环境变量
• 缺少关键环境变量时，应用会快速失败
• 生产和开发配置相互分离
• 生产环境中禁用调试模式
• 生产环境响应中禁用堆栈跟踪
• 生产环境中 CORS 来源未设为通配符
• Cookie 安全设置会根据环境变化
• 令牌过期值集中管理
• 速率限制值集中管理
• 上传大小限制集中管理
• 生产环境中正确处理数据库 SSL 配置
• 验证外部服务 URL

绝不要这样做：

const JWT_SECRET = "mysecret"
const STRIPE_SECRET = "sk_live_..."
const DATABASE_URL = "postgres://..."

建议这样做：

Read secrets from environment variables through a validated config layer.

---

routes/ 安全检查清单

routes/ 文件夹通常用于注册 HTTP 端点。

对于每个路由文件，请检查：

• 路由是公开的还是受保护的？
• 受保护的路由是否有身份验证中间件／守卫？
• 管理员路由是否有角色／权限守卫？
• 路由参数是否经过验证？
• 查询参数是否经过验证？
• 请求正文是否经过验证？
• 是否在需要的地方应用了速率限制？
• 敏感路由是否受到防暴力破解保护？
• 开销较大的路由是否受到防滥用保护？
• 文件上传路由是否限制了文件大小？
• 如果签名验证需要原始正文，支付 Webhook 路由是否使用原始正文？
• 已弃用的路由是否已禁用或受到保护？
• 内部路由是否禁止公开访问？
• 测试／开发路由是否已在生产环境中禁用？
• 路由名称是否清晰，且未泄露内部实现细节？
• DELETE/PATCH 等危险方法是否受到保护？
• 是否在需要时为路由添加了版本号？

通常需要严格保护的敏感路由：

/auth/login
/auth/register
/auth/refresh
/auth/logout
/auth/forgot-password
/auth/reset-password
/auth/verify-email
/auth/otp
/users/:id
/admin/*
/payments/*
/webhooks/*
/files/upload
/ai/*
/credits/*
/subscriptions/*

绝不要在没有后端角色检查的情况下公开管理路由。

错误示例：

Frontend hides admin button, but backend route has no admin guard.

正确示例：

Backend verifies user role/permission before executing admin action.

---

controllers/ 安全检查清单

控制器只应处理 HTTP 层面的工作。

对于每个控制器文件，请检查：

• 没有直接在控制器中编写敏感业务逻辑
• 没有直接执行复杂的数据库查询
• 除非项目惯例要求，否则不要在控制器中进行密码哈希
• 不要随意散布令牌创建逻辑
• 不要将直接支付验证逻辑与 HTTP 代码混在一起
• 使用请求正文前，先对其进行验证
• 使用请求参数前，先对其进行验证
• 使用查询参数前，先对其进行验证
• 当前用户来自经过验证的身份验证上下文，而非请求正文
• 执行敏感操作前，先检查角色／权限
• 应使用经过身份验证的用户 ID 时，控制器不会信任请求正文中的 userId
• 控制器不会暴露内部错误
• 控制器不会返回敏感字段
• 请求正文包含敏感信息时，控制器不会完整记录该正文
• 控制器不会在未经服务器验证的情况下接受前端传来的价格、角色、额度、套餐或权限

危险模式：

POST /users/update
body: { userId, role: "admin" }

安全模式：

Use authenticated user ID from token/session.
Allow role changes only through protected admin service.

控制器绝不能信任：

req.body.userId
req.body.role
req.body.isAdmin
req.body.credits
req.body.price
req.body.subscriptionStatus
req.body.paymentStatus
req.body.emailVerified

除非经过严格的服务器端验证。

---

services/ 安全检查清单

服务层包含业务逻辑。

对于每个服务文件，请检查：

• 业务规则已在服务器端强制执行
• 访问数据前会检查用户所有权
• 敏感操作设有角色／权限检查
• 额度／分钟数／令牌扣减是原子操作
• 支付状态已在服务器端验证
• 用户无法修改其他用户的数据
• 软删除或已禁用的用户无法执行操作
• 在需要的地方阻止已暂停的用户
• 在需要的地方要求完成电子邮件验证
• 密码重置流程安全
• OTP 流程安全
• 刷新令牌轮换安全
• 拒绝重复使用或已撤销的令牌
• 安全地记录敏感状态变更
• 关键操作使用事务
• 已考虑竞态条件
• 已处理重复请求的幂等性
• 安全地处理外部服务故障
• 服务不会直接泄露提供商错误
• 服务不包含可能逐渐不一致的重复授权逻辑

始终检查所有权。

示例：

Before returning project/order/document by ID, verify it belongs to the authenticated user or the user has permission to access it.

危险：

getDocument(documentId)

安全：

getDocument(documentId, currentUserId)

---

repositories/ 或 data-access/ 安全检查清单

仓库包含数据库查询。

对于每个 repository/data-access 文件，请检查：

• 查询使用参数化方式
• 不存在原始 SQL 注入风险
• 不使用字符串拼接 SQL
• 用户控制的筛选条件采用白名单
• 排序字段采用白名单
• 分页范围受限
• 不存在无上限的查询
• 除非必要，否则不查询敏感字段
• 不必要时不返回密码哈希
• 不必要时不返回刷新令牌
• 不必要时不返回内部标记
• 在需要时筛除软删除记录
• 在需要时应用租户/用户隔离
• 常用查找字段有索引
• 对关键的多步写入使用事务
• 重要字段有唯一约束
• 不直接向客户端泄露查询错误
• 不在零散文件中重复数据库访问

不安全的原始查询模式：

SELECT * FROM users WHERE email = '${email}'

安全示例：

Use ORM-safe queries or parameterized SQL.

对于多租户应用，每个查询都必须考虑租户隔离。

示例：

WHERE id = documentId AND userId = currentUserId

或

WHERE id = documentId AND organizationId = currentOrganizationId

---

models/ entities/ schemas/ 安全检查清单

模型定义数据结构。

对于每个 model/entity/schema 文件，请检查：

• API 响应中绝不暴露密码字段
• 绝不暴露令牌字段
• 隐藏内部安全字段
• 为敏感字段设置适当的默认值
• 在需要时添加唯一约束
• 必填字段确实设为必填
• 角色使用安全的枚举值
• 订阅/支付状态使用安全的枚举值
• 以一致的方式处理软删除字段
• 包含创建/更新时间戳
• 在需要时包含所有权字段
• 在需要时包含租户/组织 ID
• 对敏感操作包含审计字段
• 查找字段有索引
• 在需要时加密敏感数据
• 尽量减少个人身份信息（PII）
• 默认角色安全，通常为普通用户
• 默认积分/免费配额不易被滥用
• 普通的创建/更新 DTO 无法设置管理员标记

敏感模型字段：

password
passwordHash
refreshToken
refreshTokenHash
resetToken
otp
otpHash
apiKey
apiKeyHash
twoFactorSecret
emailVerificationToken
role
isAdmin
permissions
credits
balance
subscriptionStatus
paymentStatus
stripeCustomerId
providerAccountId
deletedAt
blockedAt
suspendedAt

除非绝对必要，否则不要暴露这些字段。

---

DTOs / validators / schemas 安全检查清单

验证文件极其重要。

对于每个 DTO/schema/validator 文件，请检查：

• 存在请求正文验证
• 存在查询参数验证
• 存在路径参数验证
• 拒绝或剔除未知字段
• 验证电子邮件格式
• 执行密码策略
• 验证文件元数据
• 限制枚举值
• 限制数值范围
• 限制字符串长度
• 限制数组最大长度
• 验证嵌套对象
• 谨慎验证 URL
• 将重定向 URL 加入白名单
• 将排序字段加入白名单
• 将筛选字段加入白名单
• 限制日期范围
• 用户无法发送受保护字段
• 用户无法设置角色/管理员/积分/支付状态
• 验证错误安全且一致

绝不允许批量赋值。

不安全：

updateUser(req.body)

安全：

Only allow specific fields:
name
avatar
bio
timezone

普通用户更新时禁止设置：

role
isAdmin
permissions
credits
subscriptionStatus
emailVerified
passwordHash

---

middleware/ guards/ 安全检查清单

中间件和守卫用于保护路由。

请检查：

• 身份验证中间件正确验证令牌
• 拒绝过期令牌
• 拒绝无效令牌
• 如果支持撤销，则拒绝已撤销的令牌
• 用户在数据库中仍然存在
• 用户未被封禁/停用
• 角色守卫检查后端角色，而非前端提供的角色
• 权限守卫检查精确的操作/资源
• 对敏感路由应用速率限制中间件
• 存在请求 ID 中间件
• 已应用安全标头
• CORS 配置安全
• 已配置请求正文大小限制
• 文件上传中间件具有限制
• 通过代理时 IP 提取正确
• 中间件顺序正确
• 公共路由明确设为公开
• 内部路由受到保护

常见守卫：

auth guard
role guard
permission guard
api key guard
rate limit guard
ownership guard
verified email guard
subscription guard
admin guard

---

auth/ 安全检查清单

身份验证需要进行深入检查。

检查：

• 密码是否使用安全算法进行哈希处理
• 是否从未以明文形式存储密码
• 登录是否受到速率限制
• 注册是否受到速率限制
• OTP 是否受到速率限制
• 密码重置是否受到速率限制
• 刷新令牌端点是否受到保护
• 是否尽可能轮换刷新令牌
• 如果刷新令牌存储在数据库中，是否以哈希形式存储
• 注销时是否撤销刷新令牌／会话
• 密码重置令牌是否只能使用一次
• 密码重置令牌是否会快速过期
• 邮箱验证令牌是否会过期
• OTP 是否会快速过期
• OTP 尝试次数是否有限制
• JWT 密钥是否足够强
• JWT 算法是否受到限制
• 令牌过期时间是否合理
• 访问令牌是否不包含敏感数据
• 令牌载荷是否精简
• 如果用户角色可能发生变化，是否不会永远盲目信任令牌中的用户角色
• 被停用的用户是否无法继续使用旧令牌
• 是否在需要时进行会话／设备跟踪
• 如果实现了双重身份验证，是否安全地处理
• 在可行的情况下，是否避免账号枚举

令牌载荷通常应只包含最少的数据：

sub/userId
sessionId or tokenVersion if used
role only if safe for your system
iat
exp
iss/aud if used

切勿将以下内容放入令牌：

password
passwordHash
refreshToken
otp
private API keys
payment details
full user profile
sensitive PII

---

令牌安全检查清单

对于 JWT／访问令牌：

• 过期时间较短
• 密钥／私钥足够强
• 算法正确
• 载荷中不含敏感数据
• 如果使用，则验证签发者／受众
• 验证过期时间
• 谨慎处理时钟容差
• 不接受 none 算法
• 不在未验证的情况下解码
• 在需要时轮换签名密钥

对于刷新令牌：

• 过期时间长于访问令牌
• 安全存储
• 尽可能在数据库中以哈希形式存储
• 尽可能在使用时轮换
• 注销时撤销
• 更改密码时撤销
• 出现可疑活动时撤销
• 在需要时关联到设备／会话

对于 API 密钥：

• 仅显示一次
• 仅存储哈希版本
• 允许撤销
• 允许设置过期时间
• 限定权限范围
• 对使用频率进行限制
• 安全记录使用情况
• 切勿在日志中发送完整密钥

---

cookies/ sessions 安全检查清单

如果后端使用 Cookie：

• 使用 HttpOnly
• 在生产环境中使用 Secure
• 尽可能使用 SameSite Lax 或 Strict
• 设置适当的域
• 设置适当的路径
• 设置适当的 maxAge／expires
• 在需要时使用 CSRF 保护
• 登录时重新生成会话
• 注销时销毁会话
• 不要直接在 Cookie 中存储敏感数据
• 不要使用未经签名或签名较弱的 Cookie

对于跨站身份验证：

• CORS 必须严格
• 必须谨慎配置 credentials
• 必须考虑 CSRF 风险

---

payments/ 安全检查清单

对于支付模块：

• 切勿信任来自前端的价格
• 未经后端验证，切勿信任来自前端的套餐名称
• 切勿信任来自前端的支付状态
• 在服务端创建结账／支付意图
• 验证 Webhook 签名
• 在服务提供商要求时使用原始请求体
• 存储支付服务提供商事件 ID
• 确保 Webhook 具备幂等性
• 安全处理重复的 Webhook
• 处理支付失败
• 处理退款
• 在需要时处理拒付
• 处理订阅取消
• 处理订阅续费
• 在验证支付之前，不授予付费访问权限
• 仅存储最少的支付信息
• 除非符合要求且确有必要，否则不要存储卡片详情
• 检查用户是否拥有该笔支付／客户账户
• 防止套餐／价格被篡改
• 安全记录支付事件

危险做法：

POST /upgrade
body: { plan: "pro", paid: true }

安全做法：

Backend verifies payment through provider webhook before upgrading user.

---

credits/ 使用量/ AI 额度安全检查清单

对于积分、令牌、时长或 AI 使用量系统：

• 切勿信任前端提供的使用量
• 在服务端跟踪使用量
• 以原子方式扣除积分
• 使用数据库事务或原子更新
• 防止余额变为负数
• 防止重复扣款
• 对开销较大的端点实施速率限制
• 添加单用户和单 IP 限制
• 添加免费额度滥用防护
• 保留使用量日志
• 将免费积分与付费积分分开
• 防止用户为获取免费额度而创建无限个账户
• 考虑进行电子邮件/电话验证
• 谨慎考虑设备/会话/风险信号
• 不要只依赖前端计时器
• 不要只依赖客户端记录的时长
• 验证后端的实际使用量
• 为手动调整积分添加管理员审计日志

---

files/ 上传安全检查清单

对于文件上传模块：

• 限制文件大小
• 限制文件数量
• 验证 MIME 类型
• 验证扩展名
• 不要只信任用户提供的 MIME 类型
• 生成安全的文件名
• 在生产环境中，将文件存储在应用服务器磁盘之外
• 尽可能使用对象存储
• 对私有文件使用签名 URL
• 不要公开私有文件
• 扫描危险文件类型或限制其上传
• 防止路径遍历
• 防止覆盖文件
• 按需移除元数据
• 在后台任务中处理大型文件
• 不要执行上传的文件
• 除非经过清理，否则不要允许任意上传公开 HTML/SVG 文件
• 按需验证图像尺寸
• 如果可能，为高风险应用添加病毒扫描
• 使用身份验证和速率限制保护上传路由

危险文件类型通常需要格外谨慎：

html
svg
exe
sh
bat
php
js
docm
xlsm
zip

---

integrations/ 安全检查清单

对于第三方集成：

• 不要将 API 密钥硬编码
• 不要记录 API 密钥
• 集中管理服务提供商客户端
• 配置超时
• 控制重试
• 清理服务提供商错误信息
• 验证 Webhook 签名
• 安全存储 OAuth 令牌
• 将权限范围设为最小
• 验证外部 URL
• 获取 URL 时检查 SSRF 风险
• 按需轮换密钥
• 外部调用失败时，不要暴露敏感详情
• 不要完整记录敏感的服务提供商载荷

对于 URL 获取功能，请检查 SSRF 防护：

• 屏蔽 localhost
• 屏蔽私有 IP 地址段
• 屏蔽元数据 IP 地址
• 尽可能将域名加入允许列表
• 限制重定向次数
• 限制响应大小
• 设置超时
• 验证协议
• 按需仅允许 http/https

---

admin/ 安全检查清单

管理员功能需要严格保护。

请检查：

• 管理员路由要求身份验证
• 管理员路由要求管理员角色或权限
• 在服务端检查管理员角色
• 记录管理员操作的审计日志
• 防止管理员意外暴露密钥
• 管理员用户列表不暴露密码/令牌字段
• 不能通过公开注册创建管理员
• 保护角色变更
• 保护权限变更
• 危险操作需要确认或额外检查
• 将超级管理员操作与普通管理员操作分开
• 对管理员路由实施速率限制
• 对管理员搜索/列表端点进行分页
• 保护管理员导出功能
• 如果实现管理员模拟功能，则记录并限制该功能

重要的管理员审计字段：

actorUserId
targetUserId
action
resourceType
resourceId
oldValue
newValue
ipAddress
userAgent
createdAt

---

jobs/ queues/ workers 安全检查清单

对于后台任务：

• 任务载荷不应包含不必要的密钥
• 任务载荷不应包含原始密码/令牌
• 任务处理前先验证载荷
• 尽可能确保任务具备幂等性
• 安全处理重复任务
• 对失败任务进行有限次数的重试
• 为关键任务提供死信处理机制
• 保护队列管理面板
• Worker 日志不得泄露敏感数据
• 执行敏感操作前，任务应检查数据库的当前状态
• 支付/积分任务应确保事务安全
• 电子邮件任务不得将数据发送给错误的收件人
• 文件处理任务应验证文件所有权

---

events/ 安全检查清单

对于事件驱动代码：

• 事件中不应包含不必要的敏感数据
• 事件处理程序具有幂等性
• 事件处理程序会验证当前状态
• 关键事件处理会记录日志
• 不可信客户端无法直接触发事件
• 内部事件不会作为公共 API 暴露
• 失败的处理程序会安全地重试
• 重复事件不会导致积分、支付或邮件重复处理

---

error handling 安全检查清单

对于错误处理文件：

• 生产环境响应中不包含堆栈跟踪
• 客户端响应中不包含原始数据库错误
• 不会直接暴露 ORM 约束详情
• 错误消息中不包含机密值
• 错误消息中不包含令牌值
• 不会记录敏感路由的完整请求正文
• 验证错误清晰但安全
• 涉及敏感信息时，未找到响应不会泄露过多信息
• 在需要时，身份验证错误采用通用提示
• 内部错误会连同请求 ID 一起记录
• 客户端收到安全的消息和错误代码

错误示例：

PrismaClientKnownRequestError: Unique constraint failed on users_email_key

正确示例：

Email already exists.

错误示例：

JWT_SECRET missing: sk_live_xxx

正确示例：

Server configuration error.

---

logging 安全检查清单

对于日志记录器文件：

• 日志采用结构化格式
• 日志包含请求 ID
• 在安全的情况下，日志包含用户 ID
• 日志不包含密码
• 日志不包含 OTP
• 日志不包含完整令牌
• 日志不包含 API 密钥
• 日志不包含银行卡数据
• 日志不包含私有文件
• 日志不包含敏感请求正文
• 开发环境和生产环境的日志有所区别
• 安全事件会记录日志
• 安全地记录登录失败尝试
• 管理员操作会记录日志
• 安全地记录支付生命周期事件

对以下字段进行脱敏：

password
passwordHash
token
accessToken
refreshToken
authorization
cookie
otp
secret
apiKey
card
cvv
privateKey

---

response/ serializer/ mapper 安全检查清单

对于响应数据整形：

• 移除密码字段
• 移除令牌字段
• 移除内部标记
• 移除服务提供商机密
• 移除私有元数据
• 仅在需要时返回用户角色
• 不向普通用户返回仅限管理员使用的字段
• 错误响应格式保持一致
• 列表响应采用分页
• 限制大型负载
• 不会意外包含敏感的嵌套关联

安全的用户响应：

id
name
email
avatar
role if needed
createdAt

不安全的用户响应：

passwordHash
refreshToken
resetToken
otp
apiKey
internalNotes

---

CORS 和标头安全检查清单

检查：

• 生产环境中的 CORS 来源设置严格
• 使用凭据时不使用通配符 CORS
• 限制允许的方法
• 限制允许的标头
• 启用安全标头
• 尽可能禁用 X-Powered-By
• 视情况考虑内容安全策略
• 对 HTTPS 应用，在代理/服务器层启用 HSTS
• 设置请求正文大小限制
• 设置 JSON 解析器限制
• 压缩配置安全
• 代理信任设置正确

对于 Node/Express 应用，检查是否使用 helmet 或同等的安全标头工具。

---

数据库安全检查清单

检查：

• 数据库凭据存储在环境变量中
• 数据库用户遵循最小权限原则
• 已审查迁移
• 敏感列受到保护
• 身份验证查询字段已建立索引
• email/username/provider ID 具有唯一约束
• 在适用的情况下设置外键
• 关键操作使用事务
• 始终一致地处理软删除
• 生产环境已启用备份
• 生产数据库未公开暴露，除非已做好安全防护
• 已控制 SQL 注入风险
• 仔细审查 ORM 原始查询
• 已实施租户隔离

高风险数据库操作：

deleteMany
updateMany
raw SQL
unfiltered findMany
bulk role updates
manual credit updates
subscription status updates

---

API 滥用防护检查清单

检查以下项目是否启用了速率限制：

login
signup
forgot password
reset password
OTP send
OTP verify
email verification
file upload
AI generation
credit usage
payment creation
webhooks
admin routes
search endpoints
public forms

采用分层限制：

per IP
per user
per account
per email
per phone
per device/session where appropriate

---

授权检查清单

对于每个端点，请询问：

Who can access this?
Can a normal user access it?
Can a logged-out user access it?
Can user A access user B's data?
Can user change role/credits/payment status?
Can admin action be performed by non-admin?
Is organization/team ownership checked?
Is subscription required?
Is email verification required?
Is account active/not suspended?

常见的授权缺陷：

GET /documents/:id returns any document by ID
PATCH /users/:id lets users update others
DELETE /projects/:id does not check ownership
POST /admin/users/:id/role has no admin guard
GET /orders/:id leaks other users' orders

始终检查对象级授权。

---

安全审查输出格式

审查后端项目时，请按以下格式回复：

## Security Summary

Overall risk: Low / Medium / High / Critical

## Critical Issues

- Issue
- Why it is dangerous
- Where it exists
- How to fix it

## High Priority Fixes

- Issue
- Recommended fix

## File-by-File Notes

File: path/to/file
Problems:
- ...
Fix:
- ...

## Token/Auth Issues

- ...

## Route Protection Issues

- ...

## Data Leak Issues

- ...

## Payment/Credit Abuse Issues

- ...

## Rate Limit Issues

- ...

## Recommended Secure Structure

Show improved structure if needed.

## Safe Code Changes

Provide code only for necessary changes.

## Final Checklist

- [ ] Input validation
- [ ] Auth middleware
- [ ] Role/permission checks
- [ ] Ownership checks
- [ ] Rate limiting
- [ ] Secure token handling
- [ ] Safe error handling
- [ ] Sensitive fields removed
- [ ] Payment/webhook verification
- [ ] File upload limits
- [ ] Logging redaction
- [ ] Env validation

---

生成新的后端代码时

每个新的后端功能都必须默认包含安全措施：

• 验证
• 如有需要，进行身份验证
• 如有需要，进行授权
• 如有需要，检查所有权
• 使用安全的数据库查询
• 安全地处理错误
• 安全地映射响应
• 为敏感端点提供速率限制建议
• 为关键安全行为编写测试
• 代码中不包含机密信息
• 不记录敏感信息
• 不信任客户端提供的角色、价格或额度

提交最终代码前，请在心中检查：

Can this endpoint be abused?
Can another user access this data?
Can the client fake this value?
Can this leak sensitive data?
Can this be spammed?
Can this create race conditions?
Can this break payment/credit logic?
Can this expose secrets in logs/errors?

最终规则

安全并非只涉及一个文件或一个中间件。

必须在每个路由、控制器、服务、仓库、模型、验证文件、集成、作业和部署配置中检查安全性。

编写后端代码时，始终假设攻击者会查看前端、修改请求、窃取令牌、猜测 ID、刷接口、伪造 Webhook、上传恶意文件，并尝试成为管理员。