應用程序編程接口 (API) 無處不在，它們在我們以數字為中心的生活中幾乎扮演著一切的角色。每次我們在手機上啟動網頁或應用程序時，后臺都會進行數十次 API 調用，以提供高度定制的體驗。越來越多的人甚至家中的日常用品也在與 API 對話 – 從 Amazon Echo 等智能揚聲器到家用電器、電表和燈泡。
但隨著 API 的使用不斷增長，對 API 安全性的需求也隨之增長。
企業越來越依賴 API 來實現與合作伙伴、供應商和第三方應用程序的無縫集成，而 API 安全漏洞可能給組織帶來嚴重的財務和聲譽損失——一些API 安全研究顯示，每次攻擊的平均成本約為 610 萬美元。
API 現已成為惡意行為者（即網絡犯罪分子，而不是 Willem Dafoe）用來竊取數據、破壞運營、進行欺詐以及參與一系列其他對企業不利的險惡活動的主要載體。
隨著 API 成為現代應用程序開發的基礎，攻擊面（攻擊者可能通過其未經授權訪問網絡或系統以提取或輸入數據或執行其他惡意活動的所有入口點）正在不斷增加。解決方案是什么？API 安全。
API 安全是一套旨在保護組織 API 的最佳實踐。除了基礎設施安全參數外，公司還應在應用程序邏輯級別以編程方式保護 API。
應該制定適當的 API 權限和規則，以確保只有目標受眾才能使用正確類型的允許 API。
API 安全是任何現代數字企業的重要組成部分。通過采取正確的安全措施，企業可以確保其 API 安全，并確保其傳輸的敏感數據不會受到未經授權的訪問。
由于軟件行業廣泛依賴 API，因此提供 API 的組織有必要提高 API 的安全性和可信度。在 2023 年 API 峰會上，Ahmed Koshok 和 Tyler Reynolds（Kong 高級解決方案架構師兼 Traceable.ai 渠道和 GTM 總監）討論了 API 安全性及其最佳實踐日益增長的重要性。
“我們確實處于這個新興 API 安全領域的早期階段，”雷諾茲說?！暗珡奈磥?API 安全性的角度來看，它將成為現代應用程序的基礎?！?/p>
API 用于訪問敏感信息，包括個人身份信息 (PII)、財務數據和知識產權。目前，90% 的網絡流量都通過某種 API 傳輸，其中大部分流量都帶有敏感數據。任何未經授權的訪問或數據泄露都可能給組織帶來嚴重后果，包括法律責任、失去客戶信任和聲譽受損。此外，許多行業都受到有關敏感數據保護的監管要求的約束。
API 安全策略可以幫助組織遵守這些法規、避免受到處罰并維護其聲譽。
雷諾茲說：“我們不能不正面解決這個問題?！?/p>
識別和管理 API 安全風險是維護安全可靠的 API 基礎設施的關鍵方面。
以下是組織可以采取的一些步驟來最大限度地降低 API 安全風險。
Koshok 表示：“API 管理的兩個維度是了解 API 的存在以及對 API 治理的應用。理想情況下，所有 API 都應該被了解和管理。”
一旦組織對其 API 進行盤點，Kong 就會幫助其開發 360 API 安全管理框架，以了解這些 API、使用模式、依賴關系和應用程序流以及每個端點的風險級別。
組織在實施 API 時應該注意幾種常見的 API 安全風險，例如OWASP API 安全十大列表中所列的風險。
身份驗證和授權機制不完善或缺失是許多公開 API 的主要問題。當 API 不強制執行身份驗證（私有 API 的情況通常如此，它們僅供內部使用）或身份驗證因素（客戶端知道、擁有或存在的東西）很容易被破解時，就會發生身份驗證失效的情況。由于 API 通常為組織的數據庫提供入口點，因此組織必須嚴格控制對它們的訪問。
API 很容易受到多種攻擊，而防御者多年來一直在其網絡和基于 Web 的應用中抵御此類攻擊。以下攻擊都不是新攻擊，但它們很容易被用來攻擊 API。
加密不足可能導致數據泄露和其他安全事故。這包括使用弱加密算法、未能加密敏感數據以及未實施 SSL/TLS 加密來保護傳輸中的數據。
“這些漏洞的可怕之處在于，被利用的 API 完全按照設計運行，”Reynolds 分享道?！斑@不是代碼中的錯誤，而是利用 API 的可預測性，讓它做一些開發人員不打算做的事情?！?/p>
這就是為什么無論您的 API 多么完善，您都需要優先考慮安全性。（我們可能聽起來像是老生常談，但這一步很容易被忽視。）API 安全性不應事后才考慮或被視為別人的問題。不安全的 API 會給組織帶來很大的損失，因此請在開發 API 時構建安全性并實施強大的管理系統。
Reynolds 繼續說道：“API 安全確實是一個大數據問題。要實現全面的 API 安全方法，您必須了解數據和身份，并深入了解端到端應用程序的業務邏輯。”
API 安全性最關鍵的方面之一是實施身份驗證和授權。此步驟可確保只有授權用戶才能訪問 API，并且他們的訪問級別適合其角色。在可行的情況下，請使用基于可靠、經過驗證的身份驗證和授權機制的解決方案，例如 OAuth2.0 和 OpenID Connect。
API 身份驗證和授權是指驗證客戶端身份并控制對 API 資源的訪問的過程。身份驗證是驗證客戶端是誰，而授權是控制他們在通過身份驗證后可以訪問哪些內容。
適當的 API 安全性需要實施身份驗證和強大的授權控制。要控制對 API 資源的訪問，您必須仔細全面地識別所有相關用戶和設備。這通常需要客戶端應用程序在 API 調用中包含一個令牌，以便服務可以驗證客戶端。
使用 OAuth 2.0、OpenID Connect 和 JSON Web 令牌 (JWT) 等標準來驗證 API 流量并定義訪問控制規則或授予類型，以確定哪些用戶、組和角色可以訪問特定的 API 資源。
在將安全模型應用于內部和外部 API 時保持一致有助于確保所有 API 都具有適當的身份驗證和授權。這降低了在沒有適當憑據或權限的情況下訪問 API 的風險。使用一致的模型還可以更輕松地審核和驗證所有 API 是否都正確實施了安全控制。
如果使用不同的模型，則會增加整體管理 API 安全性的復雜性。采用一致的方法，安全機制的更改只需在一個地方應用，而不必為不同的 API 分別重新實施。
總體而言，一致性可以實現更好的策略執行，降低配置錯誤的可能性，并且隨著更多 API 的添加，更容易大規模維護 API 安全性。
所有網絡流量都應加密 — 尤其是 API 請求和響應，因為它們可能包含敏感憑據和數據。所有 API 都應使用并要求使用 HTTPS。盡可能啟用 HTTP 嚴格傳輸安全比將 HTTP 流量重定向到 HTTPS 更好，因為 API 客戶端可能不會按預期運行。
實施 API 訪問控制的第一步是確定要控制訪問的資源。這可能是特定端點、數據資源或 API 內的操作。希望允許第三方通過 API 訪問內部數據和系統的組織必須引入并測試控制措施來管理該訪問：誰、什么、何時，以及對數據訪問、創建、更新和刪除的檢查 —零信任安全模型。
維護 API 數據完整性對于確保通過 API 傳輸的數據準確、完整和一致至關重要。
永遠不要假設 API 數據已被正確清理或驗證。在服務器端實施自己的數據清理和驗證例程，以防止標準注入漏洞和跨站點請求偽造攻擊。調試工具可以幫助檢查 API 的數據流并跟蹤錯誤和異常。
包裝來自 API 的錯誤響應可防止敏感的實現細節在面向客戶端的響應中暴露。
例如，通過返回通用的“404 Not Found”響應而不是特定于框架的錯誤消息，底層技術堆棧保持不透明。這有助于避免無意中泄露信息，從而幫助攻擊者。包裝還為客戶端提供了一致的錯誤響應格式，無論實際發生的錯誤是什么。客戶端獲得可操作的信息以妥善處理錯誤，而不是解析意外的服務器錯誤消息。
最重要的是，錯誤包裝使 API 能夠遵循故障安全默認設置，即您假設請求會失敗并據此制定計劃。API 可以在響應之前驗證數據完整性，而不是通過未包裝的錯誤暴露部分或損壞的內部狀態?？傮w而言，包裝 API 錯誤響應可提高 API 使用者的安全性、可靠性和溝通清晰度。
某些 API 會泄露過多信息，無論是通過 API 返回的無關數據量，還是泄露過多有關 API 端點的信息。當 API 將過濾數據的任務留給用戶界面而不是端點時，通常會發生這種情況。確保 API 僅返回實現其功能所需的信息。此外，在 API 級別實施數據訪問控制，監控數據，并在響應包含機密數據時進行混淆。
刪除不應共享的信息。由于 API 本質上是開發人員的工具，因此它們通常包含密鑰、密碼和其他信息，這些信息在公開之前應被刪除。但有時這一步會被忽略。組織應將掃描工具納入其 DevSecOps 流程，以限制機密信息的意外泄露。
API 為組織創造了無數機會來改善和提供服務、吸引客戶并提高生產力和利潤 — 但前提是您必須安全地實施它們。構建 API 時，請在開發過程中考慮質量和安全性，而不是等到事后。安全的 API 才是好的 API！
文章來源：Keeping Your APIs Safe: Best Practices for Top-Notch Security
<progress id="ajf1e"></progress>