WAF（Web Application Firewall，網站應用程式防火牆）是擋在網站前面的一道檢查站，專門看每一個進出網站的請求，把看起來像攻擊的擋下來。它的價值在漏洞剛爆出來、網站還來不及修補的那段時間最明顯：2026 年 10 月 PHP 爆出重大漏洞 PHP2Shell，Cloudflare 在官方公開漏洞前大約 9 小時，就幫所有用它 WAF 的網站（包含免費方案）自動加上防護規則。
這篇用這次事件當例子，把 WAF 是什麼、能做什麼、做不到什麼講清楚。如果你想看漏洞本身與網站該怎麼升級，可以先讀我們整理的 PHP2Shell 白話拆解與當天修補實錄；這篇講的是另一半：修補完成之前，有什麼東西能先幫你擋。
WAF 是什麼？一張表看懂它在保護什麼
一句話：WAF 專門保護「網站」這一層，看的是請求的內容，判斷有沒有人想利用網站的漏洞。用大樓來比喻，一般防火牆是大門的門禁，決定哪些門可以進出；WAF 是大廳的保全，會看你手上拿的東西，發現有人帶著撬鎖工具就攔下來。
一般防火牆 | WAF（網站應用程式防火牆） | |
|---|---|---|
像什麼 | 大樓門禁：哪些門開、哪些門關 | 大廳保全：檢查每個訪客帶了什麼 |
看什麼 | 連線從哪裡來、要去哪個埠 | 網頁請求的內容，例如表單送出的資料、網址參數 |
擋什麼 | 不該開放的服務被連進來 | SQL 注入、跨站腳本、利用軟體漏洞的攻擊 |
放在哪 | 主機或機房的網路邊界 | 網站前面，常見是 Cloudflare 這類代理服務 |
誰需要 | 所有主機 | 有對外網站、表單、會員登入的公司 |
兩者分工不同，不能互相取代。主機層的防火牆怎麼設，可以參考 伺服器防火牆是什麼；這篇專講網站層的 WAF。
Cloudflare 這次做了什麼：漏洞公開前 9 小時就上防護
一句話：Cloudflare 參與了 PHP 漏洞的協調處理，在官方公開前先把防護規則推給所有客戶，免費方案也不用自己設定。下面整理自 Cloudflare 官方公告。
時間（台灣時間） | 發生什麼事 |
|---|---|
10 月 20 日 | 漏洞細節提前外流；Cloudflare 之後觀察到有人開始攻擊客戶網站，而且不斷變換攻擊手法想繞過防護 |
10 月 21 日上午 11 點 | Cloudflare 對所有使用 WAF 的網站（含免費方案）預設啟用防護規則 |
10 月 21 日晚上 | PHP 官方公開漏洞並發布修補版本，比 Cloudflare 上防護晚了大約 9 小時 |
Cloudflare 在公告裡提到，他們和 PHP 基金會、OpenAI、Wiz 等單位一起協調處理這個漏洞，所以能在公開前就準備好規則。對免費方案的網站來說，這次不需要做任何設定，只要網站流量有經過 Cloudflare，就自動受到保護。
這也說明了 WAF 的一個關鍵價值：漏洞從公開到被大量攻擊的時間越來越短，這次甚至公開前就有人在試。網站管理者再快，也需要時間盤點、測試、升級；WAF 能把這段空窗期補起來。
為什麼這次的漏洞特別難擋：它的攻擊長得很像正常流量
一句話：這次的攻擊請求，很難光看「長相」就分辨是好是壞，所以 Cloudflare 改成連網站的「回應」一起看。
傳統 WAF 的做法是檢查「送進來的請求」，看到可疑的寫法就擋。但這次的漏洞是靠大量或特製的請求讓 PHP 出錯，單看請求本身，跟正常的大量流量很難區分。規則訂太嚴，正常客人會被誤擋；訂太鬆，攻擊又會漏掉。
Cloudflare 這次推出的新做法叫「完整交易偵測」（官方說明）：同時看「客人送進來什麼」和「網站回了什麼」。用便利商店比喻，以前店員只看客人拿什麼商品到櫃檯；現在連收銀機吐出什麼也一起看，如果發現收銀機被騙開了抽屜，就在錢交出去之前攔下來。
只看請求（傳統做法） | 請求加回應一起看（這次的新做法） | |
|---|---|---|
判斷依據 | 送進來的內容像不像攻擊 | 送進來的內容，加上網站的回應有沒有出現被攻破的跡象 |
優點 | 反應快，能在請求進網站前就擋 | 能確認攻擊「真的成功了」才擋，誤擋正常客人的機會少很多 |
限制 | 攻擊長得像正常流量時，容易誤擋或漏掉 | 請求已經進到網站，只能擋住回應，不能取代修補 |
最後一列很重要：新做法能擋住「攻擊者拿到結果」，但攻擊請求已經碰到你的網站了。這就是為什麼 Cloudflare 自己也一再強調，WAF 是多一層保護，修補 PHP 才是根本。
WAF 平常都在擋什麼？五種最常見的網站攻擊
一句話：PHP2Shell 這種大漏洞不常有，WAF 平常大部分時間在擋的，是每天都有的自動化攻擊。只要網站上線，不管規模多小，幾乎每天都會被機器人掃過一輪。
攻擊類型 | 白話解釋 | 生活比喻 | 沒擋住的後果 |
|---|---|---|---|
猜密碼（暴力破解） | 機器人用常見帳號密碼組合，一直嘗試登入網站後台 | 小偷拿一大串鑰匙一支一支試 | 後台被登入，網站被改、被放惡意程式 |
找設定檔 | 機器人在網站上找不小心留下的備份檔、設定檔 | 小偷翻你家門口的地墊找備用鑰匙 | 資料庫密碼、金鑰外洩 |
SQL 注入 | 在表單或網址裡夾帶指令，騙網站把資料庫內容吐出來 | 在點餐單上偷寫「順便把收銀機打開」 | 會員資料、訂單資料被撈走 |
跨站腳本（XSS） | 在留言或表單裡塞惡意程式，讓其他訪客的瀏覽器執行 | 在公布欄貼一張會讓看到的人上當的假公告 | 訪客的登入狀態被偷、被導到釣魚網站 |
利用已知漏洞 | 針對網站使用的軟體版本，用公開的漏洞直接攻擊 | 知道某款門鎖有設計瑕疵，專挑裝這款鎖的門 | 主機被接管，這次的 PHP2Shell 就屬於這一類 |
這五種攻擊的共通點是「大量、自動、不挑對象」。攻擊者會對整個網路掃一遍，看誰的門沒鎖好，你只是剛好在名單上。所以「我們公司很小，駭客不會有興趣」這個想法是行不通的，小網站反而常因為沒人維護而成為最容易得手的目標。
WAF 擋這些攻擊的方式，主要是靠「已知攻擊的樣子」加上「異常行為」來判斷。例如同一個來源在一分鐘內嘗試登入幾百次，或請求裡出現典型的注入寫法，就直接攔下。好的 WAF 服務會持續更新這些判斷規則，像這次 Cloudflare 在漏洞公開前就推出新規則，就是這種持續更新的價值。
WAF 能做什麼、做不到什麼
一句話：WAF 是幫你爭取時間的保全，修門鎖還是要靠更新。把它當成唯一防線，是最常見的誤解。
WAF 做得到 | WAF 做不到 |
|---|---|
在修補前擋下已知的攻擊手法 | 修好網站本身的漏洞 |
擋下大量常見攻擊，例如猜密碼、掃描漏洞、注入攻擊 | 保證擋住每一種變形的新攻擊 |
讓你從後台看到誰在攻擊、攻擊了什麼 | 保護沒有經過它的流量，例如有人直接連主機的位址 |
降低網站被入侵與資料外洩的機率 | 處理已經被入侵的網站，例如清除後門 |
中間那列「直接連主機的位址」特別容易被忽略。如果攻擊者知道你主機的真實位址，就能繞過 WAF 直接打。所以用 WAF 的網站，主機最好設定成只接受經過 WAF 的流量。網站常見的攻擊類型，可以參考 OWASP 整理的十大網站風險。
⚠️常見誤解：裝了 WAF 就不用更新
這次 Cloudflare 的公告特別提醒，就算有 WAF 保護，PHP 還是要升級。WAF 擋的是已知的攻擊樣子，攻擊者一直在變換手法，總有可能漏掉。修補完成之前開著 WAF、修補完成之後也繼續開著，兩者一起才是完整的做法。升級步驟可以看 PHP2Shell 修補實錄。
導入 WAF 前要注意的三件事
一句話：WAF 開下去之前，先想好「誤擋怎麼辦」。最常見的抱怨是：防護一開，正常客人也被擋在門外。
注意事項 | 為什麼 | 建議做法 |
|---|---|---|
先觀察再封鎖 | 規則太嚴會誤擋正常客人，例如表單送出失敗、後台進不去 | 新規則先用「只記錄不封鎖」跑一兩週，確認沒有誤擋再改成封鎖 |
留一條誤擋的申訴管道 | 客人被擋了通常不會告訴你，只會默默離開 | 在錯誤頁放上客服聯絡方式，定期看被擋的紀錄有沒有正常客人 |
主機只收經過 WAF 的流量 | 攻擊者知道主機真實位址就能繞過 WAF | 主機的防火牆只開放給 WAF 服務的來源，關掉其他直接連線 |
另外，WAF 也會影響一些正常但「長得像攻擊」的操作。例如網站後台貼上一段程式碼、上傳大檔案、串接第三方服務的回呼。導入時請負責的人把這些情境都測一輪，必要時針對特定路徑調整規則，不要為了方便就整個關掉。
萬一真的被攻破，WAF 幫不上忙，要照被駭的止血步驟處理，可以參考 WordPress 網站被駭怎麼辦。如果網站是交給廠商維護，WAF 的設定與攔截紀錄的檢視，也建議寫進維護範圍，維護合約範本 有 SLA 與責任範圍的寫法。
預算有限的公司，可以從免費方案開始：先讓流量經過 WAF，看看後台的攔截紀錄，你通常會很驚訝每天有多少攻擊被擋下。有了這些數字，再決定要不要升級付費方案，會比憑感覺花錢實在得多。
我的網站有被 WAF 保護嗎？三步驟自己確認
一句話：先確認流量有沒有經過 WAF，再確認防護有沒有打開，最後看紀錄有沒有在運作。不懂技術的老闆，可以直接把下面這張表交給負責網站的人。
要確認什麼 | 怎麼問負責的人 | 合格的答案 |
|---|---|---|
流量有沒有經過 WAF | 我們的網站有沒有用 Cloudflare 或其他 WAF？ | 有，而且網址是經過代理的狀態 |
防護有沒有打開 | 託管的防護規則有開嗎？是封鎖還是只記錄？ | 有開，而且是封鎖模式 |
有沒有在運作 | 最近一週攔下了多少攻擊？ | 能從後台拿出攔截紀錄 |
會不會被繞過 | 主機能不能被直接連到？ | 主機只接受經過 WAF 的流量 |
Cloudflare 的免費方案已經包含這次的防護，付費方案則有更完整的託管規則（官方說明）。如果網站有會員登入或表單，WAF 搭配表單防機器人機制效果更好，可以參考 表單機器人防護採購指南。
中小企業需要 WAF 嗎？怎麼選
一句話：只要網站有對外開放的表單、登入或購物功能，就值得有一層 WAF。好消息是，最基本的一層不一定要花大錢。
你的網站 | 建議 | 大概的成本 |
|---|---|---|
純形象網站，沒有表單與登入 | 用免費方案的代理加基本防護就夠 | 每月 0 元起 |
有詢價表單、會員登入、部落格後台 | 開啟託管規則，搭配表單防機器人 | 每月約數百到上千元台幣 |
電商、預約、會員系統，存有個資 | 付費方案的完整託管規則，定期看攔截紀錄 | 每月數千元台幣起，依流量與方案而定 |
政府、金融、醫療相關系統 | 依法規要求選用，並搭配弱點掃描與滲透測試 | 依需求報價 |
WAF 只是網站資安的其中一層。完整的做法還包括定期更新、備份、弱點掃描。三種資安檢測的差別，可以參考 弱點掃描、滲透測試、壓力測試差在哪；自動化攻擊會怎麼撈資料，神腦資安事件拆解 有實際案例。Cloudflare 除了 WAF，還能在主機掛掉時先顯示快取頁面，做法可以看 Cloudflare 救援機制實戰。
看到這裡，如果你也在想「我們的網站到底有沒有被保護到」，我們很樂意 聽你聊聊現在網站的狀況，一起看看哪一層最值得先補。
ℹ️我們怎麼看
這次事件讓我們看到一個趨勢：漏洞從外流到被攻擊，已經快到網站管理者來不及反應，3 年內「先擋再修」會變成網站維運的標準做法，WAF 會像防毒軟體一樣成為基本配備。但我們也看過不少人裝了 WAF 就以為高枕無憂，結果網站好幾年沒更新。我們的取捨是：WAF 一定要有，更新流程也一定要跑，兩件事分開檢查。給老闆的判斷工具很簡單：問負責網站的人兩句「我們有 WAF 嗎？」「上次更新是哪一天？」兩個都答得出來，才算有人在顧。網站被駭後的處理步驟，可以參考 WordPress 網站被駭怎麼辦；維護廠商該承諾什麼，可以看 維護合約範本。
ℹ️我們做過這件事
這次 PHP2Shell 公告後，我們當天就把自家與代管的網站盤點、回測並升級完成，每站停機不到一分鐘。我們累積了 40+ 企業客製案落地，網站上線後的防護設定、版本更新與資安修補，都是維運的日常。看到這裡，如果你也在想「我們的網站該加哪一層防護」，我們很樂意 聽你聊聊現在的實際情況，一起看看從哪一塊開始最划算。
QWAF 是什麼？
WAF 是網站應用程式防火牆（Web Application Firewall），擋在網站前面檢查每一個請求的內容，把像攻擊的請求擋下來，例如 SQL 注入、跨站腳本與利用軟體漏洞的攻擊。它保護的是網站這一層，跟主機的一般防火牆分工不同。
QWAF 和一般防火牆差在哪？
一般防火牆像大樓門禁，決定哪些連線可以進來；WAF 像大廳保全，會檢查進來的人帶了什麼。一般防火牆擋不住從網站正門進來的攻擊，所以有對外網站的公司兩者都需要。
QCloudflare 免費方案有 WAF 嗎？
有基本的託管防護。這次 PHP2Shell 漏洞，Cloudflare 在漏洞公開前大約 9 小時，就對所有使用 WAF 的網站（含免費方案）自動啟用防護規則，免費方案不需要另外設定，前提是網站流量有經過 Cloudflare。
Q有 WAF 就不用更新網站了嗎？
不行。WAF 擋的是已知的攻擊樣子，攻擊者會一直變換手法，總有可能漏掉，也擋不住直接連到主機的流量。Cloudflare 在這次公告也提醒，有 WAF 保護仍然要升級 PHP。WAF 是幫你爭取修補時間，修補才是根本。
Q怎麼知道我的網站有沒有被 WAF 保護？
問負責網站的人四件事：網站流量有沒有經過 WAF 服務、防護規則有沒有開啟且是封鎖模式、最近有沒有攔截紀錄、主機是不是只接受經過 WAF 的流量。四件都答得出來，才算真的有保護。
AUTHOR
恆遠數位編輯團隊
留言(0)
尚無留言，成為第一個留言的人吧！