OWASP API Security Top 10 完整指南：2023 版 API 安全漏洞與防護【2026 更新】

TL;DR

• OWASP API Security Top 10 是針對 API 的十大安全風險清單
• 2023 版仍是 2026 年的最新版本，OWASP 尚未發布更新版本
• API1 BOLA（物件層級授權失效）連續兩版蟬聯第一
• 2024-2025 年 API 攻擊事件持續增加，Dell、Trello、Roku 等大廠皆受害
• API 安全需要從設計階段就開始考量
• 結合 API Gateway 和程式碼層防護，才能有效保護 API

版本說明：本文介紹的 OWASP API Security Top 10 2023 版是截至 2026 年 2 月的最新正式版本。OWASP Web Application Top 10 已於 2025 年發布新版，但 API Security Top 10 維持 2023 版。兩份清單針對不同場景，應搭配使用。

---

為什麼 API 安全很重要？

API 已經成為現代應用的基礎。手機 App、網站前端、IoT 裝置、第三方整合，都透過 API 溝通。

根據統計，超過 80% 的網路流量來自 API 呼叫。API 承載的資料量和重要性，早已超越傳統網頁。

API 攻擊事件案例

近年重大 API 安全事件持續增加。根據統計，2024 年有 37% 的組織遭遇 API 安全事件，相比 2023 年的 17% 成長超過一倍。

2024-2025 年重大事件

2024 年 Dell 資料外洩（4,900 萬筆）

• 攻擊者透過合作夥伴入口網站的 API 漏洞存取客戶資料
• 缺乏 API 流量限制（Rate Limiting）和異常偵測機制
• 姓名、地址、購買紀錄全部外洩
• 漏洞類型：API4（無限制的資源消耗）+ API9（不當的資產管理）

2024 年 Trello 資料外洩（1,500 萬筆）

• 公開 REST API 端點無需認證即可查詢用戶資料
• 攻擊者用 5 億個 Email 比對，成功取得 1,500 萬筆用戶資料
• 包含 Email、姓名、帳號設定
• 漏洞類型：API2（認證機制失效）+ API1（BOLA）

2024 年 Twilio Authy 外洩（3,340 萬筆電話號碼）

• 未經認證的 API 端點暴露用戶電話號碼
• 可用於 SIM Swap 和釣魚攻擊
• 漏洞類型：API2（認證機制失效）

2024 年 GitHub API 金鑰外洩（1,300 萬組）

• 公開 Repository 暴露近 1,300 萬組 API 金鑰和密鑰
• 攻擊者可利用這些憑證存取第三方服務
• 漏洞類型：API8（安全設定錯誤）

2021-2023 年經典案例

2023 年 T-Mobile 事件

• API 漏洞暴露 3,700 萬客戶資料
• 姓名、Email、電話號碼、生日都被取得
• 這是 T-Mobile 第五次重大資料外洩事件

2022 年 Twitter 事件

• API 漏洞導致 540 萬用戶資料外洩
• 攻擊者可用 Email 或電話號碼查詢對應帳號

2021 年 Peloton 事件

• 任何人都能透過 API 取得其他用戶的私人資料
• 原因：缺乏物件層級授權檢查（BOLA）

這些事件的共通點：問題都出在 API 層，而非傳統網頁漏洞。95% 的組織在過去一年中經歷過 API 安全事件，但只有 7.5% 的組織有專門的 API 安全測試計畫。

API 安全 vs 網頁安全：有何不同？

面向	傳統網頁	API
攻擊面	有限的表單和連結	大量端點和參數
認證方式	Session Cookie	Token、API Key、OAuth
資料格式	HTML	JSON、XML
使用者	人類	程式、機器
流量模式	可預測	高頻、自動化
主要風險	XSS、CSRF	BOLA、認證失效

API 安全需要不同的思維和工具。這就是為什麼 OWASP 專門制定了 API Security Top 10。

想了解 OWASP 組織和其他安全專案，可以參考 OWASP 完整指南。

插圖：示意圖顯示多個裝置（手機、筆電、IoT 設備）透過箭頭連接到...

場景描述： 示意圖顯示多個裝置（手機、筆電、IoT 設備）透過箭頭連接到中央的 API 伺服器，伺服器周圍有盾牌圖示代表安全防護。背景是淺藍色網格。

視覺重點：

• 主要內容清晰呈現

必須出現的元素：

• 依據描述中的關鍵元素

需要顯示的中文字： 無

顏色調性： 專業、清晰

避免元素： 抽象圖形、齒輪、發光特效

Slug: api-security-architecture-diagram

---

OWASP API Security Top 10（2023 版）

2023 版是目前最新的 API 安全風險清單。以下逐項解析。

API1：Broken Object Level Authorization（BOLA）

