如何保护无用户凭证的公开API不被滥用？注册流程API防护方案咨询

针对你提出的两个问题的明确答复 #

1. 匿名用户签发短期JWT是可行的，落地注意以下规则即可保障安全 #

• 签发逻辑：用户首次访问注册页面/初始化注册流程时，由后端直接签发15~30分钟有效期的超短JWT，Payload仅保留匿名会话ID、签发时间、过期时间三个无业务敏感信息的字段，签名算法优先用RS256非对称加密，私钥仅后端留存，公钥同步到API网关做验签即可。
• 客户端存储方案：SPA应用直接存在内存变量中即可，不要存入localStorage/sessionStorage，避免XSS攻击窃取，页面刷新直接重新申请新的JWT，不影响正常注册流程；移动端应用将JWT存入系统级安全存储区域（iOS Keychain/Android Keystore），禁止明文存储到本地缓存。
• 防盗用规则：JWT签发时直接和当前请求的IP、User-Agent绑定，后续请求携带的JWT如果和请求的IP、UA不匹配直接拒绝访问，即便JWT被截获也无法盗用。后续所有find_person、create_person请求必须携带有效JWT，无有效JWT的请求直接在网关层拦截。

2. 验证码在该场景下防护效果明确，建议分级触发 #

• 针对find_person接口：该接口存在被批量调用扫号、撞库的风险，不用默认加验证码，当单个JWT/单个IP调用频率超过阈值（可设为1分钟5次）时再弹出验证码，校验通过才能继续调用，足以拦截90%以上的批量扫号脚本，也不会影响正常用户的使用体验。
• 针对create_person接口：建议默认加验证码，优先选择行为式验证码，比传统图文验证码体验更好，也能有效拦截批量注册垃圾账号的自动化脚本。

基于你现有规划的防护措施优化建议 #

你已经规划的API KEY分配、速率限制、DDoS防护都是必要的基础防护，补充以下优化点即可覆盖绝大多数风险：

• API KEY安全优化：不要将API KEY硬编码在SPA前端代码、移动端安装包中，极易被反编译窃取。SPA场景建议由后端做API代理，前端请求统一发往后端，后端再携带API KEY调用业务接口；移动端场景采用白盒加密方案存储API KEY，同时支持API KEY定期轮换，泄露后可快速禁用替换。
• 速率限制分层优化：做三层速率限制，第一层DDoS防护层做全局粗粒度限速，第二层API网关层按API KEY+IP维度做中粒度限速，第三层业务层按匿名JWT维度做细粒度限速，create_person接口额外增加单IP单日注册数量上限，避免批量注册垃圾账号。
• 额外补充业务防护：create_person接口返回成功前，增加手机号/邮箱验证码校验逻辑，只有用户输入正确的校验码后账号才正式生效，避免垃圾账号注册后即可使用；两个接口都增加严格的输入参数校验，拦截SQL注入、参数溢出等常见注入攻击。

内容的提问来源于stack exchange，提问作者jfbaro