開場白

今天的 D25，我們聚焦現代 Web 與雲端服務最常被打的面向──API Security（應用程式介面安全）。在前後端分離、行動 App 與微服務普及後，攻擊者常直接以 curl 或腳本撞擊 API。本文不做 PoC，只講設計思維與治理框架，核心三題：BOLA（Broken Object Level Authorization）、Rate Limit（速率限制）、JWT（JSON Web Token）生命週期管理。

目標

• 釐清常見 API 攻擊與其背後邏輯。
• 建立授權、速率限制、Token 治理的設計原則。
• 產出可提交的「API 風險與防禦對照表」。

一、BOLA（Broken Object Level Authorization）

概念：以「物件擁有權」為核心的授權缺陷。攻擊者只要改請求中的資源識別（如 id），即可越權存取他人資料。

示意請求

GET /user/profile?id=1024

若後端未驗證 id 是否屬於登入者，攻擊者可改為：

GET /user/profile?id=1025

防禦重點

• 後端每次存取都做「物件擁有權（Ownership）檢查」，不可只看“已登入”。
• 不信任前端傳入 ID；避免以可猜測的自增整數作為外部識別，可採 UUID/HashID。
• 建立集中式授權中介層（Authorization Middleware），避免驗證邏輯分散。
• 對敏感資源加上資源層與功能層雙重授權（物件是否屬於我 + 我是否具該操作權）。

二、Rate Limit（速率限制與濫用防治）

概念：對 API 呼叫量/頻率設上限，以抑制暴力登入、資料刮取、資源濫用。

策略分類（擇一或並用）

• IP 限速：每 IP 每分鐘/秒上限；適用匿名或公開端點。
• Token/使用者限速：以使用者或 Token 維度限制；適用登入後端點。
• 雙層限速：IP + 使用者同時限制；降低代理或多帳號繞過。
• 成本加權限速：依端點成本（如匯出、搜尋）給不同配額。

高維提醒

• Rate Limit 不是防火牆，它屬於行為風控；需搭配封鎖、記錄、告警與後續調查流程。
• 回應 429 之外，應對「高風險來源」暫停配額、進行驗證升級（CAPTCHA/二次驗證）。
• 避免一刀切；以自適應/分層策略平衡濫用與正常流量。

三、JWT（JSON Web Token）與會話治理

原理：JWT（Header.Payload.Signature）以簽章讓伺服器能無狀態驗證用戶身分。

常見盲點 → 改進方向

• 把 JWT 當 Session 用：JWT天生不可撤銷 → 改採短期 Access Token + Refresh Token並建黑名單/版本號（jti）。
• Payload 放敏感資料：Base64 只是編碼 → 僅放最小必要識別；敏感資訊改放伺服器側。
• Token 不輪替：長期有效風險高 → 實作 Token Rotation，刷新必換新。
• 弱簽章/容許 alg=none：可被竄改 → 僅允許 HMAC/RSA 並嚴格驗簽與演算法白名單。

治理建議（最小集合）

1. Access Token TTL 短（數分鐘～數十分鐘）＋ Refresh Token 管控續期。
2. 建立 撤銷/黑名單 與 jti 追蹤（支援「強制登出」與事件回應）。
3. 事件化日誌：簽發、刷新、撤銷皆產生審計紀錄；異常嘗試要可追。
4. 範圍（scope）/受眾（aud） 精準化，避免超權。

四、API 安全設計心法

• 最小授權原則：每個端點誰可以、可以做什麼要明確。
• 集中式授權：把 AuthZ 放在統一層，不讓檢查散落各服務。
• 錯誤回應策略：避免回傳內部細節；403（禁止）通常比 404（隱藏）更利於審計。
• 內/外/合作 API 分層：不同面向給不同認證、授權、限速與審計強度。
• 輸入驗證：ID/參數型別、長度、格式白名單；避免把未校驗的值直入資料層。

五、可驗收輸出｜API 風險與防禦對照表

交付標準：至少列出 3 個端點；每項皆含風險→對策→量化指標。

小結

API 攻擊多半發生在邏輯層而非單純語法層。將焦點放在三件事：

1. **物件授權（BOLA）**要嚴格且集中；
2. 速率限制要分層且事件化處置；
3. JWT 生命週期要短、可撤銷、可追蹤、可輪替。
   把這三問寫進設計審查表：「誰能用？能用幾次？什麼時候失效？」——能答清楚，八成風險就已被消減。