你的API还在裸奔？阿里大师带你领悟安全的代码正确姿势
看起来好像前后端分离是个浪潮，原来只有APP客户端会考虑这些，现在连Web都要考虑前后端分离 。这里面不得不谈的就是API的设计和安全性，这些个问题不解决好，将会给服务器安全和性能带来很大威胁 。下面我也是根据自己的一些经历和经验说下自己的一些心得 。
API的设计中，主要考虑两大方面的问题 ：
- 防止API被恶意调用
- API通信中数据加密的问题
接口的安全性主要围绕token、timestamp和sign三个机制展开设计，保证接口的数据不会被篡改和重复调用，下面具体来看：
Token授权机制：
用户使用用户名密码登录后服务器给客户端返回一个Token（通常是UUID），并将Token-UserId以键值对的形式存放在缓存服务器中。服务端接收到请求后进行Token验证，如果Token不存在，说明请求无效。Token是客户端访问服务端的凭证。
时间戳超时机制：
用户每次请求都带上当前时间的时间戳timestamp，服务端接收到timestamp后跟当前时间进行比对，如果时间差大于一定时间（比如5分钟），则认为该请求失效。时间戳超时机制是防御DOS攻击的有效手段。
签名机制：
将 Token 和 时间戳 加上其他请求参数再用MD5或SHA-1算法（可根据情况加点盐）加密，加密后的数据就是本次请求的签名sign，服务端接收到请求后以同样的算法得到签名，并跟当前的签名进行比对，如果不一样，说明参数被更改过，直接返回错误标识。签名机制保证了数据不会被篡改。
Api有哪些安全问题？—-http接口—前后端分离mvvm
- 数据被抓包窃取
- 数据被调包篡改
- 数据被爬取泄露
数据加密
- 对称加密：DES、AES
- 非对称加密：RSA
安全够了吗，还有哪些要做？
加密解决了数据上行的安全，然而黑客，直接抓密文来提交，怎么办？
接口签名
安全够了吗，还有哪些要做？
接口签名，仅仅依靠参数顺序的排列组合，安全强度不够
身份认证—–token令牌
Token授权机制：用户使用用户名密码登陆后，服务器给客户端返回一个Token，并在服务器中缓存此Token。后续服务器收到请求后进行Token验证，若Token不存在，则说明请求无效
身份认证的封装—–cookie隐式携带token
- 使用tokenFilter统一处理
- 登陆成功，服务器直接种token到cookie中
- 客户端请求时，需要送token值的加密串，到服务器
总结
安全是一个永恒的话题，随着各大网站全站https的推进，安全也越来越被重视。签名设计大家必须有，HTTPS希望大家有。