前言
大家好呀，我是捡田螺的小男孩。
我们日常开发中，如何保证接口数据的安全性呢？个人觉得，接口数据安全的保证过程，主要体现在这几个方面：一个就是数据传输过程中的安全，还有就是数据到达服务端，如何识别数据，最后一点就是数据存储的安全性。今天跟大家聊聊保证接口数据安全的 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. 限流機制
如果用戶本來就是就是真實用戶，他惡意頻繁調用接口，想搞垮你的系統呢？這種情況就需要接入限流了。
常用的限流算法有令牌桶和漏桶算法。大家可以看下我的这篇文章，面试必备：4 种经典限流算法讲解
可以使用Guava的RateLimiter单机版限流，也可以使用Redis分布式限流，还可以使用阿里开源组件sentinel限流。比如说，一分钟可以接受多少次请求。
7. 黑名單機制
如果發現了真實用戶惡意請求,你可以搞個黑名單機制，把該用戶拉黑。一般情況，會有些競爭對手，或者不壞好意的用戶，想搞你的系統的。所以，為了保證安全，一般我們的業務系統，需要有個黑名單機制。對於黑名單發起的請求，直接返回錯誤碼好了。
8.白名單機制
有了黑名單機制，也可以搞個白名單機制啦。以前我負責的企業轉帳系統，如果有外面的商戶要接入我們的系統時，是需要提前申請網絡白名單的。那時候運維會申請個 ip 網絡白名單，只有白名單裡面的請求，才可以訪問我們的轉帳系統。
9.數據脫敏掩碼
對於密碼，或者手機號、身份證這些敏感信息，一般都需要脫敏掩碼再展示的，如果是密碼，還需要加密再保存到資料庫。
對於手機號、身份證信息這些，日常開發中，在日誌排查時，看到的都應該是掩碼的。目的就是儘量不泄漏這些用戶信息，雖然能看日誌的只是開發和運維，但是還是需要防一下，做掩碼處理。
对于密码保存到数据库，我们肯定不能直接明文保存。最简单的也需要MD5处理一下再保存，Spring Security中的 BCryptPasswordEncoder也可以，它的底层是采用SHA-256 +随机盐+密钥对密码进行加密，而SHA和MD系列是一样的，都是hash摘要类的算法。
10. 數據參數一些合法性校驗。
接口數據的安全性保證，還需要我們的系統，有個數據合法性校驗，簡單來說就是參數校驗，比如身份證長度，手機號長度，是否是數字等等。
總結
本文給大家居間了 10 種保證接口數據安全的方案。小夥伴們，如有還有其他方案的話，可以在留言區評論哈，一起交流學習。