API使應用程序能夠交換和使用數據和服務。由于能夠訪問組織的敏感數據，API成為惡意攻擊者和威脅參與者的一個有吸引力的目標。組織需要保護API以保護企業資源，以及使用API的其他應用程序和組織。

團隊應該執行API安全性測試，以確保API在負載下仍然可用。測試還需要確定API公開的數據和資源的機密性、完整性和可用性。API安全測試應該是全面和持續的，以便能夠及時處理發現的漏洞并修復，增強企業對網絡攻擊的彈性。

API 安全測試清單

以下實踐有助于確保API安全測試計劃足夠徹底，從而有效防范 API 安全風險。

1. 確定全面測試和維護API安全負責人

許多團隊都參與了 API 生命周期，隨著項目的進展，項目將經歷大量的快速變化和迭代。指定一個人來記錄所有API，確保完成所有測試并根據結果采取行動，這一點很重要。

隨著對云服務和Web應用程序環境的日益重視，與過去相比，更多的業務單位和其他應用程序所有者可能會參與到API安全治理中。這使得擁有一個中心聯絡點變得更加重要。

2. 為安全測試預算時間和資源

安全測試需要時間和金錢，因此組織在開始新項目時需要考慮這些因素。威脅建模突出了潛在的 API 風險和需要緩解的常見漏洞，但在項目上線后維護和更新 API 測試的預算也是必要的。

3. 分類和記錄每個 API 的用途及其應如何運作

記錄 API 及其使用。此信息有助于測試評估 API 是否可以處理可接受的操作和有效數據，以及不可接受的操作或無效數據。

4. 盡早運行測試，并盡可能自動執行測試

在開發生命周期早期發現安全問題可以節省時間和金錢，將安全檢測工具及開源組件分析工具集成到現有的工作流程和持續集成/持續交付管道中。理想情況下，在應用程序的每個版本上運行測試。許多 API 測試工具現在可以完全集成，以便按需進行持續或觸發測試。

5. 定義要運行的測試類型

對 API 安全評估進行以下測試：

無效的輸入。來自API的輸入應該像來自不受信任的源一樣處理，并相應地進行清理和驗證。模糊測試可以用來向API發送隨機數據，查看它是否可以處理意外數據而不會崩潰。

注入攻擊。使用這些測試攻擊來確保API拒絕那些試圖在不暴露任何敏感信息的情況下操縱后端數據庫或在服務器上執行操作系統命令的請求。

參數篡改。通過API請求發送的參數，比如購物車中商品的價格，很容易被攻擊者改變。參數篡改檢查API是否在處理參數之前驗證和檢測參數。

未處理的 HTTP 方法。使用所有 HTTP 方法發送請求，以確保服務器上不允許使用不必要的方法，例如 CONNECT、DELETE、PUT 和 TRACE。如果這些方法返回有效的響應而不是錯誤，則它們會帶來安全風險。如果應用程序確實需要這些方法之一，確保將其使用正確限制為受信任的用戶。

業務邏輯漏洞。API 的設計和實現中的缺陷可能使攻擊者能夠以開發人員從未想過的方式與 API 交互，從而引發意外行為，例如，在沒有完成預期購買工作流程的情況下完成交易。使用自動化工具測試此類漏洞通常很困難，因為漏洞通常是應用程序及其特定功能所獨有的。詳細說明事務和工作流的清晰設計和數據流文檔，包括在每個階段所做的假設，有助于防止引入此類漏洞。

身份驗證、訪問和加密控制。確保請求的發起者在服務器上經過身份驗證，并被授權訪問所請求的資源。實施身份和授權協議(如 OpenID Connect 和 OAuth 2.0)可能很困難，相關密鑰和令牌的管理也很困難。分配額外的時間來測試這些安全控制非常重要。

負載過大。速率限制控制(API 在一段時間內可以調用的次數)有助于阻止未經批準的連接并防范 DDoS 攻擊。確保設置這些限制以獲得更好的性能。

最后，錯誤消息、日志條目和故障轉移處理同樣也是測試的重要方面，因此在每次測試后查看消息和日志以檢查記錄的信息是否正確。

6. 修復失敗的測試并重新測試

將測試報告發送給指定人員，以確保修復警告和錯誤。重新測試以確保更新的代碼解決了問題。對于不滿足安全要求的任何第三方API，制定計劃與服務提供商協調，并根據需要重新測試。

7. 及時了解安全風險并更新文檔

參與構建 API 的每個人都需要了解網絡犯罪分子用來攻擊 API 的新技術，以便他們能夠更新代碼、安全控制和測試。安全團隊應定期向參與項目的每個人通報新威脅和實踐信息。

OWASP API 安全 10 大列表(包括防范以下漏洞)：

對象級授權損壞。

身份驗證損壞。

損壞的對象屬性級別授權。

不受限制的資源消耗。

函數級別授權損壞。

不受限制地訪問敏感的業務流程。

服務器端請求偽造。

安全配置錯誤。

庫存管理不當。

不安全地使用 API。