WAF 是什麼？Web Application Firewall 與弱點掃描、DAST、IPS 的差異及部署完整指南

先講結論：WAF 是即時防護層，不是網站安全的替代品

NIST 將 WAF 視為 Web Application Firewall；在實際架構中，它通常位於 CDN、Edge、Reverse Proxy、Load Balancer、API Gateway 或 Web Server 前後，讀取可用的 HTTP／HTTPS 交易資訊，依規則判斷是否放行。它最重要的價值是把政策放在應用程式之前執行，讓已知惡意模式、異常協定、特定路徑濫用與突發流量不必先進入應用程式。

但『請求被 WAF 擋住』與『弱點已修復』是兩個不同結論。WAF 可能只攔住目前已知的 Payload 形態，攻擊者仍可改變編碼、參數位置、內容格式或直接繞過 Edge；而 IDOR／BOLA、跨租戶存取、金額竄改與流程濫用等問題，需要理解使用者、物件與狀態，通用規則很難可靠判斷。

成熟做法是 Defense in Depth：WAF 降低暴露與爭取修復時間，DAST／弱點掃描持續找出可被外部利用的問題，SAST／Code Review 定位根因，應用程式本身執行認證、授權、輸入驗證與安全輸出，最後以監控、修復 SLA 與複驗關閉風險。

• 把 WAF 視為一個需要 Owner、版本、變更、監控與回復程序的正式服務
• 每個公開網站與 API 入口都要確認是否真的經過同一套政策，不能只看 DNS 指向
• 阻擋事件要能對應 Rule、Request、Application、Release 與修復工單
• 弱點未完成原始碼或元件修復前，不得因有 WAF 而改標成已修復

WAF 在請求路徑中做了什麼？從解析到最終動作

一筆請求到達 WAF 後，系統通常會先完成 TLS 終止或取得已解密內容，再正規化 Method、Host、Path、Query、Header、Cookie 與 Body。規則引擎依序執行 IP／地理位置、自訂規則、Rate Limit、Bot／Threat Signal、Managed Rules 與應用專用政策，最後套用 Allow、Block、Count／Log、Rate Limit、Challenge 或 CAPTCHA 等動作。

規則順序是安全語意的一部分。AWS 官方文件指出 Allow 與 Block 屬於終止動作，命中後後續規則不再執行；Count 則通常繼續評估。不同平台名稱不完全相同，但共同風險是：一條過早的 Allow／Skip 可能讓請求跳過後段 Managed Rules，一條過廣的 Block 也可能直接中斷合法交易。

WAF、網路防火牆、IDS／IPS、CDN 與 API Gateway 有什麼不同？

這些元件可能共存在同一個產品或雲端服務中，但安全邊界不同。網路防火牆主要依 IP、Port、Protocol 與 Connection State 控制連線；IDS／IPS 分析網路或主機活動並告警／阻擋；WAF 聚焦已解密的 HTTP 交易；API Gateway 管理 API 路由、認證、Quota 與生命週期；CDN 的核心任務是邊緣快取與內容傳遞，可能附帶 WAF、Bot 與 DDoS 功能。

命名不能取代架構驗證。採用 CDN 不代表 Managed Rules 已啟用；API Gateway 有 Authentication 不代表每個 Object 都做 Authorization；TLS 流量若未在 IPS 前解密，IPS 可能看不到應用層 Payload；Edge WAF 若沒有鎖住 Origin，攻擊者仍可能直接連到 Backend。

WAF 與弱點掃描、DAST、SAST、SCA、滲透測試的差異

WAF 觀察正在通過的流量並執行政策，屬於 Prevent／Detect Control；弱點掃描與 DAST 主動對授權目標發送測試請求，確認應用在特定輸入下是否呈現可利用行為；SAST 分析原始碼或中間表示；SCA 盤點第三方元件與已知風險；滲透測試則由人員將多個弱點與業務脈絡串成攻擊路徑。

WAF Log 可以提供攻擊趨勢，卻不能列出所有尚未被攻擊的弱點；DAST 可以找出問題，卻不是 24 小時阻擋層。最佳整合方式是讓掃描結果建立修復工單，必要時先建立有期限的 WAF Virtual Patch，再以原始負向案例複驗程式修復，最後評估是否撤除臨時規則。

