Cloudflare 於二零二六年九月二十九日在官方網誌宣布推出 Application Profiles（應用輪廓），把「正則資安」（positive security）從 API Schema 學習延伸到一般 Web 應用：系統先觀察合法請求的結構與欄位格式，再標記偏離輪廓的流量，讓資安團隊以 Security Rules 決定觀察或攔截。同日「AI 時代自適應應用資安」框架文亦交代發現風險、治理代理、執行期防護與調查回應四個閉環階段。來源真實性已驗證：對照 Cloudflare 官方 Application Profiles 專文與 AI-era framework 專文（兩篇均 HTTP 200），未採信未經官方證實的二手數字。

對香港與亞洲企業而言，重點不在再多一條特徵碼，而在用自家生產流量定義「甚麼叫正常」，以縮小零日與大型語言模型突變攻擊的可操作面。本文梳理機制、技術原理、日常場景、限制與落地考量。

Cloudflare／官方：推出 Application Profiles——以合法流量結構學習正則資安；企業封閉測試開放

引言

傳統 WAF 多靠特徵與機器學習分數抓「像攻擊」的請求；面對可連續試探、即時改寫 payload 的代理式攻擊，單靠「更快打補丁」愈來愈不夠。Cloudflare 提出的對策是：先學會你的應用期望甚麼輸入，再把不合輪廓的請求變成可分析、可規則化的訊號。來源真實性已驗證如上；下文只陳述官方公開機制與適用範圍，不臆測未公布的定價或全面上市時間。

一、核心事件：Application Profiles 做甚麼

技術細節

官方說明，Application Profiles（文中亦稱 Application Schema Profiles）會定期從觀測流量學習預期的 HTTP 請求結構，並在學習完成後自動掛上常駐驗證層。驗證結果會寫入請求中繼資料，本身不會直接阻斷；客戶可在 Security Analytics 回看，再以 Security Rules 對不合規請求採取行動。沒有輪廓的操作不會被此功能分類。

可學習內容視流量而定，涵蓋路徑變數、查詢參數、標頭與 Cookie，以及 JSON 或 form-encoded 的 body 結構。對每個欄位，系統可學習資料類型（整數、字串、布林、陣列、UUID 或短列舉）與約束（數值範圍、字串長度、字元類別等）。列舉目前最多支援三個值。

學習以「操作」（operation）為單位：由 HTTP 方法、主機名模式與路徑模式識別，並在 Web Assets > Operations 管理。對自動發現的操作，客戶須主動選「Learn profile」才會開始學習；手動建立的操作在建立時可觸發學習。學習按區域每週自動跑一次，使用最近成功流量：過去七日至少一千個 2xx 回應才學欄位，至少一萬個才學邊界。官方提醒成功流量可能含機械人與掃描器，強制執行前應人工覆核。

產品狀態方面：已有 API Security 的客戶可把此能力視為 Schema Learning／Schema Validation 的延伸而使用；未有 API Security 的企業客戶則以邀請制封閉測試（closed beta）開放，官方並寫明邀請不代表未來方案可用性。暫不支援 multipart 表單、GraphQL 與 XML。

同日框架文把應用資安收成四個連續階段：發現並排序風險、治理存取與代理行為、執行期防護，以及調查、回應與學習；Application Profiles 落在「以正則模型收窄攻擊面」的執行期一層，並與 Attack Score、Bot 分數、Threat Events 等訊號可在同一規則中組合。

二、技術原理深度解析

正則資安的核心假設是：多數經典攻擊（SQL 注入、跨站腳本、遠端程式碼執行等）會讓某個參數離開「正常型別／範圍／字元集」。若搜尋框只應接受英數，拒絕特殊字元即可砍掉一大片已知攻擊庫，而不必等該 CVE 的特徵碼。

與 Managed Rules「必須像已知攻擊」不同，輪廓驗證關心的是「是否符合已學習的期望」。例如路徑中的 UUID、查詢參數 product_id 應為整數且落在邊界內；一旦出現字串或畸形 UUID，即可標記違規。官方亦提供違規位置欄位（如 query／path／headers／cookies／body 的 violated_parameters）與未宣告參數欄位，方便只對高風險欄位強制、或在新版本上線時暫時容忍新增參數。

