如今，API 已成為將當今 APP 經濟的粘合劑，在 Web 2.0 的浪潮到來之前，開放的 API 甚至源代碼主要體現在桌面應用上，越來越多的 Web 應用面向開發者開放了API，同時也正在成為黑客攻擊的頭號目標。
API 的運行方式與 URL 的運行方式大致相同，用戶使用 Web 搜索時，頁面展示結果是動態的，以手機銀行應用程序為例，API 也以類似的方式運行，它可以獲取用戶的地理位置、姓名、賬號和賬戶余額，并相應地填充交互頁面中的字段，但因為 API 包括所有安全檢查，并且通常直接與后端服務通信，所以也更容易被攻擊者青睞。
應用程序安全方面一直存在一個問題：輸入驗證。如果沒有適當的功能和安全測試，API 可能會成為一個完美的攻擊點。因為 API 受應用程序信任，可以進行高速、海量數據交換。
通過對大量應用程序安全市場客戶的調查，并參考開放 Web 應用程序安全項目 ( OWASP ) 后，調查人員匯總了以下三類最常見的 API 漏洞：
第一：資產管理不當
此 API 缺陷是環境隔離和管理不足的結果，允許攻擊者訪問安全性不足的 API 端點，在之前的網絡安全事件中，就有由于開發人員 API 無需編輯即可訪問生產數據，進而暴露了客戶的系統，屬于此類別的漏洞還包括未監控開發 API 中的敏感數據，以及讓已棄用的 API 仍處于在線或公開狀態。
第二：受損的對象級別授權 Broken Object Level Authorization ( BOLA )
BOLA 的通俗定義是對對象訪問請求的驗證不充分，它允許攻擊者通過重用訪問令牌來執行未經授權的操作。Peloton 事件是最近諸多 BOLA 利用中比較有名的一個案例，攻擊者可以查看包括標有私人事件在內的，幾乎所有用戶的個人資料。此類攻擊可能影響到從開發到運營，再到營銷和公共關系的每個業務組。
第三：無效的用戶身份驗證
此類漏洞的準確定義是 " 身份驗證機制中的實施缺陷 "，允許攻擊者冒充合法用戶。這里關聯兩種常見的漏洞利用類型：第一個是由自動化機器人執行的憑證填充。查找有用戶身份驗證缺陷的 API 是自動攻擊的理想目標。此漏洞的更復雜用途是進行偵察，以確定 API 的工作方式。例如我們輸入 "a@a.com /" 密碼的用戶名 / 密碼組合，應用程序顯示 " 密碼無效 "，那么攻擊者就會知道用戶名是有效的。攻擊者將使用此數據點來增加憑證填充（或其他類型的攻擊）成功的機會。
API 缺陷影響整個企業，而不僅僅是運維團隊、安全團隊或業務團隊，指指點點從來無法修復問題，修復始于協作，那么如何防止 api 接口被惡意調用或攻擊？
1. 圖形驗證碼：
將圖形校驗碼和手機驗證碼進行綁定，在用戶輸入手機號碼以后，需要輸入圖形校驗碼成功后才可以觸發短信驗證，這樣能比較有效的防止惡意攻擊。目前大部分應用都是采用這種方式。
2. 限定請求次數：
在服務器端限定同一IP 地址，同一設備，同時間范圍內的接口請求次數。比如同一號碼重復發送的時間間隔 , 一般為 60 或 120 秒；設置每個 IP 每天最大的發送量；設置單個手機號每天的最大發送量。
3. 流程條件限定：
將手機短信驗證放在最后進行，比如需要用戶必須注冊后，或者用不必須填寫了某些條件才能進行短信驗證。
4. 歸屬地是否一致：
服務器端檢查用戶的 IP 所在地與手機號歸屬地是否匹配，如果不匹配則提示用戶手動操作等。
5. 服務器接口驗證：
當用戶登錄成功后，返回一個由 Token 簽名生成的秘鑰信息 ( Token 可使用 base64 編碼和 md5 加密，可以放在請求的 Header 中 ) ，然后對每次后續請求進行 Token 的封裝生成，服務器端在驗證是否一致來判斷請求是否通過。
（1）常規的方法：用戶登陸后生成 token，返回客戶端，然后服務器使用 AOP 攔截 controller 方法，校驗 token 的有效性，每次 token 是一樣的；
（2）用戶登陸后生成臨時 token，存到服務器，并返回客戶端，客戶端下次請求時把此 token 傳到服務器，驗證 token 是否有效，有效就登陸成功，并生成新的 token 返回給客戶端，讓客戶端在下一次請求的時候再傳回進行判斷，如此重復。 這種方法有性能問題，但也有一個漏洞，如果用戶在一次請求后，還未進行下一次請求就已被黑客攔截到登錄信息并進行假冒登錄，他一樣可以登錄成功并使用戶強制下線，但這種方法已大大減少被假冒登錄的機會。
（3）兩層 token：一般第一次用賬號密碼登錄服務器會返回兩個 token，時效長短不一樣，短的時效過了之后，發送時效長的 token 重新獲取一個短時效，如果都過期，那么就需要重新登錄了。當然更復雜你還可以做三層 token，按照業務分不同 token。
6. 采用 https：
線上的 api 接口開啟 https 訪問 , 這樣做的話別人抓包的難度會提高很多，而且 https 需要秘鑰交換，可以在一定程度上鑒別是否為偽造的網絡非真人 IP 地址。
7. 服務器端代理請求：
針對于網站，這也是解決跨域的方案之一，采用服務器代理可以有效的防止接口真實地址的暴露。
