Express 与 Sequelize 业务 API：权限、报价和库存事务

本文来自对一个个人 TypeScript/Express 服务默认分支的静态源码审阅。观察范围包括应用装配、JWT 中间件、业务路由、库存与报价控制器及 Sequelize 模型；不公开项目/仓库名称、环境配置、部署地址、默认凭据或源代码。没有安装依赖、运行服务、连接数据库或执行测试，所以下文只描述可从代码确认的结构，不把建议写成已经具备的线上保障。

应用装配：中间件的先后就是请求边界

服务以 Express 组合 JSON/表单解析、访问日志、CORS、统一路由和错误处理中间件，并把多个业务域挂到 API 路由树。模块覆盖身份、商品资料、零件、购物车、收藏、预约、评论、报价、库存、字典与店铺配置。Sequelize 模型分别表示用户、商品、零件、库存日志和报价等实体，模型入口集中声明一部分关联关系。

这种按业务域拆分的结构容易理解：路由声明 URL 和中间件顺序，controller 编排一次请求，model 描述持久化字段。模块变多以后，关键问题不是文件夹有多少，而是入口是否能一眼看出认证、授权、校验和副作用的顺序。Express 中间件必须明确地结束响应或调用 next()；若校验失败后仍继续向下执行，后续 controller 可能在未满足前置条件时运行。Express 中间件说明

当前源码中能确认的风险

以下观察来自 2026-10-14 默认分支的静态源码核对，不包含生产环境、部署变量或数据库状态：

• CORS 同时启用了凭据，并用 origin.startsWith(allowedOrigin) 匹配来源；前缀匹配可能接受伪装成可信域名开头的其他主机。应解析并逐字段精确比较 origin，只允许明确列出的 scheme/host/port；不能把通配符与凭据模式混用。
• 配置模块给 JWT 与数据库连接提供固定的代码默认值，缺少环境配置时服务仍可能继续初始化。生产应对必需密钥、数据库用户和连接参数 fail closed，启动时只报告缺少的变量名，绝不打印值。
• 首次启动会在找不到管理员时自动创建账户，并把默认登录信息写入日志。即便密码字段存的是哈希，固定初始口令和可被集中采集的明文日志仍构成高风险引导方式。应改为部署时一次性随机引导、限时邀请或受控命令，并保证只消费一次、登录后强制更换且日志不含凭据。
• 报价创建只检查清单非空，随后直接使用请求体中的行项目价格和数量计算总额；没有在该路径中从商品目录重读可信价格，也没有明确的数量/金额 schema 校验。客户端金额可篡改，服务端必须按商品 ID、有效状态与当前价格重新计算，并限制行数、数量、金额范围及重复项。
• 库存单笔与批量路径分别先更新库存、再写流水，未把两次写入放入同一事务。批量入库会跳过无效项仍返回成功，批量出库允许部分成功；删除流水还会调整库存后物理删除记录。产品若保留部分成功语义，应逐项返回不可歧义结果；否则整批事务回滚。修正历史不能抹掉审计轨迹，优先用有权限、可追溯的冲正记录。

这些是源码能够证明的实现形态，不代表相关接口已暴露给匿名用户或线上部署仍使用这些默认值。公开文章不复述源码里的具体默认凭据、密钥、仓库标识或部署信息。

建议将每个写操作的流程固定为：解析身份 → 校验字段和权限 → 从数据库读取可信业务状态 → 在事务内完成状态变更和流水 → 提交后发送通知 → 以明确的响应结构返回。错误处理中间件应只记录可诊断的安全信息，不能把堆栈、口令、令牌或数据库连接细节返回给客户端。

JWT 通过不等于拥有管理员权限

审阅到的认证层把令牌验证和管理员角色判断拆成两个中间件；库存读写路由在认证后再要求管理员身份。这个分层易于复用，但每个管理路由都必须逐一确认两层中间件都存在，不能只保护列表页、遗漏批量接口或日志编辑接口。测试应按“匿名、普通用户、管理员、过期令牌、签名无效令牌”覆盖读写路由，而不只验证登录成功。

报价创建路径允许游客提交，且可选令牌中间件在令牌无效时继续按游客身份处理。若这是有意的访客体验，应对“未提供令牌”与“提交了坏令牌”区分处理；对于明确带凭据的请求，通常应拒绝无效令牌，避免调用方误以为操作已使用登录身份。管理员列表、详情与状态更新则应持续要求管理员授权，并对访客提交的信息做防滥用限流和数据最小化。当前代码中的状态更新把请求体状态直接交给 ORM；应由 DTO/枚举白名单限制合法状态，并使用条件更新避免并发覆盖。