WAF 擅長攔截哪些風險？

OWASP WSTG 指出 WAF 會檢查 HTTP Request 並阻擋看似惡意的內容，對 SQL Injection、XSS 等攻擊較有效。OWASP Core Rule Set（CRS）則提供可在 ModSecurity、Coraza 與相容引擎使用的通用攻擊偵測規則，涵蓋 Injection、Local／Remote File Inclusion、Remote Code Execution、Protocol Violation、Scanner Detection 等類別。

這些能力建立在『攻擊會留下可從單筆或一組 HTTP 交易辨識的訊號』。如果能描述不應出現的字串、結構、編碼、Method、Path、Header、Body、來源、Rate 或行為分數，WAF 就能形成有效控制；若需要知道使用者是否真的擁有某筆訂單，通用 WAF 就缺少必要業務狀態。

WAF 不擅長什麼？權限、商業邏輯與未知狀態不能靠通用規則推理

OWASP WSTG 明確提醒，WAF 對 Access Control 與 Business Logic 問題較不有效。若 Alice 與 Bob 的請求格式完全相同，差別只在 Object Owner，WAF 看到 `GET /orders/123` 並不知道 123 是否屬於目前使用者；若優惠券只能用一次、退款必須先完成退貨、轉帳需要雙人覆核，也需要後端狀態機判斷。

WAF 也不能可靠發現未被請求觸發的脆弱元件、Secret 寫入 Repository、弱密碼雜湊、缺少 Server-side Authorization、背景 Job 權限、雲端 IAM、資料保留或第三方依賴風險。這些問題仍要靠安全設計、Code／Dependency Review、配置查核與授權測試。

兩種政策模型：Denylist 偵測攻擊，Allowlist 定義合法交易

通用 Managed Rules 多採 Negative Security Model：辨識已知攻擊、異常協定與可疑模式，部署快且適合大量不同應用，但必然存在規則覆蓋與繞過邊界。Positive Security Model 則描述某個 Route 只接受哪些 Method、Content-Type、Parameter、型別、長度與結構，不符合即拒絕，對固定 API 與高價值交易更精準。

OWASP Virtual Patching Cheat Sheet 建議在可行時以 Allowlist 建立獨立輸入驗證邊界，但也指出大規模動態網站維護成本高。務實設計是分層：全站使用持續更新的 Managed Rules；登入、付款、管理、上傳與 API 以 Route-specific Schema、Method、Rate 與必要 Header 補強。

OWASP CRS 如何判斷？理解 Rule、Anomaly Score 與 Threshold

OWASP CRS 的 Anomaly Scoring 不是『命中一條就一定阻擋』。規則依嚴重度累積分數，最後與 Inbound／Outbound Threshold 比較；官方預設分數為 CRITICAL 5、ERROR 4、WARNING 3、NOTICE 2，並建議正式調校目標維持 Inbound Threshold 5。提高 Threshold 會降低敏感度，也可能讓只命中單一 Critical Rule 的 LFI、RFI、RCE 或資料外洩行為通過。

因此不能用『誤判很多，把 Threshold 調到 20』作為長期解法。正確順序是保存完整 Rule Match、URI、Parameter 與應用版本，找出合法輸入為何命中，建立最窄的 Rule Exclusion 或修正不必要的輸入格式，再觀察攻擊覆蓋是否仍存在。

Paranoia Level 不是越高越好：先執行觀察，再提高阻擋層級

CRS Paranoia Level（PL）控制會執行哪些規則。提高 PL 會增加偵測面，也幾乎一定帶來新的 False Positive。CRS 官方提出 Executing Paranoia Level 與 Blocking Paranoia Level 分離的方式：先讓較高 PL 的規則執行並留下命中，但只讓已完成調校的較低 PL 參與阻擋；排除合法誤判後，再提高 Blocking PL。

這比同時提高 PL 與 Anomaly Threshold 安全，因為後者可能為了容納新誤判而放過原本會阻擋的攻擊。每次 PL、Ruleset Version 或 Threshold 變更都要視為政策 Release，有流量樣本、驗證矩陣、Canary、Rollback 與 Owner。

部署位置怎麼選？Edge、區域 Gateway、Reverse Proxy 與主機型 WAF

