網站需要 WAF 嗎：網站應用程式防火牆能擋什麼、不能擋什麼

網站有登入、會員、表單或線上訂單，或客戶與法規要求「應用程式防火牆」時，就值得認真評估 WAF。WAF 檢查的是送到網站的 HTTP 請求，能攔下常見的注入、跨站腳本與暴力登入嘗試，也能在外掛來不及更新時充當臨時補丁；但它擋不住塞爆頻寬的網路層攻擊，也取代不了系統更新、備份與帳號安全。本文說明 WAF 和一般防火牆的差別、三種部署方式怎麼選、誤擋怎麼處理，最後附上判斷清單。

01常見情境：會員網站、接到資安問卷的製造商、只有形象官網的事務所

要不要導入 WAF，取決於網站功能與維護方式。以下是三種常見情況（示意），各自該先看的段落不同。

• 經營線上課程的小團隊：課程網站用 WordPress 搭配會員外掛，最近後台出現大量陌生 IP 的登入失敗。負責人擔心學員資料外洩，又怕加了防護後學員登不進來。先看「WAF 能擋什麼」表格中驗證失敗那一列，確認登入頁有沒有限速與多因素驗證；再看「誤擋、規則調整與只記錄模式」，先觀察一段時間再開啟阻擋。
• 接海外訂單的零件製造商：中型工廠的資訊兼總務人員收到大客戶的供應商資安問卷，其中一題問官網是否設有應用程式防火牆。他擔心答「沒有」會影響訂單，卻不確定只有型錄與詢價表單的網站算不算需要。先看「判斷清單」釐清網站實際處理哪些資料、問卷依據什麼要求；再看「三種常見做法」，評估哪一種和現有主機相容、由誰維護。
• 只有形象官網的會計師事務所：官網是幾頁介紹加聯絡表單，委外維護，所長聽說「網站一定要裝防火牆」，擔心花了錢卻不知道防到什麼。先看「WAF 不能取代的事」，確認更新、備份與帳號這些基本功是否到位；表單若收個資，再看判斷清單排先後。

02WAF 是什麼：和一般防火牆差在哪裡

依 OWASP（開放全球應用程式安全計畫）的說明，WAF 是針對 HTTP 應用程式的防火牆，對每一次 HTTP 往來套用一組規則，常見規則涵蓋跨站腳本（XSS）與 SQL 注入等攻擊。OWASP 也指出，一般代理伺服器保護的是使用者端，WAF 保護的是伺服器端，可以看成一種反向代理；形式可以是硬體設備、伺服器外掛或過濾器，放在單一或一群應用程式前面。

和平常說的「防火牆」相比，差別在檢查的東西不同：

• 網路防火牆：依 IP、連接埠與通訊協定決定放行或拒絕，例如只開放網頁用的 80、443 連接埠。它看得到「誰要從哪扇門進來」，通常不看帶了什麼。
• WAF：看的是網址、參數、表單欄位、Cookie、標頭與請求內容，判斷這一筆請求像不像攻擊。例如有人在搜尋框送出夾帶資料庫指令的字串，網路防火牆只看到一條普通的 443 連線而放行，WAF 才有機會依規則攔下。

美國國家標準與技術研究院（NIST）的術語表把「應用程式防火牆」定義為以狀態式協定分析，檢查一個或多個應用程式流量的防火牆。兩者不是二選一：網路防火牆關掉不該開的門，WAF 檢查從開著的門走進來的內容。

常被忽略的是維護成本。OWASP 提到 WAF 可以依個別網站客製，但工作量可能不小，網站改版或新增功能時規則也要跟著調整，比較像一項要持續照顧的設定。

03三種常見做法：雲端反向代理、主機伺服器層、網站外掛

同樣叫 WAF，放的位置不同，看得到的流量與維護方式也不同：

選擇時可以這樣想：網站放在共用的虛擬主機、沒有伺服器管理權限，多半只能在雲端代理型與外掛型之間挑；網站放在 VPS 或專屬伺服器、有人能管理伺服器設定，就多了伺服器層這個選項，也能搭配 OWASP 維護的開源通用規則集。WordPress 官方的強化指南也提到，除了外掛，也可以在網站伺服器上安裝 WAF，讓內容在交給 WordPress 處理之前先過濾。

三者各有盲點：外掛型最容易開始，但和網站跑在同一個程式裡，網站被入侵後外掛也可能被停用；雲端代理型若主機沒鎖定只接受代理連線，等於留了一道側門；伺服器層則需要懂伺服器設定的人照顧。

04WAF 能擋什麼：對照 OWASP Top 10 的常見攻擊

OWASP Top 10 是 OWASP 發布的網站應用程式安全認知文件，整理最關鍵的風險，目前最新為 2025 年版。它是風險分類，不是 WAF 的功能清單；下表挑出和 WAF 最相關的幾類。

不安全的設計（A06）、安全設定錯誤（A02）這類問題出在網站本身，WAF 能做的很有限。合理的期待是：WAF 減少自動化攻擊得手的機會、替修補爭取時間。

05誤擋、規則調整與只記錄模式

WAF 的規則是通用的。OWASP 通用規則集的文件把誤判定義為正常請求被規則誤認為攻擊，並說明剛部署的規則集不認識背後的網站；防護等級越高，越容易誤判。實務上常見的誤擋包括：

• 在後台編輯文章時貼入含 HTML 標籤的內容，被當成跨站腳本。
• 表單欄位填了程式碼片段、SQL 字樣或大量特殊符號。
• 外部系統回傳的通知或 API 串接請求，格式和一般瀏覽不同而被擋，例如物流狀態更新。
• 公司多人共用同一個對外 IP 登入後台，觸發限速。

降低誤擋可以照這個順序做：

