API 安全最佳實務： 如何保護您環境中的 API
什麼是API安全性？
當今的軟體應用程式開發已離不開 API， 它們通過控制程式的元素來交互實現各種應用系統和軟體系統之間的無縫接軌。從資料庫和伺服器通訊的 Web API，到允許存 AP 功能的作業系統，以及提供開發人員將事先編寫好的程式碼整合到自已的 API 程式碼資料庫，API 不僅簡化了複雜應用程式的開發，也提升了靈活性，並縮短開發時間。
然而，API 也有可能成為風險來源，潛在攻擊者可以使用 API 獲得未經授權的存取，如發起 DDoS 攻擊等惡意活動，並獲得立足點進行橫向移動或竊取資料。 且當我們談論 API 安全的含義和 API 安全最佳實務時，我們將重點聚焦於企業用來保護 API 免受此類利用與濫用的流程和措施。
API安全威脅的類型
API 具有自己特有的漏洞和安全風險， 當企業希望保持強大的安全狀態時，需要有針對性的方法。以下列出最新的 OWASP API Security Top 10 中這些威脅可能導致的負面影響：
1. 物件層面的無效授權 Broken Object Level Authorization
透過操縱 API 請求中的物件識別，攻擊者可以利用 API 端點來取得存取權限，可以是連續整數、UUID 或通用字串，容易被識別且利用。
2. 無效的身分認證 Broken Authentication
如果您的身份驗證機制存在漏洞，攻擊者可以利用身份驗證令牌（Token），或透過冒充合法使用者來存取您的資料。
3. 物件層面屬性的無效授權 Broken Object Property Level Authorization
此授權機制負責管理對物件或屬性特定部分的存取。若缺乏授權驗證，未經授權的使用者可能會獲得應受限制的存取權限。
4. 無限制的資源耗用 Unrestricted Resource Consumption API
需要資源來處理請求，但如果沒有設定資源限制，攻擊者可發動 DDoS 攻擊， 導致系統宕機或增加營運成本。
5. 無效的功能權限控管 Broken Function-level Authorization
由於存在大量使用者、群組和角色，存取控制策略可能很快就會變得複雜。如果使用者權限系統不完整或損壞，將為攻擊者敞開了大門。
6. 無限制存取敏感業務流程 Unrestricted Access to Sensitive Business Flows
這不是由實作漏洞引起的，而是業務工作流程中敏感資訊的過度使用，可能讓攻擊者找出此開發流程，自動進行過度存取並造成損害。
7. 伺服器端請求偽造 Server-side Request Forgery
許多企業認為 VPN 或防火牆已提供足夠的保護，但若 API 在未驗證用戶提供的 URI 下抓取遠端資源，攻擊者可利用經過設計的請求傳送到未預期的目的地。
8. 安全配置錯誤 Security Misconfiguration
配置更改和定期自定義對系統至關重要，但每次更改都可能帶來風險，尤其當開發人員未遵守 API 安全最佳實踐時。
9.API 資產管理不當 Improper Inventory Management OWASP
提醒企業，API 暴露的端點多於傳統網頁應用，因此詳細的文檔非常關鍵。棄用的版本或暴露的調試端點是攻擊者輕易利用的目標。
10. 不安全的使用 API Unsafe Consumption
開發人員通常信任與第三方 API 互動的端點，但攻擊者可能針對整合到目標 API 的第三方服務發起攻擊，並以此為跳板進一步攻擊。
影子API與殭屍API
除了常見的 API 安全威脅外，影子 API 和殭屍 API 是兩種特別值得關注的風險類型。這些 API 通常未被企業監控，並可能帶來重大安全風險。
影子 API 類似於影子 IT 的概念，通常是為滿足小型開發者需求而低調建立的 API，或者是未經授權且未被納入清單的 API。這些 API 的建立和部署通常不符合企業的政策與治理規範，因此無法被現有的 API 安全測試工具監控。影子 API 是否具備必要的驗證與訪問控制機制無法保證，並且由於它們不為安全團隊與企業所知，可能使組織面臨數據洩漏或隱私風險。
殭屍 API 面臨類似的挑戰，但它們的存在方式不同。殭屍 API 指的是未被正式停用的 API，可能是因為開發團隊已更新至新版本，但忘記了舊版的存在，或為確保更新過程無問題而選擇繼續保留舊版運行。你可能會忘記某個暴露的 API 或其端點，但攻擊者卻樂於幫你記住它們。
API攻擊的影響是什麼？
為了解這些 API 風險，我們來看看威脅行為者利用 API 漏洞後可能發生的一些情況：
① 敏感資料暴露：API 負責個人資訊處理，包括醫療保健詳細資訊、金融交易和 PII。由於這些 API 通常被第三方開發者和應用程式使用，確保其安全性應是重中之重，以維持消費者信任並確保符合法規要求。
② 未經授權的訪問：一旦攻擊者通過 API 漏洞建立了立足點，他們的惡意行為幾乎沒有上限。威脅行為者可能植入惡意軟體或勒索軟體、發起中間人攻擊、進行代碼注入，甚至橫向移動以訪問關鍵資產，對企業造成嚴重破壞。
③ DDoS 攻擊：當 API 資源沒有受到限制時，特別容易成為分散式阻斷服務 （DDoS）攻擊的目標。攻擊者會向 API 發送大量流量和通信請求，導致正常用戶無法使用服務。這些攻擊通常來自多個來源，進一步加劇其影響。
如何利用API安全最佳實務防禦 API攻擊？
保護 API 需要採取多方面、分層的方法。 首先了解您環境中 API 風險的實際範圍， 並在開發週期中儘早實施控制措施來識別和修復漏洞。如果你正在尋找 API 安全檢查清單，以下整理了一些 API 安全最佳實踐，提供您參考。
實施強而有力的控制措施
在最早的階段就需要實施核心安全措施。例如，多因素身份驗證可防止攻擊者即使獲取了憑證也無法訪問 API，使用 OAuth 或 JWT 等強大驗證機制也能有效阻止攻擊者。通過啟用速率限制，可以大幅減少暴力破解攻擊的風險。此外，始終使用數據加密來提高數據的安全性，降低被竊取的可能性。
確保所有 API 的可視性
無論您的文件管理有多完整，仍可能存在未被看到的 API，而安全測試工具無法保護不可見的內容。尋找一個能提供單一整體視圖的解決方案，涵蓋內部、外部、第三方、託管、非託管、影子和殭屍 API，並顯示它們的使用方式以及隨時間推移所做的更改。
鼓勵開發人員減少攻擊面
API 的好處之一是它們可以在不同的專案中重複使用，但許多開發者因擔心修改現有 API 而選擇從頭開始，無意中增加了攻擊面。使用能提供歷史 API 可見性的工具，可以讓開發者重新考慮直接使用現有 API，而非重新編寫。
儘早並持續驗證 API
對於 API 安全性，將安全左移至開發早期階段至關重要。從設計階段開始掃描 API 文檔和代碼，將安全性整合到設計中，能幫助團隊發現錯誤配置以及路徑定義、身份驗證結構和傳輸加密中的風險。此外，將文件與實際實施進行對比，可以快速識別並解決問題，而不會造成中斷。