Edge／CDN WAF 可以在全球邊緣吸收攻擊與降低 Origin 負載；區域 Load Balancer／API Gateway WAF 更接近私有網路與服務路由；獨立 Reverse Proxy 或 Appliance 可集中保護多種 Backend；主機或 Sidecar 型部署則能貼近特定 Workload。選擇不只看規則數，還要看 TLS、Body Size、API 格式、Latency、HA、Log、IaC、資料區域與故障模式。

大型組織常採多層 WAF，但兩層的解析、規則與例外若不一致，可能造成重複阻擋或內層盲區。應明確指定哪一層負責 DDoS／Bot／Rate、哪一層負責 Managed Rules 與應用專用 Schema，以及每層實際看到的 Client IP、Host、Path 與 Body。

最常被忽略的旁路：Origin 必須只接受受信任 WAF 路徑

OWASP WSTG 提醒，Cloud WAF／CDN 可能因直接存取 Backend 而被繞過。攻擊者可從歷史 DNS、憑證透明度、錯誤訊息、郵件來源、SSRF 或公開雲端位址找到 Origin；只要 Origin 仍接受 Internet 流量，Edge 的所有規則都可能失去意義。

Origin 應以 Security Group／Firewall、Private Link、mTLS、Authenticated Origin Pull、受信任 Proxy IP 與 Host 驗證限制來源。`X-Forwarded-For` 等 Header 只能信任由已驗證 Proxy 重建的值；不能讓 Client 自行提供並被日誌、Rate Limit 或 Allowlist 採用。健康檢查、管理介面、舊網域、IPv6、災難復原站與 Object Storage 也要納入旁路盤點。

• 封鎖 Origin 對公網的直接存取，或只允許 WAF／CDN 的受控來源與身分
• 每季以外部資產盤點確認舊 IP、AAAA、旁支網域、測試站與備援站沒有暴露
• Origin 驗證 Host、TLS 憑證與代理身分，不因來源 IP 單一訊號即完全信任
• 健康檢查與故障切換不得把流量切到未受 WAF 政策保護的公開端點

TLS、Request Transformation 與解析差異會決定 WAF 看見什麼

WAF 若在 Edge 終止 TLS，必須確保 Edge 到 Origin 仍採 TLS 並驗證 Backend 憑證；否則外部 HTTPS 只保護了半段路徑。若端到端 TLS Passthrough，WAF 可能無法檢查 Payload。架構文件應清楚標出每次解密、重新加密與信任建立的位置。

更棘手的是 Parser Differential：WAF、Proxy、Framework 與 Application 可能對重複 Header、Content-Length／Transfer-Encoding、URL Encoding、Unicode、Path Separator、Multipart 與 JSON Duplicate Key 有不同解讀。安全基線要拒絕歧義訊息、限制轉換、保持軟體更新，並以 Origin 實際接收的 Request 與 WAF Log 做對照測試。

網站、REST、GraphQL、WebSocket 與檔案上傳不能套同一組假設

傳統表單、JSON API、GraphQL、gRPC Transcoding、WebSocket Upgrade、Multipart 與大型檔案上傳的解析方式與 Body 大小不同。WAF 可能只檢查前 N KB、只解析支援的 Content-Type，或只在 WebSocket Handshake 階段執行規則；超出檢查上限的內容若仍轉送，會形成可預測盲區。

每個 Application Profile 要列出 Method、Path、Content-Type、最大 Header／Body、壓縮、Streaming、Upload、GraphQL Operation 與 WebSocket 行為，確認平台實際支援並監控 `body_truncated` 等訊號。對無法完整檢查的資料，不應靜默視為安全；可依 Route 拒絕、改走專用 Pipeline、限制大小或交由應用層 Schema 與內容掃描。

Rate Limit、Bot 與 Challenge：不要只用 IP 當使用者

Rate-based Rule 能對突發流量、登入嘗試、Scraping 與資源昂貴 Endpoint 提供緩解，但 NAT、Mobile Carrier、Corporate Proxy 與 IPv6 會讓一個 IP 代表多人或一人使用多個位址。只按 IP 限流容易誤傷，也可能被分散式來源繞過。

