第一章：API 的崛起與安全危機的成因

1.1 API：現代網路的「機器網站」

API（應用程式介面） 是組織內部、行動應用程式以及各類服務之間溝通的橋樑，被形象地稱為「機器的網站」。當前數位生活中的幾乎每一項操作，如在 Google 地圖上查詢餐廳後預約 Uber 叫車、透過 Venmo 進行銀行轉帳，或是利用 Kayak 比較各航空公司機票，其背後的核心驅動力皆是 API。API 實現了跨組織的無縫整合與功能串接。

1.2 「完美 API 風暴」的統計數據

• 流量主導權（83%）： 根據 Akamai 的研究，全球網際網路流量中高達 83% 是由 API 驅動的，這證明了 API 技術的普及性及其在支撐現代網站與應用程式中的關鍵地位。
• 首要攻擊向量（No. 1）： Gartner 預測，API 攻擊已成為企業面臨的最頻繁攻擊媒介。
• 安全測試缺口（4%）： 調查顯示，高達 96% 的 API 測試著重於功能、性能與 Bug 修復，而針對安全性測試的比例僅佔 4%。這種開發速度與安全防禦之間的巨大失衡，構成了攻擊發生的「完美風暴」。

第二章：API 攻擊路徑與心理學

2.1 為什麼 API 是誘人的目標？

API 是應用程式功能背後的「黏合劑」與「結締組織」，直接連接外部世界與內部的資料庫、交易引擎及敏感資訊。API 吸引攻擊者的原因在於其背後隱藏的高價值數據：

1. 敏感數據流向： 包含信用卡資訊、個人識別資訊（PII）與企業知識產權。
2. 可直接操作的功能： 每次登入、存支票或轉帳，背後都是獨立的 API 調用。
3. 邏輯漏洞（Logic Flaws）： 若 API 配置或邏輯設計有誤，這些缺陷會直接轉化為可利用的漏洞。

2.2 API 攻擊的實際執行方式

許多開發者誤以為 API 是隱形的，但事實上，透過瀏覽器的「開發者工具（Inspect）」即可輕易觀察到如 Fetch Flights 等 API 調用的構造與數據酬載。 攻擊者的典型路徑：

1. 註冊與監控： 攻擊者先正常使用應用程式（如安裝 App 或建立帳號），同時監控流量中的 API 調用。
2. 繞過 UI（User Interface）： 攻擊者會避開受到嚴格控制的 UI 界面，直接透過命令列向 API 發送請求。
3. 直接操控： UI 只能顯示按鈕和預設數據，但 API 層級是完全不受控的命令列，攻擊者可以編寫並發送任何自定義請求，這時完全依賴後端邏輯來判斷請求的合法性。

2.3 殺傷鏈的簡化

傳統網路攻擊的「殺傷鏈（Kill Chain）」涉及複雜的多步驟流程（如偵查、武器化、橫向移動、權限提升等），對技術要求極高。相比之下，API 攻擊路徑極短：一旦攻擊者在 API 層級發現漏洞，往往能直接導致數據外洩，攻擊模式更為簡單高效。

第三章：監管趨勢與法規遵循

3.1 全球執法案例

• T-Mobile： 因 API 未經授權訪問導致 3,700 萬用戶紀錄外洩，必須向 SEC 提交 8K 文件報告事件。
• TracFone（Verizon）： 遭 FCC 罰款 1,600 萬美元，並被強制要求執行持續性的靜態與動態安全測試，且必須將 API 列為優先測試對象。

3.2 關鍵法規解析

• PCI DSS 4.0： 強調對業務邏輯濫用、API 風險培訓的監控。
• GDPR / CCPA / HIPAA： 只要 API 接觸到個人隱私或醫療保健資訊，即在稽核範圍內。
• SEC 新規： 公開上市公司必須報告其安全計畫，包括對 API 風險的管控。
• FedRAMP： 要求針對雲端服務進行每月的漏洞掃描，涵蓋 API 測試。

第四章：OWASP API Security Top 10 (2023) 深度解析

