X-API-Key 必须绑定请求来源并配合IP白名单与滑动窗口限流，密钥须通过环境变量或配置中心注入、禁止硬编码，各业务系统应使用独立RAM用户与最小权限策略，签名验证需包含时间戳和随机串以防止重放攻击。
X-API-Key 必须和请求来源绑定，否则光靠一个密钥根本防不住盗用。单纯校验 Key 是否存在，等于给攻击者开了个“免登录通道”。
密钥不能硬编码，更不能写进前端或 Git 仓库
硬编码的 AccessKey 是短信资费失控的第一原因——2023 年阿里云安全报告里，31% 的密钥泄露事件都源于 GitHub 上搜出的 AK/SK。你本地测试用的密钥，一旦被 commit 进去，几秒内就会被爬虫扫走。
- 所有密钥必须通过环境变量或配置中心（如 Nacos、Apollo）注入，启动时加载
- Spring Boot 项目禁用
application.yml明文写access_key_secret，改用@Value("${sms.access.key:}")+ 启动参数传入 - CI/CD 流水线中禁止 echo 密钥，Git hooks 加 pre-commit 检查含
AK|SK|secret的文件
每个业务系统配独立 RAM 用户 + 最小权限策略
别再用一个主账号的密钥给所有项目用。RAM 权限不隔离，就等于把短信发送权交给了所有调用方——哪怕只是查日志的后台系统，也能顺手发 10 万条验证码。
- 开发环境只给
AliyunDysmsReadOnlyAccess，连SendSms接口都不开放 - 生产环境用自定义策略，精确到模板 ID：
"Resource": "acs:dysmsapi:*:*:template/SMS_LOGIN_VERIFY" - 禁用
*通配符，尤其不能放开dysmsapi:QuerySendDetails——攻击者可借此反查手机号列表
Key + IP + 频控三重绑定，缺一不可
只做 Key 校验，相当于门锁只装了弹簧插销；加上 IP 白名单和 Redis 滑动窗口限流，才算真正上了防盗门+监控+报警。
- IP 绑定必须服务端校验：
request.getRemoteAddr()取真实出口 IP（注意 Nginx 要配proxy_set_header X-Real-IP $remote_addr;） - 限流 key 设计为
sms:limit:{phone}:{api_key}，避免不同项目共用同一手机号导致误限 - 滑动窗口用 Lua 脚本原子执行，防止并发超发：
redis.eval("return redis.call('incr', KEYS[1]) == 1 and redis.call('expire', KEYS[1], ARGV[1])", 1, key, "60")
签名验证比 Key 更可靠，但必须带时间戳和随机串
只传 X-API-Key 是静态凭证，截获即失守；加签是动态凭证，每次请求都唯一，且自带防重放能力。
- 签名原文必须包含
timestamp（毫秒级）和nonce（UUID），服务端校验abs(now - timestamp) - 排序后拼接规则要严格统一：key 升序 →
k1=v1&k2=v2→&key=xxx→SHA256，大小写敏感 - 千万别把
secret当作 URL 参数传——它只能参与签名计算，绝不落地、不透传、不打日志
真正的防护盲区不在算法多复杂，而在于「同一个密钥是否同时用于测试、预发、生产」，以及「错误日志里有没有打印出完整请求头」。哪怕你用了 JWT + 国密 SM3 签名，只要一条 log.info("header: {}", headers) 泄露了 X-API-Key，整套机制就归零。
