WAF 防火牆（網站應用程式防火牆）是放在網站前面、專門檢查 HTTP 請求內容的防護層，依規則攔下跨網站指令碼（XSS）、SQL 注入這類常見的網站攻擊。它和一般網路防火牆不同：網路防火牆主要看 IP 位址、連接埠與協定，WAF 則看請求裡帶了什麼內容。WAF 能在修補完成前擋下已知的攻擊路徑，但不能取代軟體更新與安全的程式設計，權限設計錯誤這類問題仍要在網站程式裡修正。部署位置可以是雲端反向代理、網站伺服器上的模組或內容管理系統外掛；上線前先用只記錄的模式調整規則，確認不會擋到正常使用者，再切換成阻擋。
WAF 是什麼：檢查 HTTP 請求的應用程式防火牆
Open Worldwide Application Security Project（OWASP）的定義是：WAF 是給 HTTP 應用程式使用的應用程式防火牆，會對 HTTP 對話套用一組規則，這些規則一般涵蓋跨網站指令碼與 SQL 注入等常見攻擊。OWASP 也說明，代理伺服器通常保護的是用戶端，WAF 保護的則是伺服器，可以把它視為一種反向代理。
美國國家標準與技術研究院（NIST）的防火牆指南把 WAF 描述為位在網站伺服器前面、針對 HTTP 攻擊的特殊應用程式防火牆。形式上，OWASP 列出設備、伺服器外掛或過濾器等型態，也可以依網站客製規則；但客製的工作量可能很大，而且網站改版時規則也要跟著維護。
和網路防火牆的差別
兩者檢查的層次不同，各自處理不同類型的問題：
- 網路防火牆：NIST 說明封包過濾是依封包中的來源與目的 IP 位址、協定、連接埠等資訊做存取控制，並不管封包的內容，適合用來關閉不必要的連接埠。
- 應用程式防火牆：NIST 指出它能依應用程式在網路上的運作方式允許或拒絕存取，看的是應用層的行為。
- WAF：是專門處理網站流量的應用程式防火牆，會檢查網址、參數、表單欄位與標頭裡的內容，判斷是否符合攻擊特徵。
因此主機商說「有防火牆」時，要再確認是只依位址與連接埠過濾，還是有檢查 HTTP 請求內容的 WAF，兩者不能互相替代。
WAF 擋得住與擋不住的攻擊
WAF 依規則比對請求，能處理的是規則涵蓋、而且在請求裡看得出特徵的攻擊：
- 擋得住的：規則涵蓋的常見攻擊，例如跨網站指令碼與 SQL 注入；以及已知弱點的攻擊路徑。OWASP 把後者稱為虛擬修補，在正式修補完成前，先偵測並阻擋符合的攻擊嘗試。
- 不能取代修補：OWASP 明確指出虛擬修補不會移除漏洞本身，更新元件與修正程式仍要排進時程。
- 不一定擋得住的：存取控制失效是 OWASP 十大風險之一，例如改掉網址裡的編號就能檢視或編輯別人的帳號資料。OWASP 說明存取控制只有在可信任的伺服器端程式或無伺服器 API 實作才有效，這類請求在格式上可能和正常操作無異，要回到網站程式修正。
- 規則以外的情況：用外洩的正確帳號密碼登入、利用商業流程漏洞的操作，WAF 不一定判斷得出來，仍要靠多重要素驗證與功能測試把關。
雲端、伺服器與外掛：WAF 部署位置比較
WordPress 官方的強化指南把網站防火牆分成幾種位置，差別在於過濾發生在流量抵達網站之前，還是在網站程式處理請求的過程中：
| 部署位置 | 過濾時機 | 設定方式 | 要注意的事 |
|---|---|---|---|
| 反向代理服務（雲端 WAF） | 流量抵達網站之前 | 修改 DNS 的 A 紀錄或整組 DNS | 主機要封鎖未經 WAF 的流量，否則可能被繞過 |
| 網站伺服器上的 WAF | 網站程式處理之前 | 在伺服器安裝模組並載入規則集 | 需要伺服器管理權限，先確認主機方案是否允許 |
| 伺服器層的存取規則 | WordPress 處理之前 | 由外掛修改 .htaccess 限制存取 | 規則寫錯可能影響整站，修改前先備份 |
| 內容管理系統外掛 | WordPress 載入時、完整處理之前 | 在後台安裝外掛 | 過濾在網站主機上執行，外掛本身也要更新 |
雲端 WAF 的關鍵是來源主機的保護。以 Azure Front Door 為例，官方建議把來源設定為封鎖未透過 Front Door 傳送的流量，否則流量可能略過 WAF 與其他安全性功能。
網站什麼時候需要 WAF
是否導入，可以依網站的功能與維護狀況判斷：
- 有會員登入、表單、檔案上傳或線上交易，對外開放的輸入點越多越值得評估。
- 使用第三方套件或委外開發，發現弱點時無法馬上修改程式。OWASP 列出的虛擬修補情境包括開發資源不足、第三方軟體無法修改、委外開發要另開專案，以及修補需要時間。
- Search Console 出現安全性問題，或主機記錄顯示大量可疑請求。
比較各家 WAF 品牌之前，先列出要問的條件：是否能切換偵測與阻擋模式、能否看到完整的阻擋記錄、規則集由誰維護與更新、能否自訂規則與排除、來源主機要怎麼保護、憑證與 DNS 怎麼設定，以及誤擋時的支援管道。
導入步驟：先偵測再阻擋
- 盤點網站入口：列出後台、登入頁、表單、上傳與 API 網址，作為之後測試的清單。
- 選擇部署位置並完成連線：雲端 WAF 要切換 DNS，並設定主機只接受經過 WAF 的流量；各類紀錄的用途可參考DNS 紀錄的類型說明。
- 先以偵測模式運作：以 Azure 為例，偵測模式只監視並記錄符合規則的請求，不會封鎖流量；OWASP 也建議虛擬修補先以只記錄的設定上線。
- 調整規則：依記錄建立規則排除，降低誤判。開源的 OWASP CRS 以偏執等級控制規則的積極程度，共分四級，等級越高越容易產生誤判。
- 切換成阻擋：調整完成後改為預防模式。Azure 提醒偵測模式不提供任何保護，不要停留在這個階段。
- 定期檢視記錄：網站改版、新增功能後，重新跑一次入口清單的測試。
誤擋怎麼處理：用排除取代關閉
OWASP CRS 把正常的請求錯誤觸發規則稱為誤判，例如後台編輯器送出含程式碼的內容，就可能觸發注入類規則。處理順序如下：
- 記下發生時間、網址、操作步驟與畫面上的錯誤訊息。
- 到 WAF 記錄找出對應的請求與觸發的規則。
- 針對該規則與網址建立排除，不要直接修改規則檔；CRS 官方強烈不建議直接改規則檔。
- 重新測試同樣的操作，並確認其他入口仍受保護。
為了解決誤擋而整個關閉 WAF，CRS 文件形容這是為了使用方便而不必要地犧牲安全。
常見問題
小型形象網站也需要 WAF 嗎？
視網站功能而定。只有介紹頁面、沒有登入與表單的網站，對外的輸入點較少，可先做好更新、備份與帳號保護；有會員、表單或上傳功能時再評估導入。
WAF 的規則需要自己寫嗎？
不一定。以 Azure 為例，WAF 原則可使用 Azure 管理的受控規則集，也能自己建立自訂規則；開源的 OWASP CRS 也提供現成規則，再依網站需要調整。
WAF 記錄要看哪些內容？
看被阻擋或標記的請求來自哪些網址、觸發哪條規則、是否集中在登入頁或表單。Azure 也建議定期檢視記錄，用來減少誤判並了解網站是否成為攻擊目標。
有了 WAF，還需要做弱點掃描嗎？
需要。WAF 擋的是符合規則的請求，不會告訴你網站本身有哪些弱點；弱點掃描找出問題後，仍要更新元件或修正程式，WAF 是在修補前爭取時間。
網站改版後，WAF 設定要重新檢查嗎？
要。OWASP 提醒客製的規則需要隨著網站修改持續維護。新增表單、改變網址結構或換了外掛後，原本的排除可能不再適用，也可能出現新的誤擋。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
想直接討論你自己的網站狀況，或需要一份初步的搜尋機會評估？
相關主題
下一步
評估 WAF 前，先列出網站的登入、表單、上傳與 API 等入口，並確認主機與 DNS 由誰管理。京采的網頁設計服務可以協助評估部署位置、配合切換 DNS 並設定主機只接受經過 WAF 的流量，上線後逐一測試表單與後台功能是否被誤擋；想先討論網站現況，歡迎與我們聯繫。
