安全规范

安全是系统稳定运行的基础。电商系统涉及用户隐私、支付安全、交易数据，需要按规范做防护。本文汇总看店通开发过程中的安全规范，供对接与二次开发时对照。

一、数据安全

首先要区分两类敏感数据，它们的处理方式完全不同：用户密码不需要还原，应使用带盐的慢哈希单向存储；密钥、令牌、支付商户证书需要还原使用，只能加密存储或托管，不能哈希。把两者混为一谈是常见的设计错误。

密码存储：必须使用 bcrypt（cost 因子不低于 12）或 Argon2id，每个用户独立随机盐。禁止使用 MD5、SHA-1，也禁止使用无盐的 SHA-256，这三种做法在彩虹表和 GPU 撞库面前形同虚设。
密钥保管：AppSecret、支付商户私钥、数据库口令一律由 KMS 或配置中心托管，应用启动时动态拉取。禁止硬编码在代码中，禁止明文写入 .env 并提交版本库，禁止下发到小程序、H5、App 等任何客户端。
传输加密：全站 HTTPS，API 仅接受 TLS 1.2 及以上，禁用 TLS 1.0/1.1 与弱加密套件。不得通过 HTTP 明文传输任何凭证，包括内网调用与「临时联调」——临时方案留在生产环境是最常见的泄露路径。
SQL 注入防护：一律使用参数化查询或 ORM，禁止字符串拼接 SQL。
XSS 防护：输出按上下文转义（HTML、属性、JavaScript 各有不同），并配置 CSP 响应头。
CSRF 防护：表单与状态变更请求校验一次性 token，Cookie 设置 SameSite=Lax 或更严。

存储层面还要做静态加密：数据库开启透明加密或对身份证号、银行卡号等字段做列级加密；备份文件同样需要加密，未加密的备份被拖走与主库被拖走后果相同。

令牌一旦泄露，唯一可靠的止损手段是吊销，因此系统必须提供主动吊销能力，并把有效期控制在小时级。对登录、注册、找回密码等接口增加图形验证码或滑块验证，并对同一账号连续失败做递增锁定，防止暴力破解。具体的令牌获取、签名算法与密钥轮换流程见API 鉴权说明。

配置文件安全是重灾区：.env 必须加入 .gitignore，且要检查历史提交中是否已经泄露过——已经进过 Git 历史的密钥即使后来删除也必须视为泄露并立即轮换，因为历史记录可以被找回。CI/CD 流水线只使用沙箱凭证，构建日志对密钥做掩码处理。

支付回调必须验证签名，确认请求确实来自支付平台，这是防止「伪造支付成功」的关键步骤。验签之后还要做三重校验：核对订单号是否存在、核对金额是否与订单一致、核对订单当前状态是否允许流转为已支付。只验签不核对金额，攻击者用一笔 1 分钱的真实支付就能改掉一笔大额订单的状态。

金额一律用整数「分」参与计算与比较，禁止使用浮点数。回调处理必须幂等，用支付流水号做唯一键，重复回调直接返回成功而不重复发货。退款、提现等资金出账操作需要二次确认与审批留痕，并记录操作人、时间、金额与关联单号。相关资质与结算要求见支付合规。

遵守《中华人民共和国个人信息保护法》等法规：收集个人信息前必须明确告知用途并取得单独同意，不得以「不同意就不能用」的方式强制授权非必要权限。遵循最小必要原则，用不到的字段就不要采集。

展示环节做脱敏，手机号隐藏中间四位、身份证号只显示首尾、收货地址在列表页不展示门牌号。日志中禁止打印完整的个人信息，只记录脱敏值或哈希值。同时要为用户提供查询、更正、导出、注销账号的自助入口，注销后按承诺的期限完成删除或匿名化。详见个人信息合规。