傳統上，安全防護是一場防禦遊戲。企業建造城牆、設定大門、撰寫規則來封鎖看起來可疑的流量。多年來，Cloudflare 一直是這個領域的領導者：我們的應用程式安全平台專為攔截進行中的攻擊而設計，在惡意請求到達源站之前將其攔截。但對於 API 安全而言，僅僅依靠防禦是不夠的。
因此，今天我們宣佈推出 Cloudflare 的 Web and API Vulnerability Scanner 測試版。
我們將從 OWASP API Top 10 中最普遍、也最難捕捉的威脅開始：物件層級授權失效 (BOLA)。隨著時間推移，我們將會增加更多漏洞掃描類型，包括 API 與 Web 應用程式的威脅。
現今最危險的 API 漏洞，並非 WAF 容易發現的通用插入攻擊或格式錯誤的請求，而是邏輯缺陷——完全符合通訊協定和應用程式規範的有效 HTTP 請求，但卻違反了業務邏輯。
要找出這些漏洞，您不能只是被動等待攻擊發生。您必須主動出擊，搜尋它們。
Web and API Vulnerability Scanner 將首先提供給 API Shield 的客戶。請繼續閱讀，瞭解我們為何在首發版本中專注於 API 安全掃描。
在 Web 應用程式領域，漏洞通常看起來像是語法錯誤。SQL 資料隱碼攻擊看起來像是將程式碼插入到應該放置資料的位置。Cross-site scripting (XSS) 攻擊看起來像是表單欄位中的指令碼標籤。這些都有特徵。
API 漏洞則不同。舉例來說，想像一個完全依賴後端 API 溝通的餐點外送手機應用程式。以訂單端點為例：
端點定義：/api/v1/orders
方式 | 資源路徑 | 描述 |
GET | /api/v1/orders/{order_id} | 查詢狀態。回傳特定訂單的追蹤狀態（例如「廚房正在準備中」）。 |
PATCH | /api/v1/orders/{order_id} | 更新訂單。允許使用者修改外送地點或新增送達指示。 |
在像 BOLA 這樣的授權失效攻擊中，使用者 A（攻擊者）請求更新屬於使用者 B（受害者）的已付款訂單的外送地址。攻擊者只需在 PATCH 請求中插入使用者 B 的 {order_id} 即可。
以下是該請求的樣貌，其中 8821 是使用者 B 的訂單 ID。請注意，使用者 A 已使用自己有效的權杖完整通過了驗證：
PATCH /api/v1/orders/8821 HTTP/1.1
Host: api.example.com
Authorization: Bearer <User_A_Valid_Token>
Content-Type: application/json
{
"delivery_address": "123 Attacker Way, Apt 4",
"instructions": "Leave at front door, ring bell"
}
請求標頭是有效的。驗證權杖是有效的。架構是正確的。對標準的 WAF 來說，這個請求看起來完美無瑕。如果是手動傳送攻擊請求，甚至可能騙過機器人管理方案。
使用者 A 現在將收到 B 的餐點！此漏洞的存在，是因為 API 端點未能驗證使用者 A 實際上是否有權限檢視或更新使用者 B 的資料。這是邏輯的失誤，而非語法錯誤。要修復這個問題，API 開發人員可以實作一個簡單的檢查：if (order.userID != user.ID) throw Unauthorized;
您可以透過主動傳送 API 測試流量或被動監聽現有 API 流量來偵測這類漏洞。透過被動掃描來發現這些漏洞需要情境脈絡。去年我們為 API Shield 推出了 BOLA 漏洞偵測功能。該功能透過被動掃描客戶流量中的使用異常，來自動發現這些漏洞。要成功進行這類掃描，您需要知道什麼是「有效的」API 呼叫、可變參數有哪些、典型使用者的行為方式，以及當這些參數被竄改時 API 會如何反應。
然而，即便可以使用 API Shield 的 BOLA 漏洞偵測功能，安全團隊仍可能因為某些原因而缺乏這些情境脈絡。例如，開發環境可能需要測試，但缺乏使用者流量；正式環境可能（很幸運地）缺乏攻擊流量，但卻仍需要進行分析，諸如此類。在這些情況下，並且為了達到整體的主動防禦，團隊可以轉向動態應用程式安全測試 (DAST)。透過建立專為安全測試設計的全新流量特徵，DAST 工具可以隨時在任何環境中尋找漏洞。
遺憾的是，傳統的 DAST 工具進入門檻很高。它們通常難以設定、需要您手動上傳與維護 Swagger/OpenAPI 檔案、難以正確地針對現代複雜的登入流程進行驗證，而且可能根本缺乏任何 API 專屬的安全測試（例如 BOLA）。
在上述餐點外送的範例中，我們假設攻擊者能夠找到一個有效的訂單來修改。雖然攻擊者在真實的正式環境中，通常有管道可以收集這類情報，但在安全測試演練中，您必須在測試 API 的授權控制機制之前，先建立自己的物件。對於典型的 DAST 掃描來說，這可能是個問題，因為許多掃描器是將每個個別請求獨立處理。這種方法無法將請求按照必要的邏輯模式連結起來，導致無法發現授權漏洞。傳統的 DAST 掃描器也可能在您的安全工具和協調環境中孤立存在，導致其發現的結果無法被共用或在適當的脈絡下被檢視。
Cloudflare 的漏洞掃描之所以與眾不同，有幾個關鍵原因。
首先，安全性見解會將我們新掃描的結果與任何現有的 Cloudflare 安全性發現並列顯示，以便提供更多背景資訊。您可以在一個地方查看所有安全狀態管理資訊。
其次，我們已經知道您的 API 的輸入與輸出。如果您是 API Shield 客戶，Cloudflare 已經瞭解您的 API。我們的 API 發現和結構描述學習功能會被動地對您的端點進行編目，並學習您的流量模式。雖然在初始版本中您需要手動上傳 OpenAPI 規範才能開始使用，但在未來的版本中，您無需上傳即可快速上手。
第三，由於我們處於網路邊緣，我們可以將被動流量偵測資訊轉化為主動情報。透過使用漏洞掃描器傳送全新的 HTTP 請求，您可以輕鬆驗證透過流量偵測發現的 BOLA 漏洞風險。
最後，我們建構了一個全新的具狀態 DAST 平台，我們將在下文對此進行詳述。大多數掃描器需要數小時的設定才能「教會」工具如何與您的 API 通訊。而使用 Cloudflare，您可以有效地跳過這一步驟並快速上手。您只需提供 API 認證，我們將使用您的 API 結構描述自動建立掃描計畫。
API 通常使用 OpenAPI 結構描述進行文件化。這些模式定義了主機、方法和路徑（通常稱為「端點」），以及傳入請求和回應的預期參數。為了自動建立掃描計畫，我們首先必須理解待掃描 API 的這些 API 規格。
我們掃描器的運作方式是，從 OpenAPI 文件建立一個 API 呼叫圖，然後使用攻擊者和擁有者上下文來遍歷該圖。擁有者建立資源，攻擊者隨後嘗試存取這些資源。攻擊者使用其自身的一組有效認證進行完全身分驗證。如果攻擊者成功讀取、修改或刪除了一個非其擁有的資源，則表示存在授權漏洞。
考慮前面提到的訂單 ID 為 8821 的外送訂單。為了讓伺服器端資源存在，它最初必須由擁有者建立，很可能是透過一個沒有任何或僅有極少依賴關係（即先前必要的呼叫與產生的資料）的「初始」POST 請求建立。將 API 建模為一個呼叫圖時，這樣的端點構成了一個沒有或只有少數傳入邊（即依賴關係）的節點。任何後續的請求，例如上面攻擊者傳送的 PATCH 請求，都會對初始請求 (POST) 具有資料依賴性（資料即為 order_id）。若未提供所有資料，PATCH 請求將無法進行。
圖中紫色箭頭所示為透過 POST /api/v1/orders/{order_id}/note/{note_id} 端點向訂單新增備註所需造訪的 API 圖節點。需要注意的是，圖中所示的任何步驟或邏輯在 OpenAPI 規格中均未提供！必須透過其他方式進行邏輯推斷，而這正是我們的漏洞掃描器將自動執行的操作。
為了在各種 API 上可靠且自動地規劃掃描，我們必須從零開始準確建模這些端點關係。然而，這衍生出兩個問題：API 規格的資料品質無法保證，且即使功能完整的結構描述也可能存在模糊的命名規則。考慮上述 API 的簡化版 OpenAPI 規格，它可能長這樣：
openapi: 3.0.0
info:
title: Order API
version: 1.0.0
paths:
/api/v1/orders:
post:
summary: Create an order
requestBody:
required: true
content:
application/json:
schema:
type: object
properties:
product:
type: string
count:
type: integer
required:
- product
- count
responses:
'201':
description: Item created successfully
content:
application/json:
schema:
type: object
properties:
result:
type: object
properties:
id:
type: integer
created_at:
type: integer
errors:
type: array
items:
type: string
/api/v1/orders/{order_id}:
patch:
summary: Modify an order by ID
parameters:
- name: order_id
in: path
我們可以看到 POST 端點傳回的回應如下：
{
"result": {
"id": 8821,
"created_at": 1741476777
},
"errors": []
}
對於人類觀察者來說，很快就能看出 $.result.id 就是要插入到 PATCH 端點之 order_id 的值。然而，id 屬性也可能被命名為 orderId、value 或其他名稱，且可能被任意嵌套。對於基於啟發式的方法來說，這些任意形狀的 OpenAPI 文件中的細微不一致性是難以解決的。
我們的掃描器利用 Cloudflare 自家的 Workers AI 平台來解決這個模糊的問題空間。像 OpenAI 開放權重的 gpt-oss-120b 之類的模型，其能力足以可靠地比對資料依賴關係，並在必要時產生逼真的假資料，基本上填補了 OpenAPI 規格中的空白。此模型利用結構化輸出，產生 API 呼叫圖的表示，供我們的掃描器遍歷，並相應地插入攻擊者和擁有者的認證。
這種方法解決了需要人類智慧來推斷 OpenAPI 結構描述中授權與資料關係的問題，現在改由人工智慧來執行相同任務。結構化輸出彌補了從 gpt-oss 的自然語言世界回到機器可執行指令之間的鴻溝。除了 Workers AI 解決了規劃問題外，在 Workers AI 上自我託管也意味著我們的系統能自動受益於 Cloudflare 高可用性、全球分佈的架構。
要建立一個能讓客戶放心交出 API 認證的漏洞掃描器，需要經過驗證的基礎架構。我們並沒有另起爐灶，而是整合了已在 Cloudflare 內部驗證並部署的服務，用於我們掃描器平台的兩個關鍵元件：掃描器的控制平面與掃描器的機密儲存庫。
掃描器的控制平面整合了 Temporal 進行掃描協調，Cloudflare 的其他內部服務早已依賴此框架。每次掃描中執行的眾多測試計畫之複雜性，均由 Temporal 的持久執行框架有效管理。
整個後端使用 Rust 編寫，這在 Cloudflare 的基礎架構服務中已被廣泛採用。這使我們能重用內部函式庫，並在團隊間共用架構模式。這也為掃描器未來與其他 Cloudflare 系統（如 FL2 或我們的測試框架 Flamingo）進行整合鋪平了道路，從而實現掃描與邊緣請求處理或測試基礎架構更緊密的協作。
透過 HashiCorp 的 Vault Transit Secret Engine 提供認證安全性
掃描驗證失效與授權失效漏洞，需要處理 API 使用者認證。Cloudflare 非常重視這項責任。
我們利用 HashiCorp 的 Vault Transit Secret Engine (TSE) 作為加密即服務，確保我們的公開 API 層僅能存取最小限度的未加密客戶認證。認證在提交後會立即由 TSE 加密（TSE 負責加密，但不儲存密文），隨後儲存於 Cloudflare 的基礎架構中。
我們的 API 並未被授權解密這些資料。解密僅發生在最後階段，也就是當 TestPlan 向客戶的基礎架構發出請求時。只有執行測試的 Worker 才有權請求解密，我們還利用 Rust 的嚴格型別與額外的安全防護機制來強化此限制，以強制執行對解密方法的最低限度存取。
我們進一步透過使用 TSE 定期輪換與週期性地重新封裝來降低風險，確保客戶的認證安全。這個過程意味著我們只與新的密文互動，而原始的金鑰始終保持不可見。
我們即日起針對所有 API Shield 客戶推出 BOLA 漏洞掃描的開放測試版，並正在開發未來版本中將要發佈的 API 威脅掃描功能。透過 Cloudflare API，您可以觸發掃描、管理組態並以程式化方式擷取結果以便直接整合到你的 CI/CD 流程或安全儀表板中。API Shield 客戶可查閱開發人員文件，立即開始掃描您的端點是否有 BOLA 漏洞。
我們從 BOLA 漏洞著手，因為它們是最難解決且對客戶風險最高的 API 漏洞。然而，此掃描引擎的設計具有可擴展性。
在不久的將來，我們計劃將掃描器的能力擴展至涵蓋 OWASP Web Top 10 中最熱門的項目，例如 SQL 資料隱碼攻擊 (SQLi) 與 Cross-site scripting (XSS) 等經典 Web 漏洞。如需在發佈時收到通知，請在此處註冊加入等候名單，當我們將引擎擴展到一般 Web 應用程式漏洞時，您將第一時間收到消息。