一、接口安全
問題1. 接口暴露使用者隐私資訊就相當于在光天化日下裸奔，被看光了
描述：程式猿在做業務接口的時候往往沒有保護使用者隐私的意識，把使用者的隐私資訊暴露在外面，一旦被人利用起來會給使用者帶來麻煩，同時被發現會降低平台的信任度；
防：
- 使用者隐私資料加密，加*号，如使用者的相關資料的JSON中有使用者手機号，使用者郵箱，支付賬号，郵寄位址等隐私資料；
- 使用者請求接口時需要對其隐私參數加密：如使用者登陸請求登陸接口，需要将使用者密碼進行可逆加密，以免接口被惡意代理捕捉請求後擷取明文密碼；
- 分享出去的位址中不要用明文的使用者ID，或者使用者登入的token
問題2. 接口暴露敏感資訊，就像把鑰匙插在鑰匙口沒拔掉一樣，隻要你會開門就能進去
使用者參與活動的資料JSON集合中不要有活動相關業務邏輯的決定性的資料,如：競拍出價活動，出價唯一最低者拿獎品，結果擷取出價的接口暴露了所有出價的價格統計結果。
防：
- 資料中需要将敏感字段,或者對業務有着決定性作用的字段中的部分字元串加*;
問題3.資料被人順手帶走(主業務接口相關JSON資料 如：首頁商品清單資料)
描述：接口中的JSON資料會被其他人拿去做自己的相關的功能；這樣就造成了伺服器的額外支出
防：
-
IP請求量限制，時間範圍内請求量限制，等各種限制IP請求的規則，
如：統計記錄(可以記錄到mongdb中)，定時監控記錄發現請求量大于限制的數量就進行IP封殺;
- 請求頭的校驗，如：User-Agent 校驗請求頭是不是APP客服端發起，Referer 是不是有來源，來源域名是不是自己的域名位址等(這種方式隻能是多一個門檻)；
問題4.移花接木，惡意修改請求資訊(修改參數，COOKIE，請求頭資訊)
描述：通過修改請求中的參數來發起的請求，如：登陸接口修改使用者名和使用者密碼，進行密碼庫碰撞等。
溫馨提示：
修改請求參數可能會導緻很多安全性問題，如：SQL注入，XSS 跨站腳本攻擊等，傳送門我的【大話程式猿眼裡的WEB安全】有相關的介紹和解決方案
以下方案都針對用戶端，如PC軟體和APP，WEB端JS去做加密的話不是很推薦，JS代碼是暴露出來的，是以如果用JS做加密一定要混淆JS代碼
防：
- 增加一個簽名參數，将參數名進行邏輯的排序組合拼接+秘鑰MD5，然後服務端接受到請求的時候也用同樣的邏輯得到簽名與簽名參數進行對比是否相同，這樣可以使參數無法被修改，修改了就提示非法請求。 如： 接口http://www.test.com/go/?actid=1&userid=123 我們可以加一個sign參數= MD5(actid=1&userid=123&【secret】)【secret】=秘鑰，自己定義。 服務端用一樣的邏輯得到密文和sign簽名進行對比是否一樣，不一樣就提示非法請求。
- 整個參數内容進行可逆的加密
- 限制參數範圍，如：支援分頁接口，很多人會為了友善使用，加了參數就是pagesize(一頁的資料量)，當沒有去限制頁碼最大值得時候，如果表資料量很大，然後攻擊者修改pagesize參數為N萬，然後資料庫就奔潰了,相關業務就挂了。
問題5.影分身術，模拟請求，發起并發請求
描述：通過抓包工具抓到請求後模拟請求，如：模拟每日簽到請求，或者直接發起每日簽到的并發請求。
溫馨提示：當請求并發後如何保證資料的完整性，一緻性問題，這也是平時開發很需要注意的問題，傳送門我的【大話程式員眼裡的高并發】有相關的介紹和解決方案。
防:
- 模拟并發請求，IP限制同上問題2的解決方案。
- 請求資訊帶上時間(可逆加密的時間)，服務端擷取時間，超過限定時間的傳回請求逾時(目的使抓取到的請求不是一直有效的)。
- 使用者token,等辨別使用者重要的資訊資料，儲存COOKIE需要設定過期時間，或者加密的明文裡要有建立的時間，服務端做對應的時間失效的限制，這樣即使COOKIE被别人盜取，模拟請求也會随着時間而失效;
總結
我們需要提高自己的安全意識，防範于未然，要多站在攻擊者的角度來看自己的接口;(讓自己有一種被害妄想症的感覺，你就離精神病近了一步，<(￣︶￣)↗ ) 不要做開發需求的機器人，我們是有思想有創造力的開發者;
二、接口設計
未完待續。。