應依風險選擇聚合 Key：IP、Account、Session、API Key、Tenant、Device Signal、Route 與失敗狀態的組合，並區分 Read、Write、Login、Password Reset、Search、Export 與 Upload。Challenge／CAPTCHA 只能降低自動化濫用，不能取代 MFA、Credential Stuffing Detection、帳號鎖定策略與交易層風險判斷。

Virtual Patching：快速降低暴露，但必須綁定弱點與期限

OWASP 將 Virtual Patch 定義為一個政策執行層，在交易途中阻止已知弱點被利用，而不修改應用原始碼。它適合第三方套件尚無 Patch、變更窗口未到、Legacy System 難以快速發布或 Incident Response 需要立即降低暴露時使用。

Virtual Patch 與 Code Fix 不互斥。每一條臨時規則都應綁定 Vulnerability ID、受影響 Route／Parameter、原始 Exploit Evidence、Owner、核准者、部署模式、開始時間、到期日、監控與撤除條件。只封鎖報告中的一段固定 Payload 很容易被變形繞過；能定義合法輸入時，應優先採 Route-specific Allowlist。

安全上線不是直接 Block：Detection、調校、Canary、Prevention

Microsoft、Cloudflare 與 OWASP 的實務文件都強調新規則需要觀察與調校。第一步在 Detection／Count／Log 模式蒐集涵蓋尖峰、批次、管理操作、上傳與 API Client 的真實流量，再將命中分成真攻擊、合法但異常、掃描器、合作夥伴與未知；確認每個 False Positive 的確切 Rule、Route、Parameter 後建立最小例外。

進入 Prevention 應採 Canary：先保護內部／低風險流量、單一網域、少量比例或特定 Region，觀察 HTTP 4xx、應用錯誤、Conversion、Latency、Rule Hit 與客服事件，再擴大。重大 Ruleset、PL、Threshold 與自訂規則更新都要重走同一流程。

誤判怎麼調？縮小例外，不要關掉整組規則

False Positive 是合法請求被判定為惡意；False Negative 是惡意請求未被阻擋。調校的目標不是讓 Log 變乾淨，而是在不破壞合法交易下維持攻擊覆蓋。Cloudflare 官方建議若單一 Managed Rule 誤判，停用或排除該特定規則，而不是整個 Ruleset；Azure 也建議例外縮到最窄的 Match Variable、Selector、Rule、Group 或 Set。

每次例外要回答：哪個 Route、哪個 Parameter、哪種合法值、哪個 Rule ID、為何安全、誰核准、何時到期。若 `/admin/import` 的 `description` 會命中一條 XSS Rule，例外應只限該 Route 與 Parameter，不能跳過全站 XSS、整個 `/admin` 或所有 Request Body。

規則順序、Allow、Skip 與 Default Action 是常見配置弱點

WAF 通常依優先序逐條評估。若前段 IP Allow、Partner Allow 或 Skip 命中後直接終止，後段 Rate Limit 與 Managed Rules 可能完全不執行；若 Default Allow 搭配規則覆蓋不足，未辨識流量直接通過；若 Default Block 卻沒有完整 API Inventory，則新 Endpoint 可能直接中斷。

Policy Review 要以實際 Evaluation Trace 驗證，而不是只讀設定頁。對每類請求建立預期路徑：會執行哪些 Phase、累積哪些 Label／Score、哪一條是終止動作、最終是否到 Origin。尤其要檢查 Rewrite 前後的 Host／Path、IPv4／IPv6、Internal Header、Trusted Bot 與 Partner Exception。

• 非終止的 Log／Count 規則應放在需要完整觀測的位置
• 所有 Allow／Skip 都必須列出會被跳過的產品、Phase 與規則，而非只寫『可信來源』
• 自訂規則與 Managed Rules 更新後重新驗證優先序，不假設平台行為永遠不變
• Default Action、錯誤處理與 WAF 不可用時的 Fail Open／Closed 行為要經演練

日誌與監控：要能回答誰被擋、為何被擋、Origin 是否仍收到

可用的 WAF Event 至少應包含 Timestamp、Request ID、Client／Proxy Chain、Host、Method、Route、Status、Rule／Ruleset Version、Action、Anomaly Score、Matched Variable、Application、Environment 與 Origin Outcome。將事件送到 SIEM 後，與 CDN、Load Balancer、Application、Identity、Deployment 與 Vulnerability Ticket 關聯，才能區分攻擊、掃描、誤判與新版本回歸。

