内容摘要：前言大家好呀，我是捡田螺的小男孩。我们日常开发中，如何保证接口数据的安全性呢？个人觉得，接口数据安全的保证过程，主要体现在这几个方面：一个就是数据传输过程中的安全，还有就是数据到达服务端，如何识别数据

前言

大家好呀，保证我是接口捡田螺的小男孩 。

我们日常开发中，数据如何保证接口数据的安全安全性呢
？个人觉得，接口数据安全的保证保证过程，主要体现在这几个方面：一个就是接口数据传输过程中的安全 ，还有就是数据数据到达服务端
 ，如何识别数据，安全最后一点就是保证数据存储的源码下载安全性。今天跟大家聊聊保证接口数据安全的接口10个方案。

1.数据加密，数据防止报文明文传输
。安全

我们都知道，保证数据在网络传输过程中，接口很容易被抓包 。数据如果使用的是http协议
，因为它是明文传输的
，用户的数据就很容易被别人获取 
。源码库所以需要对数据加密 。

1.1 数据如何加密呢？

常见的实现方式 ，就是对关键字段加密  。比如，你一个登录的接口 ，你可以对密码加密
。一般用什么加密算法呢？简单点可以使用对称加密算法（如AES）来加解密，或者哈希算法处理（如MD5）
。

什么是对称加密：加密和解密使用相同密钥的加密算法 。

非对称加密：非对称加密算法需要两个密钥（公开密钥和私有密钥）。公钥与私钥是模板下载成对存在的，如果用公钥对数据进行加密
，只有对应的私钥才能解密。

更安全的做法，就是用非对称加密算法（如RSA或者SM2） ，公钥加密 ，私钥解密 。

如果你想对所有字段都加密的话，一般都推荐使用https协议。https其实就是在http和tcp之间添加一层加密层SSL
。亿华云

1.2 小伙伴们，是否还记得https的原理呢 ？

面试也经常问的，如下 ：

客户端发起Https请求
，连接到服务器的443端口
。

服务器必须要有一套数字证书（证书内容有公钥、证书颁发机构、失效日期等） 。

服务器将自己的数字证书发送给客户端（公钥在证书里面，私钥由服务器持有） 。

客户端收到数字证书之后，会验证证书的服务器租用合法性。如果证书验证通过，就会生成一个随机的对称密钥，用证书的公钥加密 。

客户端将公钥加密后的密钥发送到服务器。

服务器接收到客户端发来的密文密钥之后，用自己之前保留的私钥对其进行非对称解密，解密之后就得到客户端的密钥 ，然后用客户端密钥对返回数据进行对称加密，酱紫传输的香港云服务器数据都是密文啦 。

服务器将加密后的密文返回到客户端
。

客户端收到后
，用自己的密钥对其进行对称解密，得到服务器返回的数据。

日常业务呢 ，数据传输加密这块的话，用https就可以啦 ，如果安全性要求较高的 ，比如登陆注册这些 ，需要传输密码的，密码就可以使用RSA等非对称加密算法 ，对密码加密
。如果你的业务，安全性要求很高 ，你可以模拟https这个流程
，对报文  ，再做一次加解密。

2. 数据加签验签

数据报文加签验签，是保证数据传输安全的常用手段 ，它可以保证数据在传输过程中不被篡改。以前我做的企业转账系统  ，就用了加签验签。

2.1 什么是加签验签呢？

数据加签：用Hash算法（如MD5 ，或者SHA-256）把原始请求参数生成报文摘要，然后用私钥对这个摘要进行加密
，就得到这个报文对应的数字签名sign（这个过程就是加签）。通常来说呢
，请求方会把数字签名和报文原文一并发送给接收方。

验签 ：接收方拿到原始报文和数字签名（sign）后
，用同一个Hash算法(比如都用MD5)从报文中生成摘要A。另外 ，用对方提供的公钥对数字签名进行解密，得到摘要B ，对比A和B是否相同 ，就可以得知报文有没有被篡改过。

其实加签 ，我的理解的话，就是把请求参数 ，按照一定规则  ，利用hash算法+加密算法生成一个唯一标签sign 。验签的话
，就是把请求参数按照相同的规则处理，再用相同的hash算法 ，和对应的密钥解密处理 ，以对比这个签名是否一致。

再举个例子 ，有些小伙伴是这么实现的
，将所有非空参数（包含一个包AccessKey，唯一的开发者标识）按照升序，然后再拼接个SecretKey（这个仅作本地加密使用 ，不参与网络传输 ，它只是用作签名里面的），得到一个stringSignTemp的值，最后用MD5运算，得到sign。

服务端收到报文后 ，会校验 ，只有拥有合法的身份AccessKey和签名Sign正确，才放行 。这样就解决了身份验证和参数篡改问题，如果请求参数被劫持 ，由于劫持者获取不到SecretKey（仅作本地加密使用 ，不参与网络传输） ，他就无法伪造合法的请求啦

2.2 有了https等加密数据，为什么还需要加签验签

有些小伙伴可能有疑问，加签验签主要是防止数据在传输过程中被篡改，那如果都用了https下协议加密数据了，为什么还会被篡改呢？为什么还需要加签验签呢？