這是講義的核心部分，透過 OWASP 十大威脅 結合真實案例來理解 API 的脆弱性。

1. 失效的物件層級授權 (BOLA - Broken Object Level Authorization)

這是 API 安全中最常見且最危險的威脅。它探討「使用者 A 是否能訪問使用者 B 的數據」。

• 機制： 應用程式未驗證發出請求的使用者是否有權操作該特定的物件（ID）。
• 案例研究：Coinbase
  • 手法： 駭客在進行交易時，截獲 API 請求，將自己擁有的以太幣（Ethereum）產品 ID 更改為自己並不擁有的比特幣（Bitcoin）ID。
  • 結果： 後端 API 存在「遺漏的邏輯驗證檢查」，未核實該資產是否屬於該用戶，導致 $1,060 美元的以太幣被當作價值 $43,000 美元的比特幣賣出。
  • 教訓： UI 的限制並非安全保障，必須在 API 層級進行邏輯檢查。
• 案例研究：Peloton
  • 手法： 攻擊者發現一個無需憑證即可查詢的 API。Peloton 修復了「身分驗證（Authentication）」問題，要求登入，但未解決「授權（Authorization）」問題。
  • 結果： 任何擁有帳號的使用者仍能透過該 API 存取全球 400 萬用戶的紀錄。

2. 失效的使用者身分驗證 (Broken Authentication)

指身分驗證機制薄弱，例如缺乏 CAPTCHA、二階段驗證，或甚至完全沒有身分驗證。

• 案例研究：Duolingo
  • 手法： 攻擊者發現一個公開 API，只要提供電子郵件，API 就會回傳該用戶在平台上的詳細檔案資訊。
  • 結果： 超過 200 萬條紀錄外洩。這類「隱藏 API」常因開發壓力而被忽視，但攻擊者會專門搜尋它們。

3. 失效的物件屬性層級授權 (BOPLA)

合併了舊版的「大量賦值（Mass Assignment）」與「過度數據曝露」。

• 機制： API 回傳了過多非必要的敏感字段，或允許用戶修改不應修改的屬性（如將帳號從「免費」改為「進階」）。
• 案例研究：Venmo
  • 手法： Venmo 首頁有一個顯示最近交易的功能，雖然 UI 上的數據已去標識化，但背後的公開 API 卻回傳了完整的紀錄內容（包含姓氏等）。
  • 結果： 攻擊者寫入腳本抓取了超過 2 億條詳細交易紀錄。
  • 預防措施： 遵循「數據最小化原則」，API 僅應回傳業務所需的最小字段。

4. 資源消耗不受限制 (Unrestricted Resource Consumption)

缺乏速率限制（Rate Limiting），導致大規模數據抓取或阻斷服務（DoS）。

• 案例研究：Trello
  • 手法： 攻擊者利用一個邀請成員的公開 API，將暗網獲取的 5 億個電子郵件地址發送給 API，藉此確認哪些是 Trello 用戶並獲取其資料。
  • 繞過技巧： 攻擊者分散使用數千個 IP 地址與住宅代理伺服器，使請求頻率維持在 WAF 偵測閾值之下。

5. 失效的功能層級授權 (BFLA)

這與物件授權（BOLA）相似，但重點在於「功能」。例如，普通用戶是否能執行管理員才能用的 DELETE 或 PUT 方法。

• 案例研究：Bumble
  • 手法： 使用者原本只能透過 GET 查看帳號類型，但攻擊者發現該端點也接受 POST 請求，並能直接修改帳號狀態為「已付費（Paid）」。

6. 不受限制地存取敏感業務流程 (Unrestricted Access to Sensitive Business Flows)

針對合法業務邏輯的濫用（例如搶票、機器人註冊）。

• 案例研究：Instagram
  • 手法： 密碼重設需要 6 位數代碼（100 萬種組合）。Instagram 雖然限制單一 IP 只能嘗試 200 次，但攻擊者透過更換 IP，在 10 分鐘的有效期限內嘗試了所有組合，成功接管帳號。
  • 改善建議： 應限制代碼嘗試次數而非 IP、縮短有效期，並避免使用可預測的數字代碼。

