![[Screenshot 2026-05-02 at 2.13.48 PM.png]]

![[Screenshot 2026-05-02 at 2.15.34 PM.png]]

![[Screenshot 2026-05-02 at 2.17.39 PM.png]]

這是一份為您整理的專業中英雙語 Markdown 講義。內容已經過結構化設計，分為三大核心區塊，並使用表格與重點標示以提升易讀性與專業度。

The Three Pillars of API Security

API 安全的三大支柱

Overview / 總覽

Understanding vulnerabilities is only the first step; mitigating them requires a structured approach. The three pillars of API security are Governance, Monitoring, and Testing.

了解漏洞只是第一步；要有效降低風險，需要結構化的策略。API 安全的三大支柱分別為：治理 (Governance)、監控 (Monitoring) 與測試 (Testing)。

• Governance (治理): Establishing and enforcing standard, secure processes for API lifecycle management. (建立並執行 API 生命週期管理的標準化安全流程。)

• Monitoring (監控): Runtime protection to ensure APIs behave correctly and to detect attacks. (運行時的保護機制，確保 API 正常運作並偵測攻擊。)

• Testing (測試): Proactively verifying that APIs are free of vulnerabilities and exploitable flaws. (主動驗證 API 是否存在漏洞或可被利用的缺陷。)

Pillar 1: Governance / 第一支柱：治理

The primary goal of governance is consistency. It sets expectations for engineering teams regarding development, deployment, and documentation.

治理的主要目標是一致性。它為工程團隊在開發、部署與文件撰寫上設定了明確的期望。

Core Components / 核心要素

• Awareness (意識): Maintaining full visibility into your API inventory. You must know what APIs exist, their purpose, their owners, and the underlying infrastructure (containers, VMs, databases).

  意識： 保持對 API 資產清單的全面能見度。必須掌握現有 API、其用途、擁有者以及底層基礎架構 (容器、虛擬機、資料庫)。

• Policy & Process (政策與流程): Defining how APIs are developed and deployed. This prevents "shadow APIs" or "rogue APIs" from entering production without proper vetting.

  政策與流程： 定義 API 的開發與部署方式。這能防止未經適當審查的「影子 API」或「流氓 API」進入正式環境。

• API Gateway Enforcement (API 閘道器執行): Using a central control point to manage all APIs and validate traffic before deployment.

  API 閘道器執行： 使用中央控制點來管理所有 API，並在部署前驗證流量。

Documentation & Standards / 文件與標準

• Mandatory Documentation (強制文件化): Documentation (like OpenAPI/Swagger in YAML/JSON) must be auto-generated from code repositories to stay up-to-date. Public access to these specs should be strictly controlled.

  強制文件化： 文件 (如 YAML/JSON 格式的 OpenAPI/Swagger) 必須從程式碼庫自動生成以保持最新狀態。應嚴格控制這些規格文件的公開存取權限。

• API Style Guide (API 風格指南): A definitive organizational standard covering authentication, authorization, naming conventions (URLs as nouns, methods as verbs), and safe error codes (providing human-readable messages without leaking system details to attackers).

  API 風格指南： 組織的明確標準，涵蓋身分驗證、授權、命名慣例 (URL 為名詞，方法為動詞) 以及安全的錯誤碼 (提供易懂的訊息，但不向攻擊者洩露系統細節)。

Pillar 2: Monitoring / 第二支柱：監控

Monitoring focuses on runtime performance and security. It is critical but faces significant challenges due to the nature of API traffic.

監控著重於運行時的效能與安全。它雖然關鍵，但由於 API 流量的特性，也面臨著重大挑戰。

Three Buckets of Monitoring / 監控的三大區塊

Approaches to Monitoring / 監控的執行方式

• Proactive Blocking (主動阻擋): Using Web Application Firewalls (WAF) and Gateways to enforce rules (e.g., block invalid auth, rate limiting).

  主動阻擋： 使用網頁應用程式防火牆 (WAF) 與閘道器執行規則 (例如：阻擋無效驗證、流量限制)。

• Reactive Alerting (被動警報): Logging traffic into a SIEM or log management tool to retrace steps and adjust inline rules without accidentally blocking legitimate traffic.

  被動警報： 將流量日誌存入 SIEM 或日誌管理工具，以便回溯追蹤並調整即時規則，避免誤擋合法流量。

The Context Challenge (上下文的挑戰):

The biggest limitation of WAFs is context. An API attack often looks exactly like legitimate traffic (e.g., a valid user with valid credentials requesting a valid endpoint, but manipulating the ID to access someone else's data). WAFs cannot easily distinguish this in milliseconds.

(WAF 的最大限制在於「上下文」。API 攻擊通常看起來與合法流量完全相同 (例如：合法用戶使用合法憑證請求合法端點，但卻竄改 ID 以存取他人資料)。WAF 很難在毫秒內分辨出這種差異。)

Pillar 3: Testing / 第三支柱：測試

Despite its importance, API testing is severely neglected. Most teams only perform positive testing (does it work?), but security requires negative testing (can it be exploited?).

儘管 API 測試至關重要，卻常被嚴重忽視。多數團隊僅進行正面測試 (功能是否正常？)，但安全防護需要的是負面測試 (是否會遭惡意利用？)。

The Three Testing Categories / 測試的三大類別

The Four Approaches to API Testing / API 測試的四種途徑

• Option 1: Do Nothing (什麼都不做)

  Ignoring the problem. This leaves organizations highly vulnerable to attackers who actively target hidden APIs.

  忽視問題。這會讓組織面臨極高的風險，因為攻擊者正積極鎖定那些隱藏的 API。

• Option 2: Do It Yourself / DIY (自行測試)

  Using manual tools like Postman, Burp, or Zap. This requires significant time and high-level security expertise.

  使用 Postman、Burp 或 Zap 等手動工具。這需要耗費大量時間以及高階的安全專業知識。

• Option 3: Third-Party Pen Testing (第三方滲透測試)

  Hiring external teams. This is usually done only annually, misses frequent code updates, and rarely covers the entire API inventory.

  聘請外部團隊。通常每年僅執行一次，無法涵蓋頻繁的程式碼更新，且極少能測試到完整的 API 清單。

• Option 4: Automated Testing (自動化測試)

  Using tools (like APIsec) to auto-generate thousands of attack simulations. This allows for continuous testing that integrates directly into the CI/CD pipeline (Shift-Left).

  使用工具 (如 APIsec) 自動生成數以千計的攻擊模擬。這能實現持續測試，並直接整合至 CI/CD 流程中 (左移安全)。