很多公司會(huì)為了給用戶提供更好的使用體驗(yàn)，針對(duì)不同的前端平臺(tái)（pc站點(diǎn)谱邪、m站點(diǎn)炮捧、移動(dòng)應(yīng)用、甚至公眾號(hào)）開發(fā)業(yè)務(wù)邏輯基本相同惦银、但布局和交互效果有所區(qū)別的產(chǎn)品寓盗。而業(yè)務(wù)邏輯部分就會(huì)抽取為公用模塊為各個(gè)項(xiàng)目提供接口服務(wù)，也就是“內(nèi)部API”璧函。
內(nèi)部API也通常會(huì)采用HTTP的方式通信傀蚌，這也就難免會(huì)遇到數(shù)據(jù)安全問題。問題主要集中在傳輸過程中被監(jiān)聽蘸吓，請(qǐng)求地址/參數(shù)被掃描善炫，輸入/輸出數(shù)據(jù)被非法獲取等。
所以库继，需要針對(duì)性的制定安全策略箩艺，當(dāng)然也可以參考開放平臺(tái)的api設(shè)計(jì)來制定策略窜醉，比如公眾號(hào)開放平臺(tái)、微博開放平臺(tái)等艺谆，通常需要先申請(qǐng)一個(gè)appkey來標(biāo)識(shí)第三方的身份榨惰，每次傳輸時(shí)通過簽名來驗(yàn)證身份，對(duì)傳輸?shù)膮?shù)和返回?cái)?shù)據(jù)通過約定的加密算法和秘鑰appsecret進(jìn)行加解密等静汤，具體步驟如下：
- 為不同的平臺(tái)分配不同的key（比如pc端=from_pc琅催，android應(yīng)用=from_android等）
- 調(diào)用方生成簽名，服務(wù)方驗(yàn)簽
- 和API約定一致的簽名算法和秘鑰
- js加密時(shí)虫给，需要對(duì)加密函數(shù)進(jìn)行混淆加密處理
- andoroid/ios藤抡，需要做加固處理
- 傳輸參數(shù)/返回結(jié)果進(jìn)行加密
- 和API約定一致的加密算法和秘鑰
- 同樣js/andriod/ios等前端代碼，需要做混淆/加密/加固處理
- 使用https協(xié)議
采用上面方式后抹估，即使使用抓包工具缠黍，也不能輕易獲取明文或格式化數(shù)據(jù)了（當(dāng)然開放給網(wǎng)頁的接口，通過模擬瀏覽器訪問药蜻，還是可以抓取渲染后的網(wǎng)頁數(shù)據(jù)的）瓷式。
