這個月我們已經聊了這麼多關於 Web 應用程式的具體漏洞和測試工具，我想延伸一個在當今架構下變得越來越核心，卻也常常被誤解的安全議題——API 安全 (API Security)。

我們可以說，如果傳統的網站安全是在保護「城堡的大門」，那麼 API 安全就是在保護城堡內部成千上萬個房間的「房門」以及它們之間的「秘密通道」。

為什麼 API 安全現在如此重要？

在過去，網站大多是「單體式應用 (Monolithic Application)」，也就是前端的 HTML 頁面和後端的業務邏輯是緊密耦合在一起的，由伺服器統一渲染後傳送給瀏覽器。

但現在的趨勢完全不同了：

• 前端後分離：現代網站普遍採用 SPA (單頁應用程式) 框架（如 React, Vue, Angular）。瀏覽器只載入一個前端的「殼」，然後透過呼叫 API 來動態地獲取或提交資料。
• 行動應用 (Mobile App)：你的手機 App 之所以能運作，幾乎完全依賴於與後端伺服器之間的 API 通訊。
• 微服務 (Microservices)：大型應用被拆分成數十甚至數百個獨立的「微服務」，這些服務之間也是透過 API 互相溝通。
• 物聯網 (IoT)：你家裡的智慧音箱、監視器等設備，同樣是透過 API 與雲端平台連接。

結論就是：API 已經成為了現代數位世界的「神經系統」。 過去被層層保護在後端的業務邏輯，現在都必須透過 API 端點 (Endpoints) 暴露出來。這意味著，攻擊面 (Attack Surface) 大大增加了，過去許多不存在的攻擊向量也隨之誕生。

API 安全的核心挑戰：從「會話」到「令牌」的轉變

傳統網站安全很多時候圍繞著 Cookie 和 Session 來做防護。但在 API 的世界裡，通訊往往是無狀態的 (Stateless)。客戶端（例如手機 App）在每一次請求中，都必須提供自己的身份證明。

這個「身份證明」通常就是 API 金鑰 (API Keys) 或更常見的 JWT (JSON Web Tokens)。這就帶來了新的安全問題：

• 這個 Token 是否安全地儲存在客戶端？
• Token 的簽名是否足夠強大，無法被偽造？
• Token 是否有過期時間？
• 當 Token 被竊取時，是否有撤銷機制？

OWASP API Security Top 10：最常見的 API 漏洞

就像 Web 應用有 OWASP Top 10 一樣，API 安全也有自己的一套十大風險。我挑選其中幾個最具代表性的來說明，你會發現它和傳統 Web 漏洞的思維有何不同。

API1:2023 - 授權機制失效 (Broken Object Level Authorization - BOLA)

這是最常見且最致命的 API 漏洞，沒有之一。它本質上是傳統 IDOR (不安全的直接物件引用) 漏洞在 API 中的體現。

• 核心問題：API 端點雖然驗證了使用者是否登入 (Authentication)，卻沒有驗證該使用者是否有權限操作其請求的物件 (Authorization)。

• 範例：
  假設有一個 API 端點可以獲取使用者的個人資料：
  GET /api/v1/users/{userId}/profile

  1. 你（合法使用者，ID 為 123）登入後，你的 App 會呼叫 GET /api/v1/users/123/profile 來獲取你自己的資料，這很正常。
  2. 但如果 API 的開發者忘了做權限檢查，一個好奇（或惡意）的你，可以直接在 Burp Suite 或 Postman 中，將請求的 URL 修改為 GET /api/v1/users/456/profile。
  3. 如果伺服器沒有驗證「發起請求的使用者（ID 123）是否有權限查看使用者 456 的資料」，它就會直接將使用者 456 的個人資料回傳給你。

  這類漏洞極其普遍，因為開發者很容易在業務邏輯中遺漏對每一個物件的存取權限檢查。

API5:2023 - 功能級別授權機制失效 (Broken Function Level Authorization - BFLA)

如果說 BOLA 是「你能否操作不屬於你的東西」，那麼 BFLA 就是「你能否執行不屬於你角色的動作」。

• 核心問題：API 沒有對不同的使用者角色（例如 普通使用者 vs 管理員）進行嚴格的功能級別權限區分。

• 範例：

  • 普通使用者可以訪問的 API 端點是：POST /api/posts/new (新增文章)
  • 管理員才能訪問的 API 端點是：DELETE /api/posts/{postId}/delete (刪除文章)

  一個攻擊者雖然是以普通使用者的身份登入，但他可以猜測或透過其他方式得知存在一個管理員的 API 端點。如果他直接嘗試呼叫 DELETE /api/posts/999/delete，而伺服器沒有在執行這個功能前，嚴格驗證呼叫者的角色是否為 admin，那麼這個刪除操作就會被成功執行。

API3:2023 - 物件屬性級別授權機制失效 (Broken Object Property Level Authorization)

這個漏洞更為細緻，它涉及到對物件內部屬性的存取控制。

• 核心問題：API 允許使用者修改或查看他們不應該有權限接觸的物件屬性。
• 常見成因：
  1. 過度暴露 (Excessive Data Exposure)：API 端點為了方便，一次性地將整個使用者物件（包含 password_hash, permission_level 等內部欄位）從資料庫中撈出來，然後直接序列化成 JSON 回傳給前端。即使前端介面沒有顯示這些敏感欄位，攻擊者也可以透過攔截 API 回應來看到所有資訊。
  2. 批量指派 (Mass Assignment)：當更新使用者資料時，開發者為了方便，可能會將使用者傳來的整個 JSON 物件直接對應到資料庫模型上進行更新。
     • 正常請求：PUT /api/users/me，Body: {"nickname": "New Name"}
     • 惡意請求：PUT /api/users/me，Body: {"nickname": "New Name", "is_admin": true}
       如果後端直接將整個 JSON 寫入資料庫，攻擊者就成功地把自己提升為管理員了。

所以呢：API 安全是新的防禦前線

API 的普及徹底改變了應用程式的架構，也改變了攻擊者的思維。防禦方不能再僅僅依賴於網路防火牆或 WAF，因為合法的 API 流量看起來都差不多。

安全必須左移 (Shift Left)，在 API 設計和開發的階段就融入安全思維：

• 預設拒絕：對每一個 API 端點，都要實施嚴格的認證與授權檢查。
• 最小權限原則：確保使用者和 API 金鑰只能存取其絕對必要的資源和功能。
• 永不信任客戶端：所有重要的業務邏輯和權限驗證，都必須在伺服器端強制執行。

API 安全是一個龐大且持續演進的領域，它要求開發者和資安人員都必須更新自己的知識庫，去理解這個由無數端點構成的、高度互聯的新戰場。