企業常遇 API 遭受大量攻擊的緊急狀況。API 如同住宅入口，需多重保護。本文實務拆解身份確認、權限管理、流量管控、資料檢查、加密傳輸、錯誤隱藏以及監控警示等七項措施，協助中小企業從設計階段納入安全考量。
住宅入口需多重保護，API 同樣需要
許多業主認同居家安全不可輕忽，卻忽略自家網站 API 可能缺乏基本驗證。API 是資料交換的關鍵通道，也是攻擊者鎖定的目標。根據 OWASP 報告，超過六成資料外洩與 API 弱點有關。只要網站涉及金流或會員功能，就必須重視 API 安全。
本文將說明常見威脅，並提供七項防護建議。若不熟悉 API，請先參閱相關整合指南。
API 為何容易成為目標
現代網站多依賴 API 傳遞資料，包括登入、訂單及庫存查詢等。這導致商業邏輯直接暴露、原始資料無遮蔽、端點眾多且自動化攻擊成本低。
第一層：身份確認機制
身份確認用來驗證請求來源，是安全基礎。
API 金鑰方式
為使用者核發金鑰並置於標頭中，切勿放在前端或網址參數。
OAuth 2.0 搭配 JWT
適合需要細部權限的場景，透過時效性權杖與編碼資訊減少資料庫查詢。
實務建議
- 設定適當到期時間
- 實作權杖撤銷功能
- 避免回傳完整權杖
第二層：權限控管
確認使用者能執行的操作，避免物件層級授權缺失導致越權存取。
保護做法
- 檢查特定資料存取權限
- 採用角色或屬性控管模型
- 使用 UUID 取代可預測 ID
- 分離管理與一般 API
第三層：流量限制
防止暴力破解、阻斷服務及資料爬取。
設定建議
- 依敏感度調整限制
- 回傳 429 狀態碼
- 區分已驗證與未驗證請求
- 搭配 IP 與地區封鎖
第四層：輸入檢查與過濾
絕不信任外部資料，以防注入攻擊。
保護措施
- 定義型別與長度限制
- 使用白名單驗證
- 執行輸出編碼
- 採用參數化查詢
第五層：傳輸加密
強制使用 HTTPS，避免明文傳輸風險。
進階做法
- 啟用 HSTS
- 實作欄位級加密
- 使用憑證鎖定
第六層：錯誤處理與隱藏資訊
避免回傳敏感細節，改用通用訊息與代碼。
不安全範例
{ "error": "User not found" }安全範例
{ "error": "認證失敗", "code": "AUTH_001" }建議做法
- 僅回傳通用訊息
- 詳情記錄於內部日誌
- 關閉除錯模式
第七層：日誌監控與異常偵測
記錄認證失敗、異常模式及錯誤率，並設定即時警示。
應記錄事件
- 認證失敗請求
- 異常存取模式
- 權限提升嘗試
警示條件
- 短時間多次失敗即封鎖
- 單一權杖過多資源存取
- 錯誤率異常上升
API 安全檢核清單
- 要求有效身份驗證
- 執行物件層級授權檢查
- 設定合理流量限制
- 驗證所有輸入
- 全程使用 HTTPS
- 隱藏內部細節
- 完整記錄日誌
- 下架停用版本
結語：安全需持續演進
API 安全不是單次任務，而需多層防禦與不斷更新。建議在架構設計階段即納入保護措施。
