# 網站表單垃圾訊息暴增，直接加驗證碼就好嗎？先做五項診斷

- 網址：https://www.edgedeploy.tw/blog/website-form-spam-bot-protection-checklist
- 分類：中小企業資安
- 發佈日期：2026-08-26
- 更新日期：2026-08-26
- 作者：邊境部署

> 詢價、預約表單被垃圾訊息塞滿時，直接加驗證碼可能擋不住後端入口，也可能讓真實客戶放棄。本文帶企業主用五項證據判斷來源、攔截層、誤擋與後續成本，再比較分層防護方案。

網站開始投放廣告後，詢價表單突然每天出現大量英文連結、重複內容或假電話。業務花時間逐筆刪除，真正的客戶詢問被埋在其中，網站廠商於是提議「加一個驗證碼就好」。但幾天後垃圾訊息仍然出現，真實客戶反而回報表單一直轉圈或無法送出。

問題不只是畫面上少了一個核取方塊，而是企業尚未確認自動程式從哪個入口送資料、攔截是否真的在伺服器，也就是網站接收與處理資料的後端生效，以及正常名單被擋掉時能不能被發現。CAPTCHA（用簡短挑戰區分真人與自動程式的驗證機制）只是其中一層，不是完整答案。

可以把表單想成展場報到。入口機台顯示「已驗證」，不代表會場門口真的檢查了通行憑證；若旁邊的工作通道沒有人查驗，自動程式仍可繞過機台直接進場。反過來，若要求每位訪客反覆解題，真正想進場的人也可能先離開。

## 先分清楚垃圾內容、濫用入口與真正攻擊

表單垃圾訊息通常是自動程式重複提交推銷、連結或無效資料。它可能只增加整理成本，也可能連帶觸發通知信、簡訊、客戶關係管理系統與自動回覆，消耗額度並污染名單。若提交量突然放大到拖慢服務，或內容嘗試操控網站與下游系統，風險就不再只是垃圾郵件。

開放全球網頁應用程式安全計畫（OWASP）的自動化威脅資料，把表單寄信垃圾內容列為自動化濫用情境。OWASP 的輸入驗證指引也提醒，瀏覽器端的 JavaScript，也就是負責網頁互動的程式檢查，可以被繞過，安全判斷必須在伺服器收到資料時再次執行。這代表「畫面上有驗證」與「提交入口有防護」必須分開驗收。

## 用五個問題找出真正缺口

1. **垃圾訊息從哪張表單進來？** 記錄表單網址、時間、內容特徵與後續去向，分辨是單一活動頁、全站共用元件，還是已停用卻仍可直接呼叫的舊入口。
2. **伺服器有留下接受與拒絕紀錄嗎？** 請廠商展示一次正常提交、一次刻意失敗及一次重複提交，確認拒絕發生在真正處理資料之前，不只是在畫面隱藏送出按鈕。
3. **驗證結果有在後端確認嗎？** 以 Cloudflare Turnstile 防機器人服務為例，官方文件明確要求伺服器呼叫驗證服務；只有前端元件，攻擊者仍可直接送出任意權杖，也就是聲稱已通過檢查的一次性憑證。
4. **真實客戶被擋時看得到嗎？** 至少保留不含完整個資的失敗原因與數量，測試手機、較慢網路、常見瀏覽器及輔助操作。只看垃圾變少，可能把有效詢問一起當成成功攔截。
5. **垃圾提交觸發了哪些成本？** 盤點寄信、簡訊、試算表、客服分派、客戶關係管理系統及廣告轉換。前端擋住一筆，不代表下游沒有重複紀錄或計費。

## 方案不是越嚴越好，而是分層降低誤擋

低量、固定格式的垃圾內容，可以先用伺服器欄位驗證、提交速度與重複內容規則，再加入誘餌欄位，也就是正常使用者不會填、但簡單機器人常會填入的隱藏欄位。它成本較低、干擾較少，但無法阻擋會模擬真人操作的程式，也要確認不會影響輔助工具。

數量持續上升時，可在伺服器或網站入口加入速率限制，控制同一來源短時間可提交的次數；對可疑提交先隔離，不要直接永久刪除。需要防機器人服務時，可選擇依風險才要求互動的模式，並把失敗、逾時、服務暫時不可用時的處理寫清楚。Cloudflare 的現行文件提供受管理、非互動與隱形三種模式，但無論選哪一種，都仍要完成後端驗證。

最便宜的外掛，也就是安裝在網站平台上的附加功能，可能只加前端元件，沒有伺服器紀錄、誤擋監測與下游去重。較完整的方案會增加建置與維護成本，卻能回答「擋了什麼、漏了什麼、是否影響真實客戶」。企業不必一開始購買最複雜的機器人管理服務，應先依提交量、名單價值與可承受的誤擋風險逐層增加。

## 今天先建立一份可比較的基準

挑一段仍能代表正常營運的期間，把提交分成有效詢問、明顯垃圾、需要人工判斷與系統失敗四類。記錄各類數量、來源表單、時間分布及是否進入信箱或客戶系統。不要把完整電話、信箱或訊息內容傳到不必要的分析工具，範例也要先遮蔽個資。

要求廠商在測試環境交付四項證據：正常客戶可以完成、簡單自動提交被拒絕、驗證失敗不會觸發下游通知、管理者能看到異常數量與原因。上線後再比較垃圾量、有效詢問與表單失敗，而不是只看「驗證碼已安裝」。如果防護造成有效詢問下降，必須能快速調整規則或暫時退回前一層。

## 自行處理的邊界與接洽準備

企業可以自行整理垃圾訊息樣本、來源表單與下游系統，確認目前是否有驗證元件，也能用真實裝置完成幾次正常測試。若不知道提交入口在哪裡、表單串接寄信或客戶系統、垃圾量已影響服務、沒有拒絕紀錄，或無法衡量真實客戶是否被擋，就需要網站、資安與名單流程一起盤點。

接洽前可準備表單網址、已遮蔽個資的垃圾樣本與時間、廣告活動、目前外掛或防護服務、主機與網站平台、下游寄信或客戶系統、最近正常詢問的大致基準，以及不能中斷的營運時段。邊境部署可以協助把這些資料整理成入口圖、分層防護與驗收清單，先降低最明確的濫用，再用證據決定是否需要更進階的服務。

### 查證來源

- [OWASP：Automated Threats to Web Applications](https://wiki.owasp.org/images/a/a2/Automated-threats.pdf)
- [OWASP Cheat Sheet Series：Input Validation](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html)
- [Cloudflare Turnstile：Validate the token](https://developers.cloudflare.com/turnstile/get-started/server-side-validation/)
- [Cloudflare Turnstile：Widgets](https://developers.cloudflare.com/turnstile/concepts/widget/)