WAF Log 可能含 Cookie、Authorization、Query、表單、個資與 Payload，不應為了除錯永久保存完整敏感內容。採欄位 Allowlist、Token／Secret Redaction、最小權限、加密、Retention 與 Break-glass Access；告警中只放調查必要證據，原始樣本放受控位置。

把 WAF Policy 當成程式碼：版本、審查、測試與回復

Managed Ruleset 選擇、Mode、Priority、Threshold、Paranoia Level、Custom Rule、Exception、Rate Limit、Log Scrubbing 與 Origin Association 都應進入 Infrastructure as Code 或可匯出的版本控制。Production 變更需 Pull Request、雙人審查、Static Validation、Replay Test、Canary 與已知良好版本回復。

測試資料要同時包含正常交易、邊界值、歷史 False Positive、真實但去敏感化的攻擊樣本、編碼變形與每一條 Virtual Patch 的原始 PoC。Ruleset 自動更新雖能快速取得新防護，也可能改變行為；應掌握 Release Window、變更通知與 Log-only 觀察期。

效能、容量與可用性：WAF 本身也是關鍵路徑

所有經過 WAF 的請求都增加解析、規則評估與 Log 成本。Body Inspection、複雜 Regex、Bot Detection、外部 Reputation、Response Inspection 與高 PL 可能提高 Latency 與運算量；大檔、壓縮內容、長 Header、JSON 深度與攻擊洪水也可能把 WAF 變成瓶頸。

容量設計應以尖峰 Request／Second、Bandwidth、Body Size、TLS Handshake、Rule Complexity 與 Region Failure 做壓力測試，並定義 WAF 不可用時是 Fail Open、Fail Closed、Bypass 還是降級。高風險交易偏向安全拒絕；公開內容可能選擇受限降級，但必須明確、短暫、告警且不暴露管理與寫入路徑。

網站有 WAF，弱點掃描要怎麼做才不被結果誤導？

授權掃描若只看到 WAF Block Page，證明該 Payload／路徑當下被 Edge 攔截，不代表 Origin 沒有弱點；若為了測試直接停用 WAF，結果又可能不代表正式使用者的真實攻擊面。最有價值的做法是明確分成兩種視角：Production Path 驗證外部可利用性與 WAF 行為；受控的 Origin／Staging Path 驗證應用根因，但必須有額外授權、來源限制與安全窗口。

掃描團隊與 WAF Owner 應共享 Scanner Source、時間窗、Request ID 與測試範圍，避免把合法掃描誤判為事件，也不要建立過廣的 Scanner Allowlist。報告要保留『Origin Vulnerable／WAF Mitigated』『Externally Exploitable』『WAF Bypass』『Not Reached』等不同狀態，修復後再同時驗證應用與 WAF。

事件應變時怎麼用 WAF？先減少傷害，再保存證據與修復根因

發現正在利用的網站弱點時，可先以 Route／Parameter／Method／Source／Rate 建立範圍最小的臨時 Block 或 Challenge，必要時關閉受影響功能，並提高該區段 Log 與告警。所有動作應保留 Policy Version、Rule ID、部署者、時間、命中事件與 Rollback，避免在高壓下建立無法追蹤的永久例外。

阻擋後仍要確認是否已有成功請求到達 Origin、是否有資料存取、帳號接管、Web Shell、異常 Token、Background Job 或旁路流量；WAF Event 只是事件證據之一。完成程式修復與 Incident Containment 後，以原始與變形案例複驗，再觀察一段時間，逐步移除臨時規則。

• 先確認合法授權與事件指揮權，再變更正式 WAF Policy
• 以最小條件緩解，不在未知影響下停掉整站或整套 Managed Rules
• 保存原始 Request、WAF Decision、Origin Outcome、Identity 與資料存取證據
• 同步開立 Root Cause Fix 與 Virtual Patch Expiry，不讓臨時控制取代修復

如何選擇 WAF？用可驗證能力與營運成本評估，不只比較規則數

採購或自建 WAF 時，規則數不是有效性的直接指標。應以實際應用、API、Body、協定、Region、資料敏感度與團隊能力設計 Proof of Concept；使用合法交易、歷史誤判、已知弱點、編碼變形、Rate、Origin Bypass 與故障情境驗證。

