如今各種api介面層出不窮，乙個api的好與不好有很多方面可以考量，其中「安全性」是乙個api介面最基本也是最重要的乙個特點。尤其是對於充值繳費類的api介面來說，如話費充值api介面、流量充值api介面、遊戲q幣充值、水電煤繳費介面等，安全與否直接影響到個人或企業的財產，所以做好的api介面安全性問題尤為重要，98徵信資料查詢平台在這裡就來聊聊關於api介面的安全性。
所謂介面，伺服器端直接根據user_id來做相應的會員操作，這是非常危險的介面處理，等於把當前的會員系統給完全暴露出來，只要對方改一下user_id就可操作所有會員對應的介面。
在做介面加密前，我們先來看以下幾個方案：
方案一：
方案二：
會員登入的時候請求登入介面，然後伺服器端返回給客戶端乙個token，該token生成的規則是 **公鑰 + 當前uid + 當前時間戳 + 一段隨機數雙重加密，根據需求決定是把該token放進cache等一段時間自動失效，還是放進資料庫（如果要放進資料庫的話，單獨拎出一張表來，順便記錄使用者的登入，登出時間），在使用者登出登入的時候改變一下，確保該token只能在使用者人為登出登入之間有用。
為保安全，應保證讓使用者在一段時間內自動退出；此方案配合linux和資料庫的許可權管理可以防外又防內。
方案三通過對稱加密演算法，該加密演算法對uid+**公鑰進行時效加密，在一定時效內可用。在會員登入成功時，伺服器端對該id加密後返回給客戶端，客戶端每次請求介面的時候帶上該引數，伺服器端通過解密認證。
但是這樣做，也是不安全的。因為，防外不防內，聽說這次的攜程宕機就是因為內部離職人員的惡意操作。內部不懷好意的人員如果知道相應的演算法規則後，就算沒有資料庫許可權，也可以通過介面來操作相關會員。
方案四：
資料庫會員表的password是帶上了隨機密竄並經過雙重加密的md5值;在使用者登入的時候,我返回會員相應的uid和password,password雖然是明文的,別人知道也不能登入,畢竟是經過加密的,然後每次請求介面的時候，通過主鍵uid可以很快的找到當前uid對應的token,然後再來比對。
但是這樣想法是too yang too ******的,抓包的人雖然不能通過密文密碼來登入該會員,然而一旦知道了這個token,除非使用者更改密碼,否則也可以一直通過這個token來操作該會員的相關介面。
除了以上這些，資料格式最好使用json格式資料，因為json有較好的跨平台性。在生成json的時候，要注意json的兩種格式：物件（字典）與 陣列；mobile端開發語言中沒有類似php中的foreach不能遍歷物件，只能遍歷陣列，他們對物件的操作一般都是通過鍵名去取鍵值。不管是成功，還是失敗。介面必須提供明確的資料狀態資訊，並且不能返回null，如果返回null的話，在ios端會崩掉。
當然，我們了解到的有關資料 api 介面安全性問題的解決方案不止這些，一些開源專案以及博主介紹的落地方案都是值得大家學習和探索的，在實際的實踐中只有多多思考總結，這樣才能讓開發出來的api變得更加強大。
api介面加密
在介面開發中，為了客戶請求安全，常常要對其進行加密操作 加乙個訪問token。例如你的api位址是 需要接受的引數有a,b,c三個 那麼可以加乙個驗證token 通過約定的key加密生成 例如 a 1 b 2 c 3 key abcdef t ok en s ha1 token sha1 token...
API介面安全 加密
客戶端和服務端設定乙個公共金鑰 key www.imdupeng.cn 假設介面需要 a b c三個引數 例如你的api位址是 需要接受的引數有a,b,c三個，那麼可以加乙個驗證token。例如 token sha1 a.b.c.key 然後訪問使用 api.php接收到a,b,c,token引數後...
API介面加密方式說明
本文件適用於api介面開發人員 移動端開發人員，針對移動端請求api介面時加密方式以及加密規則進行說明。好處 相對於對稱加密，非對稱加密安全性遠遠高宇對稱加密，能夠保證在資料傳輸中資料被劫持之後不被破解。缺點 由於非對稱加密 openssl rsa加密演算法 aes 加密模式 cbc 填充方式 pk...