摘要： Cloudflare 於 2026 年 10 月 21 日宣布 WAF 新增兩項能力：full transaction detections 與 response rules。偵測不再只看進來的請求，而是把請求和它產生的回應放在一起評估，判斷攻擊是否真的成功，並在回應送達攻擊者前攔下。這兩項功能對所有方案開放，包括 Free plans。
為什麼只看請求不夠了
傳統 WAF 運作在請求層：managed rules 擋已知攻擊手法，custom rules 讓團隊用 IP、路徑、header 等條件自訂政策。問題在於，把每個可疑請求都當成確認的攻擊，會陷入兩難——簽名放寬會誤殺正常流量，簽名收紧又讓模糊流量溜進伺服器。
回應提供了缺少的證據。Cloudflare 在文中舉了一個目錄穿越的例子：攻擊者操縱檔案參數想讀取 ../../config/database.ini，請求本身無法確定應用程式是否真的外洩了檔案，但一個 200 OK 加上帶有帳號密碼的設定檔內容，就能和穿越嘗試互相印證，構成比單一訊號強得多的證據。
時機也有關係。Cloudflare 指出，最新的 frontier 模型正在挖掘廣泛使用軟體中深藏的漏洞，AI agent 掃描漏洞時可以持續調整 payload、串連漏洞與憑證。應用程式的回應會告訴攻擊者嘗試是否成功，這正是回應需要納入防線的原因。近期披露的 php2shell 漏洞就是第一波 managed 保護的目標。
偵測與攔截分開設計
這套能力延續 Cloudflare 今年稍早推出的 always-on 偵測框架：偵測器分析流量並附上 metadata，規則再決定怎麼處理。平台新增了三個回應端欄位——cf.waf.signature.response.confidence、cf.waf.signature.response.categories 和 cf.waf.signature.response.ref（最多 10 個簽名 ID）——付費客戶可以在 custom response rules 中結合這些欄位與 hostname、路徑、來源 IP 等參數。Cloudflare 表示回應欄位仍在逐步開放各帳號，還沒看到的要聯絡帳戶團隊。
分開的好處是先看清楚再動手：安全團隊可以在 Security Analytics 檢視偵測結果落在哪些端點，再決定政策。
Response rules 怎麼用
所有客戶可用 Cloudflare Managed Response Firewall Default ruleset 一鍵部署，簽名命中時以 WAF block page 取代原始回應，範圍可以調整成只涵蓋特定路徑。自訂方面，所有客戶最多能建三條 response custom rules，支援 Log 與 Block。Cloudflare 給了一個具體例子：
http.request.uri.path starts_with "/admin" and not http.request.headers["x-internal-user"][0] eq "true" and http.response.code eq 200 and http.response.headers["content-type"][0] contains "text/html"這條規則只在使用者未標記為內部、卻真的從 origin 拿到成功 HTML 管理頁時才擋，不會影響一般登入失敗或重新導向。要注意的限制：回應規則無法復原 origin 上已發生的動作，且目前尚不支援對回應本體建規則。命中事件可在 Security Events 追查到完整請求與規則上下文。
對開發者的意義
這個方向和我之前寫過的先蒐證、後推理的安全調查架構是同一種思路：先把證據結構化，再讓規則或人做決策。對獨立開發者和小團隊來說，最實際的一點是免費方案就能拿到完整的 managed transaction 偵測——不是每個產品都有專人調 WAF 規則。
下一步很簡單：如果你的網站已經走 Cloudflare 代理，到 Security > Security Rules 確認 managed 保護已開啟；想自訂的話，先在 Security Analytics 看偵測在你的流量裡長什麼樣，再寫回應端政策。Cloudflare 也說明覆蓋範圍會逐步擴大到資料外洩等訊號，初期重點仍放在高危漏洞的 exploit 確認。
參考來源
在 X 上查看原貼文