Python 實時聊天室搭建：發布訂閱頻道API實戰應用
你可能也喜歡這些API文章!
為了提高人們對最嚴重的API安全威脅的認識，開放全球應用程序安全項目 (OWASP) 調查并發布了最嚴重的 API 安全風險列表。您應該查看OWASP 十大 API 安全風險，以掌握最嚴重的威脅并相應地保護您的 API。
影響 API 的安全問題不止于此，因為這不是一份詳盡的清單。
盡管如此，為了方便起見，這里還是列出了 OWASP 2023 年十大 API 安全風險：
OWASP 2023 年十大 API 安全風險
| 風險 | 描述 |
|---|---|
| 1：2023 對象級授權損壞 | API 往往會暴露處理對象標識符的端點，從而創建對象級訪問控制問題的廣泛攻擊面。每個使用用戶 ID 訪問數據源的函數都應考慮授權檢查。 |
| 2：2023 身份驗證失敗 | 身份驗證機制通常實施不當，導致攻擊者能夠竊取身份驗證令牌或利用實施缺陷暫時或永久地冒充其他用戶的身份。系統識別客戶端/用戶的能力一旦受損，整個 API 安全就會受到損害。 |
| 3:2023 損壞的對象屬性級別授權 | 此類別結合了 API3:2019 過度數據泄露和 API6:2019 – 批量分配，重點關注根本原因：對象屬性級別的授權驗證不足或不當。這導致信息泄露或被未經授權的各方操縱。 |
| 4:2023 不受限制的資源消耗 | 滿足 API 請求需要網絡帶寬、CPU、內存和存儲等資源。其他資源（如電子郵件/短信/電話或生物識別驗證）由服務提供商通過 API 集成提供，并按請求付費。成功的攻擊可能導致拒絕服務或運營成本增加。 |
| 5:2023 功能級別授權損壞 | 具有不同層次、群組和角色的復雜訪問控制策略以及管理功能和常規功能之間的不明確劃分往往會導致授權漏洞。通過利用這些問題，攻擊者可以訪問其他用戶的資源和/或管理功能。 |
| 6:2023 不受限制地訪問敏感業務流 | 易受此風險影響的 API 會暴露業務流程（例如購買門票或發表評論），但無法彌補過度自動化使用功能可能對業務造成的損害。這不一定是實施錯誤造成的。 |
| 7：2023 服務器端請求偽造 | 當 API 在未驗證用戶提供的 URI 的情況下獲取遠程資源時，可能會發生服務器端請求偽造 (SSRF) 漏洞。即使受到防火墻或 VPN 的保護，攻擊者也可以強迫應用程序將精心設計的請求發送到意外目的地。 |
| 8:2023 安全配置錯誤 | API 及其支持系統通常包含復雜的配置，旨在使 API 更加可定制。軟件和 DevOps 工程師可能會忽略這些配置，或者不遵循有關配置的安全最佳實踐，從而為不同類型的攻擊打開大門。 |
| 9:2023 庫存管理不當 | API 往往比傳統的 Web 應用程序暴露更多的端點，因此正確且更新的文檔非常重要。主機和已部署 API 版本的正確清單對于緩解諸如棄用的 API 版本和暴露的調試端點等問題也很重要。 |
| 10:2023 API 的不安全使用 | 開發人員往往更信任從第三方 API 收到的數據，而不是用戶輸入，因此傾向于采用較弱的安全標準。為了入侵 API，攻擊者會攻擊集成的第三方服務，而不是直接入侵目標 API。 |
本節重點介紹 API安全的最基本原則，您應將其視為為設計和實施 API 建立安全基礎的基石。
授權和訪問控制決定用戶或系統可以訪問哪些操作或資源：
令牌是實現授權的常用方法，在需要身份驗證的設置過程中獲取。它們將攜帶有關授權策略的信息，并在授予用戶或系統訪問權限之前由 API 進行驗證。
最常見的令牌類型是：
JWT 提供了一種安全傳輸信息的多功能方式，在復雜的環境中特別有用。
根據您的 API 所需的安全措施實施一種或多種機制的組合。
通過加密數據，防止攻擊者讀取客戶端和 API 之間交換的數據（傳輸中的數據）和存儲的數據（靜態數據）。
選擇強大的加密算法、確保密鑰安全以及使用經過驗證的加密庫是全面數據保護策略的關鍵方面。無論是信用卡詳細信息、用戶憑據還是敏感的業務信息，傳輸和靜態加密的應用都可以確保您的 API 以機密性和彈性處理關鍵數據，以抵御潛在攻擊。
保護 API 不僅限于授權、訪問控制和加密。另一個需要考慮的重要方面是輸入驗證，以防止通過將惡意代碼注入應用程序來利用漏洞進行注入攻擊。
例如，如果未充分驗證 API 請求中的輸入（例如查詢參數），則可能成為注入攻擊的潛在入口點。通過驗證輸入數據，您可以確保其符合預期的格式和標準，從而防范注入漏洞（例如 SQL 注入）。
定義并實施嚴格的輸入驗證策略，并確保您選擇高度安全且完善的庫。
本節概述了 API 安全的最佳實踐列表，其中包含一些原則和可操作的策略，可增強 API 抵御安全威脅的彈性和可靠性。
前三項最佳實踐證實并強調了我們在討論 API 安全基礎時提到的安全基礎的重要性。但是，您還必須研究其他最佳實踐并考慮應用它們，因為它們將全面提高您的 API 安全性。
根據預定義的角色或屬性實施精細控制并限制對 API 資源的訪問。這可確保用戶或系統僅具有必要的權限。
遵守最小特權原則，確保僅向用戶或系統授予執行特定任務或功能所需的最低訪問權限。這樣，您可以顯著降低未經授權的訪問和數據泄露的風險。
使用 HTTPS 等加密協議來保護傳輸中的數據并實施加密。在與 API 和應用程序的所有通信中使用 TLS（傳輸層安全性）。TLS 可確保傳輸過程中數據的機密性（無法讀取）、完整性（無法更改）和身份驗證（我們期望的來源）。
對于靜態數據，請選擇成熟的加密算法和工具來加密磁盤和數據庫。還請考慮對特別敏感的數據進行標記化，這會將數據替換為對攻擊者毫無意義的標記，只有授權方才能將這些標記映射回原始數據。
仔細檢查并過濾請求中提供的數據，以防止注入漏洞。實施徹底的輸入驗證，以確保數據符合預期的格式和標準。
實施機制來控制 API 請求的頻率和數量。速率限制（也稱為節流）有助于降低濫用和拒絕服務攻擊的風險。這可以通過應用程序來實現，需要花費大量的實施時間。不過，它可能會讓您對特定情況進行精細控制，甚至將速率限制與應用程序概念或邏輯聯系起來。
或者，您可以使用 API 網關/防火墻，這通常更簡單，并提供更完整的解決方案，以最小的努力保護整個 API（參見最后的最佳實踐）。
建立系統化的日志記錄實踐并實施監控工具，以檢測和應對異常活動或潛在的安全事件。定期檢查日志并針對可疑行為設置警報。確保您的日志始終能夠回答以下問題：誰？何時？什么？
定期進行安全審計，包括在開發生命周期內進行滲透測試和代碼審查，以識別和解決潛在漏洞。積極主動地應對新出現的威脅和不斷發展的安全標準。
實施版本控制，以便在對 API 進行更改時實現平穩過渡。建立明確的生命周期管理實踐，以淘汰棄用的版本并保持兼容性。
與其他 API 集成會增加對第三方提供商的依賴，以及確保系統安全的復雜性和挑戰。從這個意義上講，在與第三方 API 集成之前充分評估其安全風險并規劃實施階段所需的緩解措施至關重要。
僅共享必要信息的原則規定，API 在執行特定交易或交互時應披露最少的信息。這一原則對于減少敏感數據的暴露和限制潛在的攻擊媒介至關重要。這一原則也稱為最少披露原則。
最后但并非最不重要的一點是，考慮將 API 網關作為管理和保護 API 生態系統的中心點，并強化上面描述的一些最佳實踐。
API 網關提供多種功能：
API 安全測試是應對不斷演變的威脅的基礎。如果定期系統地進行測試，您肯定會提高 API 抵御潛在威脅的穩健性。
在API安全方面，可以采用各種測試方法來發現漏洞并確保更全面地識別 API 中的漏洞。
以下是一些需要考慮的測試類型的列表：
選擇正確的工具和框架會顯著影響 API 安全測試的有效性。以下是一些必備工具和框架的列表：
根據您的安全測試目標、被測試 API 的性質以及測試團隊的專業知識選擇正確的工具和框架。
如果沒有適當的 API 安全性，敏感數據和功能的網關將完全被解鎖，任何人都可以輕易進入，有時甚至沒有人注意到，直到為時已晚。
API 安全不應被視為奢侈品，而應被視為必需品。由于 API 已成為我們日益互聯的數字環境中現代應用程序和服務不可或缺的一部分，因此需要采取保護措施來保護它們免受數字世界中眾多威脅和惡意行為者的侵害。
我們希望本指南能為您提供一個很好的介紹，讓您知道您應該擔心什么，以及如何開始關注這些網關的安全性。即使您認為自己受到了保護，那些惡意行為者的技巧和狡猾程度也不容小覷，而且隨著時間的推移，他們的技術水平將越來越高。
文章來源：A Comprehensive Intro Guide to API Security