評估總成本要包含 Policy Engineering、False Positive Triage、24×7 On-call、Log／SIEM、Data Egress、Ruleset／Bot Add-on、IaC、HA、Latency、合規與供應商鎖定。若平台無法提供完整 Rule Match、版本、Action、Body Truncation、變更稽核與可控例外，日後很難證明它做了什麼。

修復與複驗：怎樣才可以把 WAF 相關 Finding 關閉？

WAF Finding 可能是未部署、未關聯資產、Detection-only、Ruleset 過期、例外過廣、Origin 可繞過、Log 缺失、Threshold 過高、Body 未檢查或 Virtual Patch 逾期。修復必須針對實際 Root Cause；只看到一筆攻擊被 Block，無法證明其他 Host、Path、Method、Body 與 Origin 都受保護。

複驗從 Inventory 開始，逐一確認 DNS／CDN／Gateway／Origin Association、TLS、Policy Hash、Mode、Rule Version、Priority、Exception、Rate、Body Limit、Log 與 Alert。再以正向交易、原始攻擊、編碼變形、替代 Content-Type、IPv6、直接 Origin、故障切換與高流量案例驗證，並確認合法功能沒有被破壞。

常見誤區：有 WAF 不等於網站已安全

WAF 最危險的誤用，是把控制存在誤認成控制有效。Dashboard 顯示 Enabled，只代表某個資源可能已關聯某份政策；沒有 Entry Point Inventory、Origin Restriction、Rule Trace、Body Coverage、Log、False Positive Tuning 與負向複驗，就無法證明實際防護。

WAF 上線與持續營運檢查清單

以下清單應對應實際 Host、API、Policy、Rule Version、Owner、Log 與證據。每個未完成項目都要有補償控制、期限與驗證方式；不要以一張產品啟用截圖取代端到端測試。

• 所有公開 Web、API、IPv4／IPv6、舊網域、測試與備援入口都已納入資產盤點
• 每個入口都關聯正確的 WAF Policy，Origin 只接受受信任 Proxy／WAF 路徑與身分
• TLS Client-to-Edge 與 Edge-to-Origin 都有安全版本、憑證驗證與更新程序
• Method、Host、Path、Header、Cookie、Query、Body、Content-Type 與大小的實際檢查範圍已驗證
• 網站、REST、GraphQL、WebSocket、Multipart、Streaming 與大型上傳都有明確政策
• Managed Ruleset、Anomaly Threshold、Executing／Blocking PL 與自訂規則均有核准基線
• 所有 Allow／Skip／Exception 都縮到最小條件，記錄理由、Owner、到期日與會跳過的 Phase
• Detection 流量樣本、False Positive Replay、Canary、Prevention 與 Rollback 均已完成
• Rate Limit 依 Account／Session／API Key／Tenant／Route 等風險維度設計，不只依 IP
• WAF Event 可關聯 Request、Rule、Policy Version、Application、Deployment 與 Origin Outcome
• Cookie、Token、密碼、個資與 Payload 已在 Log 前遮罩，Retention 與權限符合資料政策
• Policy 以版本控制與 IaC 管理，具雙人審查、自動測試、Drift Detection 與已知良好版本
• 尖峰、攻擊流量、Body 上限、WAF 故障、Zone／Region Failover 與 Log Sink Failure 已演練
• 每一條 Virtual Patch 都綁定 Finding、原始證據、Fix Release、到期日、複驗與撤除條件
• 弱點掃描同時保留 Production Path 與受控 Root Cause 視角，不把 WAF Block 當成已修復

Redmark 如何把 WAF 訊號與弱點修復流程接起來

Redmark 協助團隊持續盤點網站攻擊面、執行授權弱點掃描、保存風險證據並追蹤修復。對有 WAF 的網站，掃描結果應區分應用根因、外部可利用性與補償控制狀態，避免把一筆 403 或 Block Page 直接當成安全結論。

真正有效的閉環是：Redmark 找出與重現弱點，WAF 在修復窗口提供可監控的臨時緩解，開發團隊完成根因修復，再以相同負向案例與旁路矩陣複驗，最後撤除不再需要的 Virtual Patch。如此才能同時縮短暴露時間，又不讓臨時規則變成永久技術債。