中文：物件層級授權失效

風險說明： 攻擊者可以存取不屬於自己的資料物件。這是 API 最常見、最危險的漏洞。

攻擊情境：

正常請求：GET /api/users/123/orders
攻擊請求：GET /api/users/456/orders  ← 改別人的 ID

如果系統沒有驗證「使用者 123 能否存取使用者 456 的訂單」，就會發生 BOLA。

真實案例：

• 修改 URL 中的 ID 就能看到別人的訂單
• 變更請求中的 user_id 參數存取他人資料
• 透過 API 遍歷所有可能的 ID 值

防護措施：

1. 每個請求都驗證資源擁有權
2. 使用 UUID 取代遞增 ID
3. 實作集中式授權檢查機制
4. 記錄所有存取行為

// 錯誤示範
app.get('/api/orders/:orderId', async (req, res) => {
  const order = await Order.findById(req.params.orderId);
  res.json(order); // 沒有檢查擁有權
});

// 正確做法
app.get('/api/orders/:orderId', async (req, res) => {
  const order = await Order.findById(req.params.orderId);
  if (order.userId !== req.user.id) {
    return res.status(403).json({ error: 'Forbidden' });
  }
  res.json(order);
});

API 授權設計很頭痛？讓我們幫你規劃安全架構

API2：Broken Authentication

中文：認證機制失效

風險說明： API 的認證機制有漏洞，讓攻擊者可以冒充其他使用者。

常見問題：

• Token 沒有過期時間
• 弱密碼政策
• API Key 寫死在程式碼
• 認證繞過漏洞
• 暴力破解沒有防護

防護措施：

1. 使用標準認證協定（OAuth 2.0、OpenID Connect）
2. 實作 Token 過期和刷新機制
3. 多因素認證（MFA）
4. 登入失敗次數限制
5. 安全儲存憑證（加鹽雜湊）

API3：Broken Object Property Level Authorization

中文：物件屬性層級授權失效

風險說明： 使用者可以讀取或修改不該存取的物件屬性。

攻擊情境：

// 使用者更新個人資料
PUT /api/users/123
{
  "name": "John",
  "email": "[email protected]",
  "role": "admin"  ← 偷偷加入這個欄位
}

如果後端沒有過濾，使用者就能把自己改成管理員。

兩種子類型：

• Excessive Data Exposure：API 回傳過多資料
• Mass Assignment：API 接受過多輸入欄位

防護措施：

1. 明確定義可讀取/可修改的欄位
2. 使用 DTO（Data Transfer Object）模式
3. 回應只包含必要欄位
4. 伺服器端過濾敏感屬性

API4：Unrestricted Resource Consumption

中文：無限制的資源消耗

風險說明： API 沒有限制請求數量或資源使用，可能導致服務癱瘓或成本暴增。

攻擊方式：

• 大量請求導致 DoS
• 請求巨大檔案上傳
• 批次操作處理過多項目
• 複雜查詢消耗運算資源

防護措施：

1. 實作 Rate Limiting
2. 限制 Payload 大小
3. 分頁和結果數量上限
4. 查詢複雜度限制
5. 資源配額管理

// Rate Limiting 範例
const rateLimit = require('express-rate-limit');

const limiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 分鐘
  max: 100, // 最多 100 次請求
  message: 'Too many requests'
});

app.use('/api/', limiter);

API5：Broken Function Level Authorization

中文：功能層級授權失效

風險說明： 一般使用者可以存取管理員功能或其他角色的 API。

攻擊情境：

一般使用者 API：GET /api/users/me
管理員 API：GET /api/admin/users  ← 直接呼叫

如果沒有驗證角色，任何人都能使用管理功能。

防護措施：

1. 預設拒絕所有存取
2. 明確的角色權限對應
3. 集中式權限管理
4. 定期審查 API 權限設定

API6：Unrestricted Access to Sensitive Business Flows

中文：敏感商業流程的無限制存取

風險說明： 攻擊者自動化執行敏感業務操作，造成商業損害。

攻擊情境：

• 自動搶購限量商品
• 批次註冊假帳號
• 自動化搶票
• 濫用推薦獎勵

防護措施：

1. 識別敏感業務流程
2. 加入人機驗證（CAPTCHA）
3. 裝置指紋識別
4. 行為分析偵測異常
5. 業務邏輯的頻率限制

API7：Server Side Request Forgery（SSRF）

中文：伺服器端請求偽造

風險說明： 攻擊者讓伺服器發送請求到非預期的目標。

攻擊情境：

POST /api/fetch-url
{
  "url": "http://169.254.169.254/latest/meta-data/"
}

如果 API 會去取得使用者提供的 URL，攻擊者可能存取內部服務或雲端 Metadata。

