原创

Spring Boot如何保障接口安全？

1. 数据加密

数据在传输过程中是很容易被抓包的，如果直接传输，数据可以被任何人获取，所以必须对数据加密。加密方式有对称加密和非对称加密：

对称加密：对称密钥在加密和解密的过程中使用的密钥是相同的，常见的对称加密算法有 DES、AES。优点是计算速度快，缺点是在数据传送前，发送方和接收方必须商定好密钥，并完好保存。如果一方的密钥被泄露，那么加密信息也就不安全了；
非对称加密：服务端会生成一对密钥，私钥存放在服务器端，公钥可以发布给任何人使用。与对称加密相比，这种方式更安全，但速度慢太多了。

现在主流的做法是使用 HTTPS 协议，在 HTTP 和 TCP 之间添加一层加密层 (SSL 层)，这一层负责数据的加密和解密。HTTPS 的实现方式结合了对称加密与非对称加密的优点，在安全和性能方面都比较突出。关于如何开启https，可以参考这篇https://jxausea.medium.com/spring-boot-integrated-https-quick-start-demo-0f5b1ae86286

2. 数据加签

数据加签就是由发送者产生一段无法伪造的数字串，来保证数据在传输过程中不被篡改。数据如果已经通过 HTTPS 加密了，其加密部分只是在外网，而加签可以防止内网中数据被篡改。数据签名使用较多的是 MD5 算法，将需要提交的数据通过某种方式组合，然后通过 MD5 生成一段加密字符串，这段加密字符串就是数据包的签名。而其中的用户密钥，客户端和服务端都保留一份，会更加安全。3. 时间戳机

3. 时间戳机制

数据经过如上的加密、加签处理后，就算被抓包也不能看到真实的数据。但是有的不法者不关心真实数据，而是直接拿到抓取的数据包进行恶意请求。这时可以使用时间戳机制，在每次请求中加入当前的时间，服务器端会拿到当前时间与消息中的时间相减，看看是否在一个固定的时间范围内，比如 5 分钟，这样恶意请求的数据包是无法更改时间的，所以 5 分钟后就视为非法请求了。

4. AppId 机制

大部分网站都需要用户名和密码才能登录，这其实也是一种安全机制。相应的对外接口也需要这么一种机制，使用接口的用户需要在后台开通 AppID，提供给用户相关的密钥。在调用的接口中需要提供 AppID+ 密钥，服务器端会进行相关的验证。生成唯一的 AppID 即可，根据实际情况看是否需要全局唯一，同时密钥使用字母、数字等特殊字符随机生成。

5. 限流机制

本来就是真实的用户，并且开通了 AppID，但出现了频繁调用接口的情况，这时需要给相关 AppID 限流处理，常用的限流算法包括：令牌桶限流、漏桶限流、计数器限流。令牌桶算法的原理是系统以一定速率向桶中放入令牌，填满了就丢弃令牌。请求来时会先从桶中取出令牌，如果能取到令牌，则可以继续完成请求，否则等待或者拒绝服务。令牌桶允许一定程度突发流量，只要有令牌就可以处理，支持一次拿多个令牌。漏桶算法的原理是按照固定常量速率流出请求，流入请求速率任意，当请求数超过桶的容量时，新的请求等待或者拒绝服务，漏桶算法可以强制限制数据的传输速度。计数器算法比较简单粗暴，主要用来限制总并发数，比如数据库连接池、线程池、秒杀的并发数。计数器限流只要一定时间内的总请求数超过设定的阀值，就会进行限流。

6. 黑名单机制

如果一个 AppID 进行过很多非法操作，或者专门有一个中黑系统，经过分析之后可以直接将此 AppID 列入黑名单，所有请求直接返回错误码。如何查看黑名单列表呢？可以给用户设置一个状态比如：初始化状态、正常状态、中黑状态、关闭状态等等。或者直接通过分布式配置中心，保存黑名单列表，每次检查用户是否在列表中即可

7. 数据合法性校验

这是每个系统都会有的处理机制，只有在数据合法的情况下才会进行数据处理。每个系统都有自己的验证规则，当然也可能有一些常规性的规则，比如身份证号码长度和组成、电话号码长度和组成等等。合法性校验包括常规性校验以及业务校验，前者包括签名校验、必填校验、长度校验、类型校验、格式校验等，后者根据实际业务而定，比如订单金额不能小于 0 等等。

正文到此结束