自1960年代結構化編程出現以來，API一直是軟件開發的重要因素。API是一組函數或例行程序，其目的是完成特定任務或提供一種簡單方法來與軟件組件交互，這通常允許對通用流程進行自動化以更好地與在其他機器運行的服務交互。

現在，保護API變得越來越重要。雖然API已經被使用了幾十年，而近年來Web 2.0和云計算的到來讓API的數量和使用都大幅增加，目前有超過14萬公共API。其中Facebook、谷歌、Twitter、eBay和Amazon提供的API可能是最著名的，還有很多其他企業也通過提供API來提供對其內部數據的訪問。例如，Salesforce公司的客戶可以使用其API來整合Salesforce服務到他們的系統，正如Facebook Platform API讓開發人員可以創建數千應用和服務來訪問Facebook數據一樣。

API帶來的商業機會幾乎是不可抗拒的，但API提供商和API消費者需要確保API部署的安全性，讓攻擊者無法使用它們來攻擊企業或其用戶。根據云安全聯盟表示，不安全的API是云計算面臨的最大的威脅之一。

API安全風險的性質

API提供了對應用功能的訪問權限，這意味著它們增加了攻擊面，并且，攻擊者會盡全力濫用或尋找流行API代碼中的漏洞，因為它們可以被用來攻擊大量應用和用戶。為了說明這一點，讓我們假設一個虛構的公司：MashOurDataInc公司，該公司提供API以允許開發人員從其數據中心提取數據。攻擊者已經成功地將惡意腳本注入到主要數據庫，如果MashOurDataInc公司的API代碼在響應API請求發送數據之前沒有清洗數據，那么，攻擊者的惡意腳本可能會發送到使用MashOurDataInc的API的任意應用，這意味著成千上萬的用戶將受到影響。

保護API來降低風險

如果開發人員在構建應用或服務時通過API使用第三方數據，那么，在代碼中使用這些API之前，開發人員必須完全明白它們的工作原理以及應該如何調用它們，以免制造潛在的漏洞。這就是說，開發人員需要閱讀所有相關的API文檔，其中應該包含保護API函數或例行程序的部分，例如如何調用API、需要怎樣的身份驗證、哪些數據將會返回以及以何種格式，可能出現哪些錯誤。

對正在使用的API構建威脅模型可以幫助企業了解攻擊面，并確定潛在的安全問題，從而在一開始就可以構建適當的安全緩解措施。Firebug和Chrome Developer Tools等調試工具可以幫助確定和檢查API生成的數據流，并突出應如何保護API。

如果應用接收第三方傳輸的數據，則不應該認為這些數據已經被清洗或正確驗證。開發人員必須構建數據清洗和驗證例行程序以防止標準注入漏洞和跨站請求偽造攻擊，特別是對于傳輸JSON和XML消息或用戶生成的內容的API，因為所有這些數據都來自不受信任來源。此外，在調用API之前，企業還需要驗證用戶或設備具有正確的權限來查看、編輯或刪除請求的數據;很多開發人員在用戶經過身份驗證后沒有進行二次訪問控制檢查。

企業開發API以允許他人來訪問其內部數據系統時，應該專注于構建和測試控件來管理對API的訪問權限。這些控制應該明確他人對不同類別的數據可以做什么以及不能做什么。此外，在允許查看、編輯或刪除數據前應該進行二次訪問控制檢查。

企業還應該記錄保護API的要求，這會讓企業更容易確保后續代碼更改仍然滿足針對個人或敏感信息的數據處理政策要求。同時，企業還需要記錄哪些信息應該進行日志記錄以捕捉誰、什么以及何時在訪問API，以滿足審計要求。企業應該分析這些日志記錄--最好通過安全信息和事件管理工具，從而檢測和阻止任何異常行為(例如暴力攻擊)。

API可以創造無數的機會來提高客戶服務和互動，并可幫助提高生產效率和利潤;它們甚至成為有些公司立足的產品或服務。然而，考慮到API帶來的潛在風險，企業應該將風險緩解作為任何API集成戰略的核心。