某天上午，一家客户的粉丝集体收到一条奇怪的群发，内容是博彩链接。运营发誓没人动过后台。排查结果：AppSecret被前任开发写进了前端JS文件里，谁都能扒出来。安全这件事在微信公众号开发里不显山露水，出事时却是核弹级。
密钥是怎么泄出去的
常见泄密路径有四条：密钥硬编码进前端代码或小程序源码包，反编译就能拿到；密钥在聊天记录、邮件里明文传递，离职员工手机里还留着；代码仓库公开，配置文件没进忽略清单；服务器中了马，配置文件被翻走。还有第五条：截图。密钥写在配置截图里发到项目群，群解散了截图还在各人手机里，这种泄漏最难追。四条路径的共同点是没人把密钥当资产管理，随手一放，后患无穷。
泄露的连锁反应
拿到AppSecret的人可以伪造你的服务器身份调用大部分接口：读用户资料、发客服消息、改菜单、群发内容。粉丝看到的一切都顶着你的官方头像，信任崩塌只在一条消息之间。处理流程要快：立即在后台重置密钥、检查最近的接口调用日志、排查异常菜单和自动回复、必要时发布说明安抚用户。重置密钥之后记得把新密钥更新到所有用到它的服务，漏更新一个，支付或消息就断一截，别问怎么知道的。
守门清单
- 密钥只存服务器端环境变量，前端和仓库里绝不出现
- 交接时重置全部密钥，这是规矩不是不信任
- 后台开启管理员验证，敏感操作二次确认
- 接口日志保留并定期抽查异常调用
- 配置截图打码再发群，密钥类信息一律不入图
接口层面的防护也要跟上：调用自己业务接口时加签名和时间戳校验，防重放；写操作限频，防止被脚本刷；敏感操作的日志单独存，出事能回溯到人。这些不是高深技术，都是几行配置和几十行代码的事，区别只在有没有人把安全当回事。
还有一层常被忽略：公众号后台的管理员微信号，离职时必须换绑，我们在接手项目时遇到过登录权限还挂在离职员工微信里的情况，沟通成本极高。安全投入看不见回报，但它保住的是全部已有的回报。比格网络给客户做微信公众号开发的交接清单里，密钥重置和权限换绑是必勾项，安全检查每季度做一轮，做成固定动作，不靠出事推动，交付那天多花十分钟，比日后凌晨救火体面得多。安全事故没有小事，一次侥幸换来的可能就是一场公关危机，钱和口碑一起搭进去，别赌。
