API接口安全性设计

一套完整的能力范围，要涵盖哪些方面？

最近在做毕设嘛，这一块以前从来没有关注过，这不是大学阶段最后一个学生项目了嘛，使劲的折腾，不断的翻新。对，业务层接口经过我一天半的努力已经全部交付给客户端了，不过我改主意了，我要返厂重做，在不影响客户端联调的前提下。

我要加上这个新功能。

网上这类文章不少，但是我还要写，表示我现在知道这个东西了。

---

Part1 令牌

玩过爬虫的都知道，cookie是个什么东西。

一图胜千言：

签名

爬虫完多了就知道什么叫抓包了嘛。当然，网络攻击的中间人咱是没做过。

为了防止中间人攻击（客户端发来的请求被第三方拦截篡改），引入参数的签名机制。

防抖节流

我不当中间人好多年，我拿着一些正当账号，DOS我玩不够，我分布式DOS。你怎么办呢？

首先客户端需要做防抖，这不能让我服务端来做。

降级的时候也需要客户端来做第一道防线，最好是最后一道防线。

怎么办呢？时间戳。

---

以上三个总结一下：

客户端处再做个防抖。

---

再高逼格一点

三层token ：

1 临时token（有效期短）   
2  长期token（有效期长） ，一般在登录的时候获取，临时token失效后，通过长期token获取。
3  用户token（做混淆，可选）

备注：不限于三层token，根据业务，安全性和效率做出平衡。

备注：http升级为https，也可以作为提升安全性的手段，移动端一定要做代码混淆，防止加密算法泄漏，web端利用cookie，session等内存操作来保证安全（内存操作相对是安全的，黑客无法获取用户的内存信息），最后请记住，没有绝对的安全，关键是你为你的应用安全提高多少门槛。