如今各種API接口層出不窮，一個API的好與不好可以從很多方面來考量，其中“安全性”就是一個API接口最基本也是最重要的一個特點。本文就來跟大家聊聊關于API接口開發的安全性問題。

所謂接口服務器端直接根據user_id來做相應的會員操作，這是非常危險的接口處理，等于把當前的會員系統給完全暴露出來，只要對方改一下user_id就可操作所有會員對應的接口。

一般在PC端，我們是通過加密的cookie來做會員的辨識和維持會話的；但是cookie是屬于瀏覽器的本地存儲功能。APP端不能用，所以我們得通過token參數來辨識會員；而這個token該如何處理呢？

在做接口加密前，我們先來看以下幾個方案：

方案 1

與APP端開發人員約定特定的md5組合算法，然后兩端比對一下，如果相同就allow，不相同就deny；但是，這也是不安全的，如果APP程序被反編譯，這些約定的算法就會暴露，特別是在安卓APP中，有了算法，完全就可以模擬接口請求通過驗證。

方案2

會員登錄的時候請求登錄接口，然后服務器端返回給客戶端一個token，該token生成的規則是 網站公鑰 + 當前uid + 當前時間戳 + 一段隨機數雙重加密，根據需求決定是把該token放進cache等一段時間自動失效，還是放進數據庫（如果要放進數據庫的話，單獨拎出一張表來，順便記錄用戶的登錄，登出時間），在用戶登出登錄的時候改變一下，確保該token只能在用戶人為登出登錄之間有用。

為保安全，應保證讓用戶在一段時間內自動退出；此方案配合Linux和數據庫的權限管理可以防外又防內。

方案3

通過對稱加密算法，該加密算法對uid+網站公鑰進行時效加密，在一定時效內可用。在會員登錄成功時，服務器端對該ID加密后返回給客戶端，客戶端每次請求接口的時候帶上該參數，服務器端通過解密認證。

但是這樣做，也是不安全的。因為，防外不防內，聽說這次的攜程宕機就是因為內部離職人員的惡意操作。內部不懷好意的人員如果知道相應的算法規則后，就算沒有數據庫權限，也可以通過接口來操作相關會員。

方案4

數據庫會員表的password是帶上了隨機密竄并經過雙重加密的md5值;在用戶登錄的時候,我返回會員相應的uid和password,password雖然是明文的,別人知道也不能登錄,畢竟是經過加密的,然后每次請求接口的時候，通過主鍵uid可以很快的找到當前uid對應的token,然后再來比對。

但是這樣想法是too yang too simple的,抓包的人雖然不能通過密文密碼來登錄該會員,然而一旦知道了這個token,除非用戶更改密碼,否則也可以一直通過這個token來操作該會員的相關接口。

除了以上這些，數據格式最好使用JSON格式數據，因為JSON有較好的跨平臺性。在生成JSON的時候，要注意json的兩種格式：對象（字典）與 數組；mobile端開發語言中沒有類似PHP中的foreach不能遍歷對象，只能遍歷數組，他們對對象的操作一般都是通過鍵名去取鍵值。不管是成功，還是失敗。接口必須提供明確的數據狀態信息，并且不能返回NULL，如果返回NULL的話，在IOS端會崩掉。

關于API接口安全性問題的解決方案還有很多，需要在實際的實踐上多多思考總結，這樣才能讓開發出來的API更加強大。

總結

以上是生活随笔為你收集整理的api接口加密_谈谈API接口开发中的安全性如何解决的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。