目前的情況下api被很多地方應用，隨之而來的是api的安全性問題。
我所認識到的安全性問題有以下幾個方面：
1、ddos(拒絕服務攻擊)，介面被惡意呼叫，使真實的使用者無法享受到正常暢通的服務。
這個比較單純，也比較容易處理，通過ip限制來做，並且輔以一些硬體裝置應該就沒問題了，同時伺服器**商也可以提供相應的服務。
2、傳輸過程中資料被截獲，http資料報是可以被截獲到的，這一點我們無法防止，能做的只有使被截獲到的資料對截獲者來說無意義。
這個問題要分成兩種情況來說明，第一種情況，api站點採用了https，那麼在網路中傳輸的資料就是被加密過的資料，這種資料截獲者很難把他解密出來，所以可以保證資料的安全性。第二情況，api站點沒有採用https，而是使用的普通的http，如果不加任何處理其實傳輸的資料是在裸奔，當然有些資料就是給截獲者截獲到也沒有什麼影響，但對於敏感的資訊我們還是要想辦法來處理下的，要麼協商一種相同的加密方法，這樣起到加密作用。另外請求時使用token不直接傳以明文密碼暴露的機會，同時最好是在傳輸前就把資訊md5一下，這樣對使用者的在**上的安全性是有好處的。總的來說不使用https的傳輸是不安全的，有意義的敏感資訊有可能會被截獲到，建議在登入相關的介面有條件時一定使用https，如果使用http登入也一定要處理一下敏感資訊，比如這樣md5(變形(md5(原文)))，這樣即使被截獲也可以保證截獲人不能得到原文，也就保證了使用者在其他**上帳號的安全。
附：1、 傳輸中加上簽名sign不是為了防止被截獲，而是為了防止被篡改或發出偽造請求。
2、 數字簽名是對所傳輸資料的雜湊後的摘要使用私鑰加密得到的結果，
數字簽名使得接收方可以確認資訊是可靠的，因為只有指定私鑰加密的內容接收方才可以解密出來。
對於指定的md5結果，可以有方法找到多個文字與之對應。即單次單純的md5是不夠安全的，可以通過md5(變形(md5(原文)))來解決這個問題。
3、 數字證書是由權威機構用自己的私鑰加密服用提供方的公鑰並搭載其他相關資訊組成的。
4、 使用token是為了唯一標識使用者，應該在資料庫中維護這些資料，它應有的關聯屬性（使用者id、ip、到期時間、是否有效）
api安全性設計
介面的安全性主要圍繞token timestamp和sign三個機制展開設計，保證介面的資料不會被篡改和重複呼叫，下面具體來看 token授權機制 使用者使用使用者名稱密碼登入後伺服器給客戶端返回乙個token 通常是uuid 並將token userid以鍵值對的形式存放在快取伺服器中。服務端接收...
API介面安全性設計
介面的安全性主要圍繞token timestamp和sign三個機制展開設計，保證介面的資料不會被篡改和重複呼叫，下面具體來看 token授權機制 使用者使用使用者名稱密碼登入後伺服器給客戶端返回乙個token 通常是uuid 並將token userid以鍵值對的形式存放在快取伺服器中。服務端接收...
開放介面API安全性
開放介面時最基本需要考慮到介面不應該被別人隨意訪問，而我也不能隨意訪問到其他使用者的資料，從而保證使用者與使用者之間的資料隔離。這個時候我們就有必要引入token機制了。具體的做法 在使用者成功登入時，系統可以返回客戶端乙個token，後續客戶端呼叫服務端的介面，都需要帶上token，而服務端需要校...