那我們要如何對接口請求進行一個安全校驗或者攔截非法請求吶？
1、選擇攔截過濾器。
在請求的時候對請求方法進行一次攔截處理。比如非正常訪問的方法已經注入插入可執行語句參數驗證等在攔截中進行一次安全校驗保證
請求不是非法請求。
2、數據加密。我們知道目前大部分APP接口都是通過Http協議進行調用的容易被抓包攔截。
我們可以對客戶端和服務端都對數據傳輸的時候進行一個加密處理。常用的MD5 AES等。
譬如：上一個項目做法比較簡單 對用戶與帳號密碼進行加密作為一個authcode。每次請求必須攜帶。這個方法與下邊說的方法3組合運用
客戶端：
1、設置一個key（和服務器端相同）
2、根據上述key對請求進行某種加密（加密必須是可逆的，以便服務器端解密）
3、發送請求給服務器
服務器端：
1、設置一個key
2、根據上述的key對請求進行解密（校驗成功就是「信任」的客戶端發來的數據，否則拒絕響應）
3、處理業務邏輯并產生結果
4、將結果反饋給客戶端
3、簽名
根據用戶名或者用戶id，結合用戶的ip或者設備號，生成一個token。在請求后臺，后臺獲取http的head中的token，校驗是否合法（和數據庫或者Redis中記錄的是否一致，在登錄或者初始化的時候，存入數據庫/redis）
在使用Base64方式的編碼后，Token字符串還是有20多位，有的時候還是嫌它長了。由于GUID本身就有128bit，在要求有良好的可讀性的前提下，很難進一步改進了。那我們如何產生更短的字符串呢？還有一種方式就是較少Token的長度，不用GUID，而采用一定長度的隨機數，例如64bit，再用Base64編碼表示：
var rnd = new Random();
var tokenData = userIp+userId;
rnd.NextBytes(tokenData);
var token = Convert.ToBase64String(tokenData).TrimEnd('=');
由于這里只用了64bit，此時得到的字符串為Onh0h95n7nw的形式，長度要短一半。這樣就方便攜帶多了。但是這種方式是沒有唯一性保證的。不過用來作為身份認證的方式還是可以的（如網盤的提取碼）。
4、使用第三方框架與技術整合支持比如spring的框架中的oauth模塊。
