通常我們在h5前端調用後臺接口時，一般是ajax，那麼接口的安全成了一個問題。
這裏可以肯定的說，前端調用的接口一定要驗證！
然後剖析了微信網頁版、京東網頁版這些，也都是通過接口的形勢綁定數據，所以在進行前端開發時，除了直接後臺模板綁定，比如dotnet的MVC，java的springMVC這些。
前端和後端採用接口訪問時的調用驗證機制（基於JWT的前後端驗證）
JWT主要實現的Token機制，爲每一個需要調用的接口生成驗證的Token，然後後端進行驗證合法性。
JWT是一個標準，那麼實現這個標準的語言就非常多，比如C，C++，Java等，具體的參考官方提供的文檔即可。
生成原理：比如我們請求一個接口時，會使用JWT生成的Token，一同傳遞到後端進行驗證合法性，對於生成Token可以是頁面載入的時候寫到Cookie，或者寫到頁面的固定位置。
可能遇到的問題和解決方案：
1、如果基於Java Web系統，前後端沒有做分離時，基本頁面輸出使用了Java Web的模板引擎的，可以爲輸出的頁面帶上生成Token字符串，然後這些Ajax請求全部帶上這個Token。
1.1、可能會出現這個Token暴露在頁面，然後用工具提取到，然後進行請求；對於這個問題可以這樣做，Token本身有過期機制，比如2個小時過期，這樣一般能杜絕絕對部分的請求。
1.2、再加強一下，比如請求的接口上做一個驗證，比如獲取請求時判斷上一個請求的頭上Referer值，看下是否爲當前域名下的。
1.2、比如生成Token時，帶上請求的參數進行生成再輸出，這樣也就一個Token只能做一個參數的請求，也能杜絕掉一大部分的僞造請求。
1.3、對於生成Token，可以是單獨的接口，但這樣有點危險，可能會讓人提取去用，但是如果判斷只能當前域名下使用可能會有效。
1.4、也可以這樣生成這個Token，比如我們要訪問的B頁面，那麼先請求A頁面再跳轉到B頁面，此時就會帶上Token在Cookie上，然後再請求。不過同樣也會被提取的風險。
1.5、學微信的做法，微信的前端JS做了Token的驗證，比如頁面上寫好AppID，然後Token是服務端生成好放入到頁面的，並且與域名進行綁定，如果域名變了，就無法使用這個Token請求。那麼我們還是回到Referer的判斷上進行判斷，是否是本域名發出的請求。
2、如果是別的系統進行調用時，比如前後端分離的方案，需要使用到Ajax進行請求第三方接口的。
2.1、沒辦法，這個Token只能有後端生成好給你，然後你再使用它進行請求，並且第三方接口上也會判斷Referer的來源域名。
2.2、還是使用上面的A和B頁面進行跳轉，然後獲取Token，當然這個A頁面可以是第三方去做，然後針對域名寫Cookie。
3、綜上，基本上是生成Token要過期時間，要判斷請求的來源域名。、
4、針對Ajax是沒有絕對安全的，只能做到比較安全；最明顯的例子就是微信Web端，網上同樣針對微信的Web API進行抓包分析，然後實現了請求的。既然加了Token機制只是爲了再複雜多一步，使刷包的人做多一步難的操作。