7. 伺服器端請求偽造 (SSRF)

誘導伺服器發送請求至不該去的地方（如內部資源或惡意網站）。

• 案例研究：Capital One
  • 手法： 攻擊者利用 WAF 的配置錯誤與過度權限，誘導伺服器列出並下載 AWS S3 存儲桶中的內容。
  • 結果： 1 億份信用卡申請資料與 10 萬個社會安全號碼外洩，導致 1.9 億美元罰款。

8. 安全配置錯誤 (Security Misconfiguration)

涵蓋未打補丁、未加密、CORS 配置錯誤、錯誤訊息洩露等基礎設施問題。

• 案例研究：Experian
  • 手法： 一個為合作夥伴設計的專用 API 被發現存在漏洞，只要輸入任何人的姓名、地址與「任意數字組合」的生日欄位，就能查詢其信用評分。

9. 庫存管理不當 (Improper Inventory Management)

針對「殭屍 API（Zombie APIs）」或「影子 API（Shadow APIs）」的攻擊。

• 案例研究：Optus
  • 手法： 一個工程師發布了未受保護、無身分驗證且使用遞增 ID 的測試 API。
  • 結果： 導致 980 萬名澳洲電信訂戶資料外洩，引發國家級爭議。
• API 發現方法： 流量分析、程式碼掃描、應用程式爬蟲，以及最重要的「與開發團隊溝通」。

10. API 的不安全消耗 (Unsafe Consumption of APIs)

過度信任第三方 API（如 Salesforce, Stripe）。

• 案例研究：Companies House (英國)
  • 手法： 有人註冊了一個包含 XSS（跨站腳本）攻擊標籤的「公司名稱」。
  • 風險： 任何串接該 API 數據且未做輸入驗證的第三方網站，都會因此觸發 XSS 攻擊。

第五章：API 攻擊趨勢分析

5.1 數據統計特徵

分析多起外洩事件後發現：

1. 高容量特徵： 約 70% 的攻擊涉及某種形式的高容量暴力破解（如大規模抓取）。
2. 核心肇因： 儘管速率限制是重要防禦手段，但 90% 的漏洞源自 OWASP API 1, 2, 3（授權、驗證、過度數據曝露）。

5.2 速率限制的迷思

• 速率限制（Rate Limiting）並非完美的防禦機制，它只是「防禦牆」，而非問題根源。
• 攻擊者的策略： 他們可以花幾個月的時間緩慢爬取（Fly under the radar），繞過 WAF 的毫秒級判斷。
• 結論： 若 API 本身不該回傳敏感資料，攻擊者就不會發送 5 億次請求。

第六章：企業防禦與威脅建模框架

6.1 威脅建模公式

企業應評估：風險 (Risk) = 威脅 (Threat) × 漏洞 (Vulnerability) × 可能性 (Likelihood) × 影響 (Impact)。

6.2 攻擊者感興趣的資產

在進行安全評估前，需明確「我有什麼是攻擊者想要的？」：

• 個人與財務數據： 用於身分竊取或暗網銷售。
• 企業數據： 涉及間諜活動或知識產權。
• 服務濫用： 詐騙、盜用資金或基礎設施破壞。

6.3 最佳實踐建議

1. 左移安全（Shift Left）： 在 API 設計階段就讓安全團隊介入，定義邏輯與權限需求。
2. 集中管理： 使用 API Gateway 來集中化策略執行與庫存可見性。
3. 權限最小化（Least Privilege）： 嚴格限制伺服器與服務的權限，避免如 SSRF 的連鎖反應。
4. 持續性壓力測試： 針對業務邏輯進行模擬攻擊，而不僅僅是程式碼掃描。
5. 跨團隊協作： 確保開發者也接受 API 安全培訓，因為他們最了解代碼中的邏輯缺陷。

結語： API 安全不應僅被視為技術挑戰，更是涉及合規、業務連續性與企業信譽的重大業務風險。透過理解 OWASP API Top 10 並建立完善的威脅建模，組織方能從這場「完美的風暴」中全身而退。