PHP如何实现仅接受移动应用连接，拒绝API直接访问？

以下是几种实用的方案，可单独或组合使用来拦截非应用发起的API请求：

• 应用签名验证
  针对Android和iOS平台分别提取应用的合法签名信息（Android取SHA-1指纹，iOS取Bundle ID+开发者签名），将其预存在后端服务器。应用每次发起请求时，把签名信息加密后放在自定义Header（如X-App-Signature）中传递。后端收到请求后，解密并比对签名是否在合法列表内。
  注意：签名传输必须加密，同时要对应用内的签名获取逻辑做代码混淆，降低被逆向破解的概率。

• 动态请求签名
  约定一个仅应用和后端知晓的密钥，应用每次发起请求时，将请求URL、参数、当前时间戳拼接后，用HMAC或AES算法生成签名，连同时间戳一起放在Header（如X-Request-Sign、X-Timestamp）里。后端用相同的密钥和逻辑重新计算签名，比对一致性，同时校验时间戳（比如限制5分钟内有效）防止重放攻击。
  注意：密钥要在应用代码中做深度混淆，避免被逆向工具提取。

• User-Agent基础校验
  在应用的网络请求中设置专属的User-Agent标识（比如MyCustomApp/2.1.0 (iOS; 16.4; iPhone 14)），后端检查请求的User-Agent是否匹配预设的格式。
  缺点：User-Agent极易被伪造，只能作为第一道简易拦截，不能单独依赖。

• 设备指纹校验
  应用端收集设备的多个硬件/系统信息（如Android的Android ID、iOS的IDFA，再结合机型、系统版本等），生成唯一的设备指纹，请求时通过Header（如X-Device-Fingerprint）传递。后端记录合法用户的设备指纹，请求时进行校验。
  注意：设备标识可能因系统重置、用户隐私设置变更而失效，需做好兼容逻辑，且该方法仍有被伪造的可能，建议与其他方案结合。

• 借助第三方应用验证服务
  集成如Firebase App Check、AWS AppSync这类服务的SDK，它们会自动处理应用身份验证流程，后端只需校验服务返回的验证结果即可。这类服务能有效降低自研验证逻辑的安全风险，但会依赖第三方服务，可能产生额外成本。

总结 #

没有绝对能完全阻止逆向请求的方案（客户端逻辑始终存在被破解的可能），建议组合多种验证方式（比如应用签名+动态请求签名+User-Agent），同时对敏感接口搭配用户登录后的Token验证，大幅提升非授权访问的门槛。

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