如何保护Android应用后端服务器及API密钥免遭窃取？

核心原则：永远不在APK中存储敏感密钥 #

只要是硬编码在客户端代码里的密钥，不管怎么隐藏，都有被反编译提取的可能。所以最根本的解决思路是让客户端完全接触不到这些敏感密钥。

• 移除客户端硬编码密钥，通过后端中转请求
  直接删掉AppConfig里的SERVER_KEY和REST_API_KEY。所有需要用到这些密钥的第三方接口请求，都先发给你的后端服务，由后端携带密钥去调用第三方接口，再把结果返回给客户端。这样客户端全程碰不到敏感密钥，就算被反编译也拿不到有用的信息。

• 用短期令牌替代静态密钥
  放弃永久有效的静态密钥，改用OAuth2或JWT这类短期令牌机制。客户端通过合法的登录/授权流程获取有效期较短的令牌，用令牌发起请求。就算令牌被窃取，过段时间也会失效，危害可控。同时后端要校验令牌的签名和合法性，拒绝非法令牌的请求。

• 给APK做混淆和加固，提高逆向门槛
  虽然不能彻底阻止反编译，但能大幅增加攻击者的成本：

  • 开启Android Studio自带的R8混淆，混淆类名、方法名和变量名，让反编译后的代码变成一堆无意义的字符，难以读懂；
  • 使用第三方加固工具给APK加壳，进一步阻碍反编译工具的分析；
  • 别尝试把密钥加密后存在客户端——解密逻辑也在APK里，攻击者逆向解密流程照样能拿到密钥，这种方式意义不大。

• 后端加多层验证，拦截非法请求
  就算攻击者拿到了密钥，后端也要能识别并拒绝他们的请求：

  • 校验应用签名和包名：后端只允许你自己的应用（特定包名+签名）发起请求，每次请求时验证客户端的包名和签名信息，篡改过的应用通不过校验；
  • 要求请求签名：客户端发起请求时，要基于请求参数、时间戳生成唯一签名，后端重新计算签名比对，防止重放攻击和非法调用；
  • 限制请求频率：对异常高频的请求直接拦截，避免恶意批量调用消耗后端资源。

• 动态获取临时密钥（仅作辅助）
  不要把密钥写死在代码里，改成应用启动时从后端获取临时密钥，并且定期更新。但注意，这种方式只是增加了攻击者的工作量，必须配合后端的验证机制，否则获取密钥的接口也可能被逆向破解。

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