API 驗證機制怎麼設計？從金流串接學到的三層防護實戰 — 編譯摘要
濃縮
核心結論
- 單純的 API Key 驗證不足以防禦中間人攻擊與重送攻擊，需要三層防護：API Key（身份識別）+ SHA-256 簽章（防竄改）+ 時間戳驗證（防重送）。
- 請求簽章（Request Signature）的設計源自台灣金流串接經驗（綠界、藍新等），將關鍵欄位 + 密鑰 + 時間戳組合後算 Hash，雙方各自計算比對。
- Key 管理採「產生時顯示一次」的模式（參考 GitHub PAT），後台僅保存 Hash，降低二次外洩風險。
關鍵證據
- 簽章材料：目標網站網址 | API Key | 時間戳，將網址綁入簽章可限制 Key 的使用範圍。
- 時間戳容許範圍 5 分鐘，兼顧伺服器時間差與防重送需求。
- 驗證順序：有無 Key → Key 正確性 → 時間戳有效性 → Hash 比對，四關全過才放行。
質疑
依賴哪些前提假設？
- 依賴 HTTPS 保護傳輸機密性，簽章本身不加密。
- 假設兩台伺服器的時鐘差異在 5 分鐘以內（依賴 NTP 同步）。
- 假設管理員會安全保管 Key（系統無法控制人為因素）。
換產業/規模/技術棧還成立嗎？
- 三層驗證的概念適用於任何跨系統 API 通訊，不限於 WordPress/PHP。
- 高流量場景下，每次請求都做 SHA-256 計算的效能影響可忽略不計。
- 需要更高安全等級的場景（如銀行 API）可能還需要 mTLS、IP 白名單等額外防護。
反例或邊界條件
- 如果不用 HTTPS，所有防護都失效。
- 伺服器時間嚴重漂移時，合法請求也會被拒。
- 此設計不含權限分級（RBAC），所有持有 Key 的請求擁有相同權限。
對標
其他領域的類似現象
- 銀行轉帳驗證：帳號（Key）+ OTP（時間戳驗證）+ 交易簽章（Hash），三層結構幾乎一致。
- 實體門禁系統：門禁卡（Key）+ 時間限制（上班時間才能進）+ 雙因素驗證（指紋）。
知識可遷移到哪些場景
- Webhook 接收端的簽章驗證（GitHub、Stripe、LINE 等平台都用類似機制）。
- IoT 裝置間的通訊驗證。
- 任何需要在不信任網路上驗證請求真實性的場景。
關聯概念
- [[請求簽章]]
- [[API 金鑰管理]]
- [[重送攻擊防禦]]
- [[HMAC 驗證]]
- [[Webhook 整合]]
![]()