Cover image for Building Secure APIs in 2026: Threats Developers Can't Ignore

Eva Clari

如今，每個產品團隊在推出使用者介面之前，都會先推出 API。行動應用程式、合作夥伴整合、內部微服務，以及接上系統的 AI 代理，全都透過同一組端點進行通訊。這種流量集中使 API 層成為堆疊中最具吸引力的目標，而攻擊者也深知這一點。Verizon 2025 年資料外洩調查報告將網路應用程式與 API 攻擊列為已確認外洩事件的主要攻擊媒介之一，且流量正持續從瀏覽器工作階段轉向機器對機器呼叫，而大多數安全團隊對這些呼叫的監控仍不如對使用者登入的監控嚴密。

破損的物件層級授權仍然是多數 API 的致命傷

OWASP 在 2023 年 API 安全十大風險中將「破損的物件層級授權」列為 API1，且至今仍比其他任何 API 缺陷造成更多實際事件。其模式簡單卻不斷被團隊重複推出：像 /api/orders/12345 這樣的端點雖然能正確驗證呼叫者，卻從未檢查該呼叫者是否真正擁有訂單 12345。只要更換 ID，就能讀取或修改他人的資料。

應在物件層級而非端點層級修正此問題。每個透過 ID 存取資源的處理程序，在回傳資料前都必須執行明確的擁有權或權限檢查，而非僅在入口處驗證工作階段權杖。將此檢查集中於共用的授權函式庫或政策引擎中，以免個別開發者在期限壓力下遺漏。對 API 測試套件執行自動化授權模糊測試，其方式應與執行功能測試相同。Postman 的 API 狀態報告已連續數年指出，授權測試是 API 開發流程中最常被跳過的步驟之一，而 BOLA 之所以持續出現在漏洞賞金報告中，正是因為團隊仍將驗證與授權視為同一問題。

面向 LLM 的 API 帶來新的威脅類別

包裝或前端語言模型的 API 所帶來的風險，是標準 REST API 所沒有的。OWASP LLM 應用程式十大風險指出，提示注入、過度代理以及不安全的輸出處理是主要風險，而這三者都直接透過 API 層浮現，而非僅透過聊天小工具。

將使用者或上游系統可影響的每個欄位都視為模型的未信任輸入，並將每個模型輸出視為下游系統的未信任輸入。不要讓模型回應在未經驗證的情況下觸發資料庫寫入、檔案操作或對其他內部 API 的呼叫。若透過 API 公開函式呼叫或工具使用，應將每個工具的範圍限定，並要求明確的允許清單，而非授予模型對內部端點的廣泛存取。應依權杖成本及呼叫可觸發的下游動作成本進行速率限制，而非僅依請求次數限制，因為單一提示可能擴散為數十個內部呼叫。當 AI 代理自主呼叫 API 時，應為每個代理發行各自的短期、範圍限定的憑證，而非共用服務帳戶。共用憑證會使單一受損代理轉化為對使用該憑證的所有代理的完整存取。

在閘道執行零信任

以邊界為基礎的安全假設內部網路可信任，而一旦服務跨越多個雲端、第三方整合以及 AI 代理依非完全可控的排程進行呼叫，此假設即告失效。零信任將每個請求視為未信任，直到其證明自身可信任，而 API 閘道正是統一執行此政策之處，而非依賴各服務自行正確執行。

在服務之間實作相互 TLS，使雙方都能驗證連線，而非僅由呼叫者對伺服器進行驗證。發行範圍限定的短期 OAuth 2.0 權杖，而非長期有效的 API 金鑰（可授予數月廣泛存取權限）。將範圍定義為特定動作（orders:read、orders:write），而非廣泛的資源層級存取，如此一來，受損權杖的影響範圍即可受到限制。在閘道依用戶端身分而非 IP 位址執行速率限制與配額政策，因為基於 IP 的限制在面對分散式流量及共用基礎架構的合法多租戶用戶端時會失效。Gartner 預測，隨著組織意識到 API 流量在多數企業環境中已超越傳統網路流量，API 安全工具與 API 閘道的支出將持續成長，而閘道層級的政策執行是實踐零信任且無需重寫每個服務的實用方式。

密鑰管理與憑證衛生

在原始碼儲存庫中硬編碼 API 金鑰與資料庫憑證，仍然是 API 外洩最常見且最可預防的原因之一。GitHub 的密鑰掃描計畫已在公開儲存庫中標記數百萬個暴露的憑證，其中有相當比例是開發者原本打算在推送前移除的生產環境 API 金鑰。

將密鑰儲存在專用保險庫（HashiCorp Vault、AWS Secrets Manager 或雲端供應商的同等服務）中，並在執行階段將其引入應用程式，而非將其嵌入已納入版本控制的設定檔或環境變數中。應依固定排程輪換 API 金鑰與簽章密鑰，並在團隊成員離職或事件顯示可能暴露時立即進行輪換。在架構允許的情況下，優先使用短期簽章權杖而非長期靜態金鑰，因為洩漏後數分鐘內即過期的權杖，造成的損害遠小於可無限期有效的金鑰。在 CI 管線中加入自動化密鑰掃描，使已提交的憑證在合併前即被阻擋，而非等到有人在生產環境中發現。

對工程團隊的啟示

這些威脅在概念上並不新穎。改變的是攻擊面。每個內部微服務、每個合作夥伴整合，以及產品所依賴的每個 AI 代理，都增加了攻擊者可探測的端點，而攻擊者用來尋找破損授權與洩漏憑證的工具，其速度已快過多數團隊的修補週期。應從撰寫第一個端點開始，就將 API 安全視為設計限制，而非上線前的檢查清單，並養成測試授權與密鑰衛生的習慣，就像測試功能一樣。

若團隊希望以結構化方式在整個工程組織中建立這些習慣，而非依賴個別開發者自行學習，應參考專門的 IT 安全培訓。