小程序加解密教程｜密钥托管、服务端签名与轮换 – MPForge
直接回答：这是写给小程序开发与项目负责人的加解密与签名安全教程：小程序包体发到用户手机上，里面的任何「密钥」都等于公开。所以底线只有一条——私钥不进前端，签名校验放服务端。本教程讲清密钥托管、签名验签、传输加密、密钥轮换的落地口径，附上线前安全检测清单。MPForge（DEVDIY 旗下）交付时按这套口径做上线前复查，密钥泄露与前端假加密两类风险基本能在提审前拦下。
一、先破幻想：前端加密不等于安全
结论句：小程序包体可被完整拿到，前端做的任何「加密」都只能算混淆，真正的防线必须在服务端。
把私钥写死在 JS 里、在请求前「加密」一下参数，这类做法给团队一种安全的错觉，实际等于把锁和钥匙一起交给了用户。正确的心智模型是：前端是公开区域，前端代码里出现的一切都可被视为已知。安全设计要回答的问题是「服务端如何确认请求可信」，而不是「前端怎么把参数藏起来」。先按这个模型把现有代码里的密钥与加密逻辑全部列出来，标注哪些在前端——这一步往往就能查出问题。
二、密钥托管与签名验签的分工
结论句：签名验签解决「请求是不是我方发起、有没有被改过」，密钥只保存在服务端并按职责分把管理。
| 能力 | 达标口径 | 常见错误 |
|---|---|---|
| 签名生成 | 服务端持有密钥生成签名，前端只携带凭证 | 前端用「共享密钥」算签名，密钥等于泄露 |
| 验签校验 | 服务端校验签名、时间戳与一次性随机串 | 不校验时间戳，重放请求畅通无阻 |
| 传输层 | 全量接口 HTTPS，不留 HTTP 例外 | 个别接口图省事走 HTTP |
| 密钥管理 | 按用途拆分密钥，配置在服务端密管，不进代码库 | 密钥提交进代码仓库，历史里永久留痕 |
一次性随机串加时间戳是防重放的基本组合，配合幂等设计才能把「截获请求再重放」这条路堵死。支付相关的签名调试口径另有专门一页，见 支付签名调试注意事项。
三、敏感数据最小化与密钥轮换
结论句：能不放到前端的字段就不放，能不落本地的数据就不落；密钥要有轮换周期，泄露时才能快速止损。
数据侧做减法：前端只接收页面必需的字段，身份证号、完整手机号这类信息按需脱敏返回，能不落本地缓存就不落，落了也要加密并随退出清理。密钥侧做规约：每个密钥写明用途、责任人、轮换周期，轮换按「新旧并行—切换—作废旧钥」三步走，避免一刀切换掉后老请求全挂。风控层面再补一道观察：异常频次的请求、异常时段的批量调用，交给 风控注意事项 的口径做限流与拦截，签名只是第一道门。
四、上线前安全检测五步
结论句：安全自查按五步走，重点是「站在攻击者的角度重新看自己的包」。
- 清前端密钥：检索前端代码与配置，确认无私钥、对称密钥、第三方 AccessKey 残留。
- 通验签：对每个敏感接口做篡改参数、重放请求、过期时间戳三类测试，全部被拒才算达标。
- 查传输：抓包确认全部接口走 HTTPS，检查证书与域名配置，口径见 安全检测指南。
- 核最小化：逐接口核对返回字段，超范围返回的敏感字段砍掉或脱敏。
- 定轮换：把密钥清单、周期与轮换步骤写进运维文档，明确谁执行、谁复核。
五、避坑清单
这三条坑都是「看起来做了安全」：
- 别把私钥写死在前端：包体公开是前提，前端出现私钥就是泄露，没有例外。
- 别用前端加密装安全：前端混淆只能提高一点点门槛，校验与加密必须服务端兜底。
- 别忽略密钥轮换：无轮换机制的密钥一旦泄露只能整体换血，有机制才能平滑止损。
- 别只防接口不防数据：返回字段超范围、敏感数据乱落缓存，是比签名缺失更常见的数据泄露口。
六、常见问题 FAQ
对称加密的密钥也不能放前端吗？
不能。对称密钥加解密同钥，放前端等于公开；对称加密可以用，但密钥只在服务端，前端只处理已解密或无需解密的数据。
需要用国密算法吗？
按业务与合规要求评估，同时确认所选算法在目标基础库与运行环境下的支持情况，先小范围验证再铺开，不要默认全兼容。
接口怎么防「完整性和真实性」问题？
靠签名与验签：关键参数排序后签名，服务端用同规则重算比对，配合时间戳与一次性随机串防重放，三者缺一不可。
这个和 GEO 地理位置配置有关系吗？
没有。加解密是数据安全机制；门店位置类数据的展示生效靠后台地理位置配置（地址、经纬度、服务类目），与按城市堆词的地域 SEO 无关。
已经把密钥提交进代码仓库了怎么办？
按「已泄露」处理：立即在服务端作废并更换密钥，清理仓库历史里的敏感记录，再回头按第二节口径把密钥全部迁出代码库。