這個漏洞也出現在 OWASP Top 10 的 A10 項目。

防護措施：

1. URL 白名單驗證
2. 禁止存取內部 IP 範圍
3. 禁止非必要的 Protocol
4. 使用專用的網路區段

API8：Security Misconfiguration

中文：安全設定錯誤

風險說明： API 的安全設定不當，暴露不必要的攻擊面。

常見問題：

• 詳細錯誤訊息暴露系統資訊
• 沒有關閉 Debug 模式
• 預設帳密沒改
• 不必要的 HTTP Method 開啟
• CORS 設定過寬
• 缺少安全 Header

防護措施：

1. 標準化部署流程
2. 定期安全組態審查
3. 自動化安全檢測
4. 最小權限原則

API9：Improper Inventory Management

中文：不當的資產管理

風險說明： 組織不清楚自己有哪些 API，或存在被遺忘的舊版 API。

常見問題：

• 舊版 API 沒有下線
• 測試環境 API 暴露在外
• 沒有 API 文件
• 不知道哪些 API 處理敏感資料

防護措施：

1. 維護 API 清單
2. 版本管理策略
3. 定期盤點和清理
4. 統一的 API Gateway

API10：Unsafe Consumption of APIs

中文：不安全的 API 使用

風險說明： 你的應用程式信任並使用第三方 API，但沒有做好防護。

風險情境：

• 沒有驗證第三方回應
• 沒有處理第三方錯誤
• 跟隨第三方的重導向
• 沒有設定 Timeout

防護措施：

1. 驗證所有外部輸入
2. 使用 HTTPS
3. 設定合理的 Timeout
4. 限制重導向次數
5. 監控第三方 API 狀態

插圖：表格形式整理 OWASP API Top 10 十項風險，左...

場景描述： 表格形式整理 OWASP API Top 10 十項風險，左欄為編號和英文名稱，右欄為中文說明和風險等級標示（紅色高風險、橙色中風險）。白色背景搭配深色文字。

視覺重點：

• 主要內容清晰呈現

必須出現的元素：

• 依據描述中的關鍵元素

需要顯示的中文字： 無

顏色調性： 專業、清晰

避免元素： 抽象圖形、齒輪、發光特效

Slug: owasp-api-top-10-summary-table

---

API 安全測試方法

知道風險後，下一步是測試。

自動化掃描工具

常用的 API 安全掃描工具：

工具	類型	特點
OWASP ZAP	免費開源	支援 OpenAPI 匯入
Burp Suite	商業	功能強大、學習曲線高
Postman	免費/商業	易用、支援安全測試
42Crunch	商業	API 專門、CI/CD 整合好
Wallarm	商業	即時防護 + 掃描

使用 ZAP 進行 API 掃描的詳細教學，可以參考 OWASP ZAP 教學。

手動測試技巧

自動化工具無法取代手動測試。以下是重點測試項目：

BOLA 測試：

1. 登入帳號 A
2. 記錄帳號 A 的資源 ID
3. 登入帳號 B
4. 嘗試用帳號 B 存取帳號 A 的資源

認證測試：

1. 使用過期 Token
2. 使用錯誤格式 Token
3. 不帶 Token 存取需認證 API
4. 暴力破解測試

授權測試：

1. 一般使用者呼叫管理員 API
2. 修改請求中的角色欄位
3. 嘗試水平和垂直權限提升

Postman 安全測試

Postman 是 API 開發者常用的工具，也可以做安全測試。

設定測試腳本：

// 檢查回應不包含敏感資訊
pm.test("No sensitive data in response", function () {
    pm.expect(pm.response.text()).to.not.include("password");
    pm.expect(pm.response.text()).to.not.include("secret");
});

// 檢查必要的安全 Header
pm.test("Security headers present", function () {
    pm.response.to.have.header("X-Content-Type-Options");
    pm.response.to.have.header("X-Frame-Options");
});

// 檢查回應時間
pm.test("Response time acceptable", function () {
    pm.expect(pm.response.responseTime).to.be.below(2000);
});

---

API 安全最佳實務

認證與授權設計

使用 OAuth 2.0 + OpenID Connect：

• Access Token 處理授權
• ID Token 處理認證
• Refresh Token 延長會話

Token 最佳實務：

• 使用短期 Access Token（15-60 分鐘）
• Refresh Token 需要安全儲存
• 支援 Token 撤銷機制
• 使用 JWT 時驗證簽章和有效期

Rate Limiting 實作

不同層級的限制：

全域限制：每 IP 每分鐘 1000 次
API 限制：每用戶每分鐘 100 次
端點限制：登入 API 每 IP 每分鐘 5 次

回應 Header 標示：

X-RateLimit-Limit: 100
X-RateLimit-Remaining: 45
X-RateLimit-Reset: 1640000000