报价不能相信浏览器的价格

报价 controller 从请求体接收商品条目，并使用其中的单价与数量计算总价。若客户端能够自行提供价格，攻击者就可以改写金额；即便前端显示的金额正确，也不是服务端可信的业务数据。请求应只提交商品 ID、数量和用户选择，服务端从当前有效商品目录重新读取价格、状态、折扣和币种，再计算每一行与总额。商品已下架、价格刚变化或数量越界时，要有明确的拒绝/重新确认策略。

金额计算应使用整数最小货币单位或可靠的十进制定点类型，明确舍入规则；不可直接依赖 JavaScript 二进制浮点乘法。保存报价时应留存服务端计算的价格快照、币种、规则版本和生成时间，后续商品调价不能悄悄改写既有报价。提交还应有幂等键或业务去重键，避免网络重试创建多份报价。OWASP 的业务逻辑建议明确要求：影响价格与状态的值必须由服务端从可信数据重新推导，不能采用客户端传来的价格或总额。OWASP Business Logic Security

库存与流水必须原子提交

库存出入库由“更新当前库存”和“创建库存流水”两个持久化动作组成。静态审阅到的单笔处理按顺序更新商品后再写流水；批量处理逐行查询并逐行更新，遇到部分无效数据时会跳过或记录错误。若中途发生数据库异常，而两类写入没有共享事务，可能出现库存已经变化但没有对应流水，或一批只完成了一部分却被调用方误当成整体成功。

推荐先校验并规范化整个批次，限制条目数量和重复商品 ID，再用 Sequelize 托管事务一次提交。每个更新、条件检查和流水创建都必须显式带同一个 transaction。扣减库存时，使用带 stock >= quantity 条件的原子更新或行锁，并检查受影响行数，避免两个并发请求同时读取相同旧库存后都成功扣减。任意一项失败时回滚整批，或在产品明确选择部分成功的前提下，返回逐项状态和批次 ID；不能以模糊的“批量成功”掩盖跳过的行。

Sequelize 默认不会自动使用事务；托管事务在回调成功时提交、抛错时回滚，但只有明确把 transaction 传给相关查询和写入，才能让它们处于同一事务中。Sequelize v6 Transactions

初始化凭据与配置治理

首次启动逻辑也是生产安全的一部分。固定默认管理员口令、将凭据写入源代码、启动时把口令打印到日志，都会让“只用于本地初始化”的便利配置变成长期攻击入口。更稳妥的做法是通过部署时的一次性随机凭据、安全的首位管理员邀请或受控命令创建账号；口令只保存强哈希，绝不写入仓库和日志；首次登录后强制更换，并关闭再次自动创建管理员的路径。JWT 密钥、数据库连接和允许的来源列表只从受保护配置注入，启动时校验缺失/弱值，但不输出原值。

CORS 只是浏览器读取响应的策略，不是身份认证。来源匹配应使用规范化后的精确 origin（协议、主机和端口），不要用宽松字符串前缀比较；同时把生产允许列表与本地开发列表分开。请求体大小限制、速率限制、参数 schema、审计字段、健康检查和日志脱敏同样要按部署环境配置。

发布前验收清单

1. 每条写路由验证匿名、普通用户、管理员、无效令牌和权限撤销后的结果。
2. 篡改单价、总价、数量、商品状态和折扣，确认服务端重新计算并返回可解释的结果。
3. 同时提交重复报价、重试请求和并发扣库存，验证幂等性与库存永不为负。
4. 在批处理中人为让最后一条写入失败，确认整批回滚，库存和流水仍一致。
5. 对凭据缺失、弱 JWT 密钥、CORS 变体 origin、超大请求和日志中的敏感字段做负向测试。
6. 通过真实迁移、备份恢复演练和只读生产健康检查验证部署过程；不要把 ORM 自动建表等同于数据库迁移治理。

这次仅审阅了默认分支中的源码文本；没有检查部署环境、生产数据库、密钥轮换、构建结果或运行时行为。文中提到的权限和模块结构是代码观察，事务、金额重算、密钥治理和并发安全是需要验证/落实的工程要求，而不是本项目已通过认证的结论。

参考：Express Middleware、Sequelize v6 Transactions、OWASP Authorization Cheat Sheet、OWASP Password Storage Cheat Sheet。