1. 先用只記錄模式上線：OWASP 的虛擬補丁說明建議，新規則先以「只記錄」的設定實施，確認不會誤擋正常操作再改成阻擋。觀察期最好涵蓋促銷活動、後台大量上架這類尖峰日子。
2. 攻擊與正常流程都要測：同一份說明也提醒，除了測試攻擊會不會被擋，也要走一遍正常的註冊、送出表單與後台編輯。
3. 用例外規則處理，不要直接改規則檔：規則集文件建議以排除規則處理誤判，而不是修改原始規則，因為規則更新時改動會被覆蓋。排除範圍越精準越好，例如只對某個後台網址的某個欄位放寬。
4. 每次調整都留紀錄：寫下誰、為什麼、針對哪個網址放寬，網站改版或換外掛時回頭檢查是否還需要。

規則集文件也提醒，誤擋放著不處理，會讓警報多到沒人看、正常使用者被擋在門外。導入前就要講好：誰看紀錄、誰能調規則、客人回報被擋時找誰。

06WAF 不能取代的事：更新、備份、帳號安全與網路層 DDoS

WAF 是多一層過濾，不是萬用的防護罩。下面這幾件事，有沒有 WAF 都得照做：

• 系統與外掛更新：虛擬補丁只是爭取時間。OWASP 的說明直接指出，虛擬補丁不會移除底層的漏洞，程式或原廠的修補仍要繼續進行；WordPress 官方強化指南也把保持最新版放在重要位置，並提到 3.7 版起已有自動更新。
• 備份與還原：WAF 擋的是請求，不保護資料本身。帳號被盜、誤刪或主機故障時，能救回網站的是可還原的備份。WordPress 官方建議定期備份，包括 MySQL 資料庫；還要實際試過還原，才知道備份能不能用。
• 帳號安全：管理者密碼外洩後，攻擊者用正確帳密登入，在 WAF 眼中就和正常管理者一樣。多因素驗證、每人一組帳號、離職或合約結束就停用帳號，這些都要在網站後台與主機控制台各自設定。
• 網路層 DDoS：WAF 處理的是 HTTP 請求；大量封包塞滿頻寬時，線路在流量抵達 WAF 之前就滿了，要靠主機商或上游的清洗能力。WAF 對應用層的大量請求能幫上一部分，例如對搜尋與登入網址限速。攻擊層級與當下的處理順序請見 DDoS 攻擊緊急處理，防護方式可參考 DDoS 防護。
• 已經被入侵的網站：WAF 只能擋之後的請求，不會清除已經植入的後門或惡意程式。網站若已出現被駭跡象，先照 網站被駭的處理步驟 清除與修補，再談加裝防護。

如果更新常拖延、沒有可還原的備份、管理帳號多人共用，建議先補齊這些缺口，再把 WAF 當作額外一層。

07判斷清單：你的網站值得導入 WAF 嗎

下列項目符合越多，導入 WAF 的優先順序越高：

• 網站有登入功能：會員專區、經銷商後台都會遇到撞庫與暴力登入。
• 會收集個人資料：表單收姓名、聯絡方式、履歷或健康相關資訊，一旦被注入或外洩，後果嚴重。
• 有線上訂單或查詢：購物車、訂單查詢、優惠碼欄位，常被自動化程式反覆嘗試。
• 使用大量第三方外掛或套件：元件越多，等待更新的空窗越多，虛擬補丁越有用。
• 更新常常延後：維護廠商只定期更新，或舊系統無法升級。
• 有合規要求：依《資通安全責任等級分級辦法》附表，責任等級 A 級與 B 級的特定非公務機關，具有對外服務之核心資通系統者，應備應用程式防火牆；C 級的附表沒有列這一項。依《資通安全管理法》第 3 條，特定非公務機關指關鍵基礎設施提供者、公營事業、特定財團法人或受政府控制之事業、團體或機構。一般中小企業多半不在適用範圍，但客戶若屬於這類單位，可能會在供應商問卷中詢問。

反過來看，只有幾頁介紹、沒有表單也沒有對外開放後台的靜態網站，WAF 的效益相對有限，先把更新、備份、帳號與 HTTPS 做好比較實際。決定導入後，要和防護服務方或網站維護者確認規則由誰維護、紀錄保存多久，以及費用依流量、網站數量還是功能計算。

08找凱斯騰協助前，先準備這些：評估 WAF 前要整理的資料

評估要不要加 WAF、加在哪一層之前，先把網站現況整理出來：

1. 網站網址、使用的系統（WordPress、OpenCart 或自行開發）與版本，以及裝了哪些外掛或套件。
2. 主機類型（共用虛擬主機、VPS、專屬伺服器）、DNS 在哪裡管理、目前流量有沒有經過 CDN 或其他代理。
3. 網站上有哪些登入、表單、檔案上傳與查詢功能，各自收集哪些資料。
4. 近期的異常狀況：大量登入失敗、可疑的網址請求、主機商寄來的通知，附上發生時間與截圖。
5. 若是客戶或法規要求，附上問卷題目或規定原文，並確認對方要的是「有設置」這個事實，還是規則設定、阻擋紀錄這類佐證資料。
6. 目前的維護分工：誰負責更新網站、誰握有主機與網域帳號、外包合約有沒有寫到資安事件的處理。

凱斯騰沒有單獨提供 WAF 服務，能協助的是 WAF 周邊的主機與防護架構：評估網站是否適合移到可自行設定伺服器防護的主機；WordPress 網站可考慮附網站備份與主機狀態監控的 WordPress 主機；網路層與大流量攻擊則可洽詢 DDoS 防護。資料整理好後，可透過 聯絡表單 或來信 [email protected] 說明網站狀況。