数据在传输过程中被加密了，理论上  ，即使被抓包，数据也不会被篡改。但是https不是绝对安全的哦 。可以看下这个文章：可怕 ，原来 HTTPS 也没用。还有一个点：https加密的部分只是在外网
，然后有很多服务是内网相互跳转的
，加签也可以在这里保证不被中间人篡改 ，所以一般转账类安全性要求高的接口开发
，都需要加签验签

3.token授权认证机制

日常开发中，我们的网站或者APP，都是需要用户登录的。那么如果是非登录接口，是如何确保安全 ，如何确认用户身份的呢 ？可以使用token授权机制。

3.1 token的授权认证方案

token的授权认证方案：用户在客户端输入用户名和密码，点击登录后
，服务器会校验密码成功
，会给客户端返回一个唯一值token ，并将token以键值对的形式存放在缓存（一般是Redis）中。后续客户端对需要授权模块的所有操作都要带上这个token，服务器端接收到请求后 ，先进行token验证，如果token存在
，才表明是合法请求 。

token登录授权流程图如下 ：

用户输入用户名和密码 ，发起登录请求服务端校验密码，如果校验通过 ，生成一个全局唯一的token。将token​存储在redis​中 ，其中key是token，value是userId或者是用户信息，设置一个过期时间。把这个token返回给客户端用户发起其他业务请求时，需要带上这个token后台服务会统一拦截接口请求，进行token​有效性校验，并从中获取用户信息 ，供后续业务逻辑使用 。如果token不存在 ，说明请求无效。3.2 如何保证token的安全 ？token被劫持呢 ？

我们如何保证token的安全呢？

比如说，我如果拿到token ，是不是就可以调用服务器端的任何接口？可以从这几个方面出发考虑：

token设置合理的有效期使用https协议token可以再次加密如果访问的是敏感信息，单纯加token是不够的 ，通常会再配置白名单

说到token，有些小伙伴们可能会想起jwt，即（JSON Web Token），其实它也是token的一种。有兴趣的小伙伴可以去了解一下哈。

4. 时间戳timestamp超时机制

数据是很容易抓包的，假设我们用了https和加签，即使中间人抓到了数据报文 ，它也看不到真实数据 。但是有些不法者
，他根本不关心真实的数据，而是直接拿到抓取的数据包，进行恶意请求（比如DOS攻击），以搞垮你的系统。

我们可以引入时间戳超时机制  ，来保证接口安全
。就是：用户每次请求都带上当前时间的时间戳timestamp ，服务端接收到timestamp后，解密，验签通过后
 ，与服务器当前时间进行比对，如果时间差大于一定时间 (比如3分钟)，则认为该请求无效
。

5.timestamp+nonce方案防止重放攻击

时间戳超时机制也是有漏洞的，如果是在时间差内 ，黑客进行的重放攻击 ，那就不好使了 。可以使用timestamp+nonce方案
。

nonce指唯一的随机字符串 ，用来标识每个被签名的请求。我们可以将每次请求的nonce参数存储到一个“set集合”中，或者可以json格式存储到数据库或缓存中。每次处理HTTP请求时 ，首先判断该请求的nonce参数是否在该“集合”中，如果存在则认为是非法请求 。

然而对服务器来说，永久保存nonce的代价是非常大的。可以结合timestamp来优化。因为timstamp参数对于超过3min的请求，都认为非法请求，所以我们只需要存储3min的nonce参数的“集合”即可。

6. 限流机制

如果用户本来就是就是真实用户，他恶意频繁调用接口，想搞垮你的系统呢？这种情况就需要接入限流了 。

可以使用Guava的RateLimiter单机版限流，也可以使用Redis分布式限流，还可以使用阿里开源组件sentinel限流。比如说，一分钟可以接受多少次请求。

7. 黑名单机制

如果发现了真实用户恶意请求,你可以搞个黑名单机制，把该用户拉黑 。一般情况 ，会有些竞争对手，或者不坏好意的用户 ，想搞你的系统的
 。所以 ，为了保证安全，一般我们的业务系统 ，需要有个黑名单机制 。对于黑名单发起的请求 ，直接返回错误码好了。

8.白名单机制

有了黑名单机制 ，也可以搞个白名单机制啦。以前我负责的企业转账系统 ，如果有外面的商户要接入我们的系统时，是需要提前申请网络白名单的。那时候运维会申请个IP网络白名单
，只有白名单里面的请求 ，才可以访问我们的转账系统。

9.数据脱敏掩码

对于密码，或者手机号
、身份证这些敏感信息，一般都需要脱敏掩码再展示的，如果是密码 ，还需要加密再保存到数据库  。

对于手机号 、身份证信息这些，日常开发中，在日志排查时 ，看到的都应该是掩码的。目的就是尽量不泄漏这些用户信息，虽然能看日志的只是开发和运维，但是还是需要防一下 ，做掩码处理。

对于密码保存到数据库，我们肯定不能直接明文保存。最简单的也需要MD5处理一下再保存 ，Spring Security中的 BCryptPasswordEncoder也可以
，它的底层是采用SHA-256 +随机盐+密钥对密码进行加密，而SHA和MD系列是一样的，都是hash摘要类的算法。

10. 数据参数一些合法性校验
。

接口数据的安全性保证 ，还需要我们的系统 ，有个数据合法性校验，简单来说就是参数校验 ，比如身份证长度，手机号长度，是否是数字等等
。

总结

本文给大家介绍了10种保证接口数据安全的方案 。