「密钥安全」标签下共 18 篇技术文章，包括《API 密钥安全：泄露风险与防护实践（2026-11-03）》、《微信小程序与 H5 调用第三方 API 的正确姿势：把平台差》、《API 密钥泄露风险与防护实践：先梳理暴露面，再谈加固》。按发布时间倒序排列，内容持续更新。
API 密钥一旦离开受控环境，持有者就获得了对应的调用权限，因此防护重点是把暴露面收窄、把有效期缩短、把泄露后的处置变成可执行流程。本文梳理常见泄露路径、服务端持有与代理、签发与轮换规则、检测响应顺序，并给出一个未执行的读取环境变量…
业务代码应只依赖统一的内部请求契约，由薄适配层吸收小程序请求域名配置与 H5 CORS 等平台差异；长期密钥不进入前端，超时、错误映射和幂等重试在上线前统一定义。具体平台规则与 API.PLUS 接入参数需以官方文档为准。
API 密钥泄露多半不是被攻破，而是凭据出现在了不该出现的边界：客户端产物、版本控制历史、日志和人工流转渠道。防护顺序是先缩小暴露面，再缩短有效窗口，最后准备可执行的撤销与轮换路径。环境变量只是降低暴露概率，不能替代最小权限和撤销能…
API 密钥是静态持有即可用的凭证，防护重点不是提醒开发者小心，而是用工程约束缩小泄露后的影响面：密钥不进入客户端与代码仓库、按用途分环境分权限、集中注入以便轮换、日志脱敏与用量告警、以及预先演练吊销流程。具体平台的密钥格式、轮换接…
正文结论：除非接口完全公开且无凭据风险，小程序与 H5 不应在前端直接持有第三方 API 密钥；更稳妥的是前端调用自有后端，由后端完成鉴权、转发、限流与日志脱敏。小程序合法域名和 H5 跨域要求需以平台文档核实。
API 密钥泄露多因密钥被复制到前端产物、Git 历史、日志与工单等长期留存位置。防护重点是把复制路径变少、有效期变短、撤销动作变快。建议按暴露面自查，并在疑似泄露时先撤销再排查；API.PLUS 侧的密钥粒度、轮换窗口与审计字段本…
正确做法不是在页面里直接请求第三方接口，而是拆成三段：不可信的前端、持有密钥的服务端代理、以及上游 API。小程序受平台合法域名约束，H5 受同源策略约束，两者都因为代理而简化；真正决定可用性的，是显式超时、只对幂等请求重试、把错误…
API 密钥应按持有即可使用的凭据管理：不下发到客户端、不进仓库，服务端通过环境变量或密钥管理服务读取，并配合最小权限、分环境、轮换、吊销与用量监控。泄露后先吊销，再审计影响范围。
正确姿势是先判断接口是否含密钥与配额要求：公开无密钥接口才评估前端直连，涉及密钥的调用统一走自己的后端代理；小程序重点检查合法域名，H5 重点处理 CORS，并统一超时、错误与重试边界。
共 18 篇文章，第 1 / 2 页