了解這些漏洞對任何 API 開發人員來說都是至關重要的。以下是主要風險的摘要（基於 2023 年發布）。1. 破碎的物件層級授權 (BOLA - Broken Object Level Authorization)#
問題：通常稱為 IDOR (不安全的直接物件參考)。當 API 暴露物件的參考（如 URL 中的 id）並且不檢查已驗證的使用者是否實際擁有存取該特定 ID 的權限時發生。
範例：使用者 A (id: 100) 將 URL 從 /orders/100 更改為 /orders/101，並且可以看到使用者 B 的訂單。
修復：始終檢查：if (order.owner_id != currentUser.id) return 403;
2. 破碎的身份驗證 (Broken Authentication)#
範例：允許弱密碼、登入時沒有速率限制（暴力破解）、在 URL 中發送 Token，或登出後有效 Token 仍然有效。
修復：使用標準 OIDC 流程，強制執行強密碼，實作 MFA (多因素身份驗證)。
3. 破碎的物件屬性層級授權 (Broken Object Property Level Authorization)#
問題：API 端點暴露了比客戶端需要的更多資料欄位（過度資料暴露），或允許客戶端更新他們不應更新的欄位（大量賦值 - Mass Assignment）。
範例：一個端點返回包含 password_hash 和 is_admin 的完整 User 物件，即使 UI 只需要 username。或者，PUT /profile 允許使用者發送 {"is_admin": true}，而程式碼不知情地保存了它。
修復：只返回必要的欄位 (Response DTOs)。詳細列出允許的輸入欄位白名單。
4. 無限制的資源消耗 (Unrestricted Resource Consumption)#
問題：API 不限制用戶端可以使用的資源，導致阻斷服務 (DoS)。
範例：缺少速率限制、允許分頁中的巨大頁面大小，或鎖定資料庫的複雜 GraphQL 查詢。
修復：實作速率限制（例如 60 req/min），限制 Payload 大小，並設定超時限制。
5. 破碎的功能層級授權 (Broken Function Level Authorization)#
問題：依賴客戶端應用程式隱藏管理功能，而不是在伺服器上強制執行檢查。
範例：存在端點 DELETE /api/users。UI 隱藏了普通使用者的按鈕，但駭客找到 URL 並直接呼叫它。
修復：在程式碼中為每個控制器方法檢查角色/權限。@PreAuthorize("hasRole('ADMIN')")。
6. 無限制存取敏感業務流程 (Unrestricted Access to Sensitive Business Flows)#
問題：以損害業務的方式濫用合法的業務工作流程（自動化/機器人）。
修復：機器人偵測，對敏感流程使用 CAPTCHA。
7. 伺服器端請求偽造 (SSRF - Server Side Request Forgery)#
問題：API 根據使用者提供的 URL 提取遠端資源，而沒有進行驗證。
範例：POST /image-upload 接受一個 URL。攻擊者發送 http://localhost:8080/admin。伺服器提取它（繞過防火牆）並返回內容。
修復：將允許的網域列入白名單。不允許呼叫內部網路或 localhost。
8. 安全配置錯誤 (Security Misconfiguration)#
範例：詳細的錯誤訊息（堆疊追蹤）洩漏資訊、啟用了不必要的 HTTP 動詞、缺少安全標頭（CORS、CSP）或未修補的依賴項。
修復：加固程序、自動化掃描、在生產環境中禁用除錯模式。
9. 不當的庫存管理 (Improper Inventory Management)#
問題：「殭屍」API。你無法保護你不知道存在的東西。
範例：舊的 API 版本 (v1) 仍在運行且沒有修補程式，而 v3 已上線。測試環境暴露給公眾。
10. API 的不安全使用 (Unsafe Consumption of APIs)#
範例：您的 API 呼叫天氣服務。該服務被駭客入侵並將惡意 SQL 注入 Payload 發送回給您，您將其儲存到資料庫中。
修復：驗證/消毒所有輸入，即使是來自「受信任」的外部 API。
關鍵要點#
BOLA (IDOR) 是頭號 API 漏洞。始終檢查擁有權。
什麼都不信：不信任使用者輸入，不信任內部服務，不信任第三方 API。
Modified at 2026-02-12 08:28:40
