API 是現代軟體的連接組織，為行動應用、微服務和第三方整合提供支援。因為 API 直接公開應用邏輯和資料，它們已成為攻擊者最喜愛的目標。API 安全是設計、測試和防禦這些介面免受濫用的學科。
API 有什麼不同之處
與傳統網頁不同，API 通常使用 JSON 或 XML 等結構化資料格式進行通信，且人工監督最少。這意味著：
- 每個端點的攻擊面更大 — 每個 API 路由本質上是自己的迷你應用，具有自己的身份驗證、驗證和業務邏輯。
- 機器對機器信任 — 服務經常假設如果請求具有有效令牌，它就是合法的，攻擊者通過令牌竊取或重放來利用這一點。
- 快速變化 — API 發展迅速，未記錄或已棄用的「影子」端點經常滑過安全審查。
常見漏洞類別
OWASP API Security Top 10 涵蓋生產系統中最普遍的問題：
- 物件層級授權破損 (BOLA) — 使用者可以通過簡單地更改請求中的 ID 來存取另一個使用者的資料，因為伺服器未驗證所有權。
- 身份驗證破損 — 弱令牌處理、可預測的工作階段標識符，或登入端點上缺少速率限制。
- 過度資料暴露 — API 傳回完整的資料庫物件，並依賴用戶端篩選敏感欄位。
- 缺少資源和速率限制 — 沒有限流允許攻擊者暴力破解認證或耗盡後端資源。
- 函數層級授權破損 — 普通使用者可以到達僅限管理員的端點，因為缺少角色檢查或不一致。
- 大量指派 — 直接接受用戶端提供的欄位（如
isAdmin）到資料庫模型，無需篩選。 - 安全設定錯誤 — 詳細的錯誤訊息、暴露的偵錯端點，或遺漏的安全標頭。
- 注入 — 未淨化的輸入通過 API 參數到達 SQL、NoSQL 或命令直譯器。
身份驗證和授權要點
身份驗證確認誰在呼叫 API；授權確認他們可以做什麼。強大的 API 安全需要兩個層級在每個請求上獨立執行：
- 使用 OAuth 2.0 或 OpenID Connect 等業界標準協議，而不是自訂令牌方案。
- 正確驗證 JWT — 檢查簽名、過期、發行者和受眾聲明；絕不信任未簽名或
alg: none令牌。 - 在伺服器端強制執行物件層級檢查：每個引用資源 ID 的請求都必須驗證呼叫者實際上擁有或有權存取該資源。
- 將最小權限原則應用於 API 金鑰和服務帳戶，縮小其範圍而不是授予廣泛存取權限。
輸入驗證和輸出控制
將每個 API 參數（包括標頭、查詢字串和嵌套 JSON 欄位）視為不受信任的輸入：
- 使用結構描述驗證（例如 JSON Schema 或基於 OpenAPI 的驗證器）驗證資料型別、長度和格式。
- 在反序列化期間使用預期欄位的允許清單，以防止大量指派攻擊。
- 僅傳回用戶端合法需要的欄位；避免在回應中傾倒整個內部物件。
- 標準化錯誤回應，使其不洩露堆疊追蹤、內部路徑或資料庫詳細資訊。
速率限制、監控和日誌記錄
即使經過良好身份驗證的 API 也需要防止濫用模式：
- 實施每個使用者和每個 IP 的速率限制，以削弱暴力和抓取嘗試。
- 記錄身份驗證事件、授權失敗和異常存取模式以供日後分析。
- 監控異常情況，例如對敏感端點的請求突然激增或來自意外地理位置的存取。
- 維護準確的 API 清單 — 您無法保護不知道存在的內容，因此追蹤並淘汰已棄用或影子端點。
實用測試方法
保護 API 是一個持續的過程，而不是一次性的審計：
- 將 API 特定工具（如與安全掃描器配對的 Postman 集合）納入 CI/CD 管道。
- 執行手動測試以尋找授權缺陷，因為自動掃描器經常遺漏 BOLA 和業務邏輯問題。
- 保持 API 文件 (OpenAPI/Swagger 規範) 與實際實作同步，以避免測試期間出現盲點。
- 以與檢查自己程式碼相同的方式審查第三方 API 整合，因為受感染的合作夥伴 API 可能成為攻擊向量。
結束語
API 安全將經典 Web 應用安全原則與機器對機器通信大規模獨特挑戰相結合。正確處理授權、驗證每個輸入，以及維護 API 表面的可見性是有彈性防禦的基礎。
探索 Korra Studio 關於 Web 應用安全和身份驗證設計的相關單元，以建立對這些概念更深入的實踐理解。