前言
服务端提供对外开放到公网API接口，危险非常大.尤其对移动应用开放接口的时候，更需要关注接口安全性的问题，要确保应用APP与API之间的安全通信，防止数据被恶意篡改等攻击。写这篇文章的初衷也是为了收集更多的方案，国内APP多大裸奔是时候关注接口安全和加强接口的安全了。
故事
以前公司因员工离职后与公司还存在的一些矛盾，导致接口被攻击了大量数据被污染。因为发现得及时和数据库做了备份，最后的方案也只能丢弃一天多的数据直接回滚到前一天的数据库备份!这种事情就不多评论了！公司有很大的问题，员工通过这种违法的手段来报复也是不可取的！！！
基础的方法
1. 请求合法性校验
- 考虑采用token，sign签名，app_key授权等方式保证接口不被其他人访问。
2. 数据校验
- 客户端提交的数据都由服务器验证数据格式、数据完整性、防止SQL注入
3. 数据加密
- 客户端提交敏感数据都进行加密。
4. 统一错误
- 服务器返回的错误都统一化，避免堆栈信息泄露。
5. 限制调用频率
- 对接口访问次数和频率设置阈值，超出预定阈值进行拒绝访问。
客户端的一些方案
一、简单token机制
客户端在登陆成功后由服务器返回用户信息和一个Token字段，将户信息加密后放入SharedPreferences中，以后每次请求把token字段和用户id加密后放人Header中由服务器验证。
{"user_id":"1","user_name":"xxx", Token:"eyJhbGciOiJIUzI1NiIsI.eyJpc3MiOiJodHRwczotcGxlL.mFrs3Zo8eaSNcxiNfvRh9dqKP4F1cB"}
注：我们的简单token 分为3块 token + 盐 + 时间戳
客户端生成访问Token：
通过抓包能随时获取token，在一定时效内能随意访问！超时需要重新抓包！根本没什么作用，只能防止用户通过URL直接获取到数据。
二、Access Token + sign签名
每次客户端启动去访问服务器接口，服务器通过验证时效性和服务器对比进行获取和刷新access_token。
{"access_token":"ACCESS_TOKEN","expires_in":7200}
每次通过读取access_token 生成sign签名，放人Header中由服务器验证。
更加灵活的方案，可以由服务器动态的控制APP是否能访问服务器。通过抓包能随时获取sign，在一定时效内能随意访问！这个是HTTP硬伤，明文在怎么样都没办法避免抓包！下面主要是处理抓包
三 Cookie Auth 认证机制
上面提到了HTTP因为抓包无论什么怎么防范都并卵！服务器小哥哥告诉我们让我们用Cookie来管理用户登录状态和访问权限。
每次登录后服务器返回一个Cookie，Cookie缓存到本地下次访问带上Token
OkHttp3实现Cookies持续化管理
最后因为下面2点替换方案
1.不符合Restful 最佳实践。
2.用着麻烦
四 JWT（JSON WEB Token）
别问我为什么没用HTTPS，因为穷。。。
JWT：是JSON风格轻量级的授权和身份认证规范，可实现无状态、分布式的Web应用授权；
JWT通常由三部分组成: 头信息（header）, 消息体（payload）和签名（signature）。
不太适合多用户和用户切换
五 HTTPS + Access Token + sign签名
感谢IOS大爷强制使用HTTPS，让我们苦逼Android也能享受HTTPS了。
HTTPS：是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。（引用百度百科）
HTTPS防止抓包和自带SSL加密，业务中Access Token + sign签名机制已经在项目中使用了，那继续使用吧！
注：其实HTTPS在数据传输中已经很安全了，服务器加入一些数据校验和 限制调用频率即可！
六：设备的唯一标识符绑定
设备的唯一标识符绑定: 账号和手机的唯一标识符相绑定。
七：简化登录流程
- 通过短信直接登录
- 通过第三方登录oauth2.0
