非可信客户端API安全防护咨询：仿造客户端调用API的应对方案

核心原则 #

所有客户端侧的校验逻辑都不可信，必须把验证重心放在服务端，同时结合多维度的身份、行为验证逻辑——核心是从「验证请求来源」转向「验证请求本身的合法性」。

具体落地措施 #

• 强身份认证+会话与设备绑定
  金融机构普遍采用多因素认证（MFA），比如短信验证码、硬件令牌、生物识别（指纹/人脸），且会话ID必须与用户设备特征（如UA哈希、设备指纹）深度绑定。每次API请求都要校验会话ID与设备特征的匹配度，一旦设备特征变更，强制触发二次验证。
  例：登录时服务端生成包含设备指纹的会话令牌，后续所有API请求必须携带该令牌，服务端实时比对，不一致直接拒绝请求。

• API请求签名机制（金融级标配）

  1. 给官方合法客户端（Web/APP）分配唯一appKey和secretKey，其中secretKey仅存储在服务端和官方客户端的安全存储区（比如iOS Keychain、Android Keystore），绝对不能出现在前端代码中；
  2. 每次请求时，客户端按固定规则（如timestamp + 随机nonce + 请求参数排序拼接 + secretKey）生成签名sign；
  3. 服务端用相同规则重新计算签名，比对一致才处理请求。Web端可通过登录后获取临时会话密钥，避免长期密钥泄露。

• 行为风控与请求频率限制
  建立用户行为基线，比如正常用户的登录频率、操作间隔、API调用序列。一旦出现异常（短时间多次登录、跳过前置操作直接调用核心API、请求频率远超正常范围），直接触发限流、验证码或账号锁定。
  例：正常用户登录后通常先查余额再转账，若恶意客户端直接调用转账API，服务端可判定为异常请求并拒绝。

• CORS与请求头校验强化
  普通CORS仅能限制浏览器跨域，对原生APP无效，需补充：

  • 服务端严格校验Origin和Referer头，仅允许官方域名/包名的请求；
  • 对原生APP，要求携带自定义X-App-Package或X-App-Sign头，服务端与预先登记的官方包名/签名哈希比对，不匹配则拒绝。

• 动态一次性请求令牌
  替代你之前用的固定隐藏值，金融行业常用动态令牌机制：

  1. 前端加载页面/发起操作时，向服务端请求绑定当前会话的一次性requestToken；
  2. API请求必须携带该令牌，服务端校验令牌是否属于当前会话、是否未被使用；
  3. 令牌使用后立即失效，无法重复利用。

• 官方APP完整性校验
  对官方移动APP，金融机构会加入：

  • APP签名哈希校验，确保请求来自未被篡改的官方版本；
  • 反调试逻辑，防止恶意开发者通过调试工具窃取密钥或参数；
  • 定期更新校验逻辑，避免被逆向破解。

关键提醒 #

• 永远不要信任任何客户端传来的信息，所有核心校验必须在服务端完成；
• 单一措施易被绕过，必须组合使用多种手段（如签名+设备指纹+行为风控）；
• 定期开展模拟攻击测试，验证控制措施的有效性。

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