學習結果可在控制台檢視，並匯出為 OpenAPI v3；亦可下載後再上傳至 Schema Validation 以固定版本。官方建議先以觀察模式理解影響，再決定全域或按路徑／操作／欄位落地攔截。後續路線圖包括按需觸發學習、排除自動化流量，以及用模型對輪廓做語意脈絡化，協助排序高風險操作（例如異常資料外傳、偵察型未知參數、高流量業務關鍵路徑）。

四、日常應用場景

1. 開發者與技術團隊

把「新參數、新路徑」從沉默失敗變成可觀測訊號：發版後若 Profile Analysis 顯示不合規暴增，可先分辦是合法客戶端升級還是探測流量。匯出的 OpenAPI 亦可回饋給合約測試與閘道設定，縮短文件與線上行為落差。

2. 企業與隱私敏感行業

金融、醫療、法律等行業往往已有 API 合約，但 Web 表單與舊式後台仍靠黑名單規則硬撐。Application Profiles 讓 Web 與 API 共用「先定義好輸入」的紀律，並可與身份、Bot、Attack Score 疊加，減少單一控制失效時的盲區——這正是官方框架文引用代理式攻擊案例時強調的「重疊且獨立的控制」。

3. 一般用戶

終端用戶通常不會直接看到輪廓名稱；體感是異常請求更早在邊緣被擋下，正常瀏覽與結帳路徑若設計穩定，不應被誤傷。若商戶剛上新活動參數卻立即全站攔截，則可能造成誤阻——故官方強調觀察期與分階段規則。

4. 香港與亞洲市場視角

本港零售、物流與金融科技站點流量波動大、季節性活動多，正則輪廓若欠人工覆核，容易把「大促新參數」當成攻擊。較穩妥做法是：先對登入、轉帳、重置密碼等少量高風險操作啟用學習與觀察，再擴展到目錄與搜尋。若團隊同時評估私有模型與零信任邊緣，可把「請求是否合規」納入營運儀表，而不是只堆特徵碼。需要在香港落地雲端遷移與網絡安全架構時，亦可參考 YSK Limited 的雲端遷移與網絡安全服務（官網刊 99.99% 高可用）：https://ysk.hk/services/cloud-security

五、專業評價與潛在考量

優勢

• 把正則資安從 API 擴到 Web，對應「LLM 可連續突變 payload」的現實，不單靠披露後的特徵更新。
• 驗證結果是可組合的請求欄位，便於與現有 Bot／Attack Score／業務規則一起寫 Security Rules。
• 學習門檻與 OpenAPI 匯出清楚，利於稽核與版本固定。

需要留意的地方

• 目前對無 API Security 客戶屬邀請制封閉測試，全面供應與方案包裝仍以官方後續公布為準。
• 學習依賴「看起來成功」的 2xx 流量，可能吸入掃描器行為；強制前必須覆核。
• 尚未覆蓋 multipart、GraphQL、XML；參數重複時驗證各值但不強制唯一，也不會只因出現新參數就單獨攔截。
• 不合規≠惡意：發版、新客戶端、罕見但合法請求都會觸發，觀察模式是必要緩衝。
• 同日框架文談及的其他能力（例如威脅情報擴大開放、代理式資安營運等）進度不一，撰文時應分開核對，避免把路線圖當成已上線功能。

結語

Application Profiles 的訊息很務實：在代理與大型語言模型降低攻擊門檻之後，防守方要用生產流量自己定義合法邊界，並把偏離變成可營運的訊號。對香港企業，價值在於先守住少數高風險操作的輸入契約，再逐步擴大，而不是一夜之間全站改為攔截。若你正評估邊緣 WAF、零信任與雲端高可用一體化，可進一步了解 YSK Limited 雲端遷移與網絡安全：https://ysk.hk/services/cloud-security

參考來源

1. Cloudflare Blog,《Enforce positive security with Cloudflare Application Profiles》（2026-09-29）https://blog.cloudflare.com/application-profiles/
2. Cloudflare Blog,《Adaptive application security for the AI era: how Cloudflare connects code, traffic, and intelligence to stop attacks》（2026-09-29）https://blog.cloudflare.com/ai-era-framework/