Input Validation

驗證所有輸入：

• 資料類型
• 長度限制
• 格式驗證（Email、電話）
• 白名單字元
• 業務邏輯限制

const Joi = require('joi');

const userSchema = Joi.object({
  name: Joi.string().min(2).max(50).required(),
  email: Joi.string().email().required(),
  age: Joi.number().integer().min(0).max(150),
  role: Joi.string().valid('user', 'moderator')  // 不允許 admin
});

---

API Gateway 安全設定

API Gateway 是 API 安全的第一道防線。

AWS API Gateway

安全功能：

• IAM 認證
• Lambda Authorizer
• API Key 管理
• 流量限制
• WAF 整合

設定建議：

# 啟用 CloudWatch 日誌
x-amazon-apigateway-policy:
  Version: "2012-10-17"
  Statement:
    - Effect: Allow
      Action: execute-api:Invoke
      Resource: "arn:aws:execute-api:*:*:*"
      Condition:
        IpAddress:
          aws:SourceIp: "203.0.113.0/24"

GCP Cloud Endpoints

安全功能：

• Cloud IAM
• API Key 驗證
• Service Account 認證
• Cloud Armor 整合

Azure API Management

安全功能：

• Azure AD 整合
• 憑證驗證
• IP 限制
• Rate Limiting Policy
• Request/Response 轉換

三大雲比較：

功能	AWS	GCP	Azure
原生認證	IAM	Cloud IAM	Azure AD
WAF 整合	AWS WAF	Cloud Armor	Azure WAF
價格模式	按請求	按請求	按單位
學習曲線	中等	中等	偏高

雲端 API Gateway 怎麼選？預約免費架構諮詢

---

常見問題 FAQ

Q1：REST API 和 GraphQL API 的安全差異？

REST API：

• 固定的端點和回應結構
• 容易做存取控制
• 較成熟的安全工具支援

GraphQL API：

• 單一端點，彈性查詢
• 需要額外的查詢深度限制
• 容易發生資訊過度暴露
• 需要欄位層級的權限控制

GraphQL 需要特別注意：

• 查詢複雜度限制
• Introspection 在正式環境應關閉
• Batching Attack 防護

Q2：API Key 夠安全嗎？

API Key 的問題：

• 無法識別使用者身份
• 容易外洩（寫在程式碼、Log 中）
• 無法細粒度控制權限
• 難以追蹤濫用

適用場景：

• 公開 API 的基本識別
• 低敏感度的服務呼叫
• 搭配其他認證機制使用

不適用場景：

• 存取使用者資料
• 敏感操作
• 需要追蹤使用者行為

建議使用 OAuth 2.0 搭配 JWT，而非單純 API Key。

Q3：如何保護內部 API？

內部 API 常被忽略，但同樣重要。

保護措施：

1. 網路層：使用 VPC、Private Subnet
2. 認證：Service-to-Service 認證（mTLS、Service Account）
3. 授權：Zero Trust 架構，不信任內部流量
4. 監控：記錄所有內部 API 呼叫
5. 文件：維護內部 API 清單

「內部就是安全」的假設是危險的。資安事件中，橫向移動攻擊常常利用內部 API 缺乏防護的弱點。

---

結論

API 安全不是選配，是必備。

OWASP API Security Top 10 提供了清楚的風險清單和防護方向。重點回顧：

1. BOLA 是頭號風險：每個 API 都要檢查物件擁有權
2. 認證授權要分開：驗證身份和檢查權限是兩件事
3. 輸入永遠不可信：驗證、過濾、限制
4. 善用 API Gateway：集中處理安全邏輯
5. 持續測試監控：安全不是一次性工作

下一步建議：

• 盤點你的 API 清單
• 用 OWASP API Top 10 做自我檢核
• 在 CI/CD 加入 API 安全測試
• 定期進行人工滲透測試

想了解 AI 時代的新興 API 安全議題，可以參考 OWASP LLM Top 10。如果你的 API 服務行動裝置，也別忘了參考 OWASP Mobile 與 IoT 安全。

插圖：流程圖展示 API 安全生命週期，從左到右依序為：設計（安全...

場景描述： 流程圖展示 API 安全生命週期，從左到右依序為：設計（安全架構）、開發（安全編碼）、測試（弱點掃描）、部署（安全設定）、監控（異常偵測），各階段用箭頭連接，形成循環。藍綠色調設計。

視覺重點：

• 主要內容清晰呈現

必須出現的元素：

• 依據描述中的關鍵元素

需要顯示的中文字： 無

顏色調性： 專業、清晰

避免元素： 抽象圖形、齒輪、發光特效

Slug: api-security-lifecycle-flowchart

預約架構設計諮詢，打造安全的 API 架構