通常情況下的api介面防護有如下幾種：
使用https防止抓包，使用https至少會給破解者在抓包的時候提高一些難度
介面引數的加解密，通過md5加密資料+時間戳+隨機字串(salt)，然後將md5加密的資料和時間戳、原資料均傳到後台，後台規定乙個有效時長，如果在該時長內，且解密後的資料與原資料一致，則認為是正常請求;也可以採用aes/des之類的加密演算法，還可以加入客戶端的本地資訊作為判斷依據
本地加密混淆，以上提到的加解密資料和演算法，不要直接放在本地**，因為很容易被反編譯和破解，建議放到獨立模組中去，並且函式名稱越混淆越難讀越安全。
user-agent 和 referer 限制
api防護的登入驗證，包括裝置驗證和使用者驗證，可以通過檢查session等方式來判斷使用者是否登入
api的訪問次數限制，限制其每分鐘的api呼叫次數，可以通過session或者ip來做限制
定期監測，檢查日誌，偵查異常的介面訪問
在開發web端程式時，如果你的服務是放在外網的，你是無法完全阻止別人模擬客戶端來呼叫你的web api的。因為你的所有前端**使用者都能直接或間接的看到。
而在開發小程式專案時，前端的小程式**是上傳到微信伺服器的，其他人想要直接看到或拿到源**的難度較大，因此小程式端相對安全些;
為什麼要做介面防護和許可權校驗
有時候，黑客通過抓包或者其他方式即可獲得到後台介面資訊，如果不做許可權校驗，黑客就可以隨意呼叫後台介面，進行資料的篡改和伺服器的攻擊。因此，為了防止惡意呼叫，後台介面的防護和許可權校驗非常重要。
小程式如何進行介面防護
要進行小程式的介面防護，首先需要了解小程式的登入過程，如下圖所示
整個的流程如下：
小程式端通過wx.login()獲取到code後傳送給後台伺服器
後台伺服器使用小程式的appid、appsecret和code，呼叫微信介面服務換取session_key和openid(openid可以理解為是每個使用者在該小程式的唯一識別號)
後台伺服器自定義生成乙個3rd_session，用作openid和session_key的key值，後者作為value值，儲存乙份在後台伺服器或者redis或者mysql，同時向小程式端傳遞3rd_session
小程式端收到3rd_session後將其儲存到本地快取，如wx.setstoragesync(key,data)
後續小程式端傳送請求至後台伺服器時均攜帶3rd_session，可將其放在header頭部或者body裡
後台伺服器以3rd_session為key，在保證3rd_session未過期的情況下讀取出value值(即openid和session_key的組合值)，通過openid判斷是哪個使用者傳送的請求，再和傳送過來的body值做對比(如有)，無誤後呼叫後台邏輯處理
返回業務資料至小程式端
ps：會話金鑰session_key 是對使用者資料進行加密簽名的金鑰。為了應用自身的資料安全，開發者伺服器不應該把會話金鑰下發到小程式，也不應該對外提供這個金鑰。
session_key主要用於wx.getuserinfo介面資料的加解密，如下圖所示
什麼是sessionid
在微信小程式開發中，由wx.request()發起的每次請求對於服務端來說都是不同的一次會話。啥意思呢就是說區別於瀏覽器，小程式每一次請求都相當於用不同的瀏覽器發的。即不同的請求之間的sessionid不一樣(實際上小程式cookie沒有攜帶sessionid)。
如下圖所示：
實際上小程式的每次wx.request()請求中沒有包含cookie資訊，即沒有sessionid資訊。
那麼我們能否實現類似瀏覽器訪問，可以將session儲存到後台伺服器呢
答案是肯定的。我們可以在每次wx.request()中的header裡增加
##j**a的寫法，jsessionid只是tomcat的對sessionid的叫法，其實就是sessionid
header:
##thinkjs3.0的寫法
header:
效果如下圖所示：
在thinkjs3.0的後台**中，sessionid被儲存到了cookie裡，可以通過
constsession_id=this.cookie('thinkjs')提取到sessionid的值
具體thinkjs的實現**
首先建立sever端的**，如下圖所示(
cd到根目錄，執行：
thinkjsnewserver建立後台**
防止API被惡意呼叫
一 身份鑑定。這個可以使用oauth2.0規範，或者帶有不對稱金鑰加密的token，選擇jwt等形式,配合身份鑑定系統來保證。二 內容防篡改。可以使用數字簽名演算法來進行雜湊校驗，強制https通訊。最新的系統可以考慮http 2。三 ddos 攻擊。通過設定防火牆，控制api呼叫頻.率，例如協議的...
防止惡意呼叫API介面
1 驗證碼 最簡單有效的防護 採用點觸驗證，滑動驗證或第三方驗證碼服務，普通驗證碼很容易被破解 2 頻率，限制同裝置，同ip等傳送次數，單點時間範圍可請求時長 3 歸屬地，檢測ip所在地是否與手機號歸屬地匹配 ip所在地是否是為常在地 4 可疑使用者，對於可疑使用者要求其主動發簡訊 或其他主動行為 ...
如何防止公開介面被惡意呼叫？
今年組長給了幾個任務，其中有兩個是關於對外介面的安全控制 前端驗證元件 利用瀏覽器js加密的技術訪問介面，防止惡意使用者越過瀏覽器直接訪問我們的介面。人機識別 在介面端再做一層檢測，區分呼叫者來自普通使用者還是工具模擬，進一步防止惡意打介面的行為。主要研究的方向在於如何提取使用者行為，因為工具模擬是...