如何減少查詢表格濫用，同時保留真正客戶的查詢

先辨認損害，不要一開始便加驗證題

公開查詢表格可能以多種方式被濫用：程式大量送出假訊息、把連結送入員工信箱、反覆觸發通知費用，或連續提交同一段內容。第一步是確認實際損害，以及正常查詢通常長甚麼樣。可保留少量已遮蓋個人資料的例子、到達時間和派送結果，但不要為防濫用而額外收集無關個人資料。要分辨惡意高流量、促銷期間的正常繁忙，以及因沒有看到確認訊息而重試的顧客。OWASP 建議先找出受威脅的入口，再分層設防，毋須把所有自動請求當成同一種問題。小企的目標是保護員工處理佇列及回覆時間，同時讓一般顧客仍容易提出問題。

把整條路徑畫在一頁：瀏覽器送出、伺服器核驗、防濫用判斷、儲存或電郵派送、員工審閱、顧客確認。若伺服器尚未接受並排隊處理，頁面已顯示「已送出」，便會帶來錯誤安心。驗證題雖減少信箱垃圾訊息，卻令輔助科技使用者或網絡較慢的顧客失去查詢機會，也只是把問題轉移。應把「已接受的查詢」界定為伺服器有可追蹤紀錄或可靠佇列項目，而且寄件人看到確認；可能是真顧客而被拒的查詢，則應有可恢復的提示，並且不會默默消失。這些定義讓團隊每次改動後都能驗收。

先做伺服器端限制及基本檢查

欄位長度及格式必須在伺服器端核驗，因為機械人可直接傳送請求，不經網頁表格。每個請求可引起的工作也要有限制：訊息長度、附件大小（如有）、對外通知次數和昂貴的資料查詢。按這個表格入口加入速率限制，需要時結合多個訊號。只看 IP 可能誤傷共用網絡的多名顧客，也難擋分散來源；只看電郵地址則可用虛構地址繞過。門檻應依正常提交情況及繁忙時段設定，再用員工控制的測試流量核實。OWASP 把速率限制列為基本控制，同時強調按入口性質及風險漸進處理。目的在於提高大量濫用的成本，並讓真顧客仍有清晰途徑。

隱藏欄位或提交時間檢查或可攔住簡單程式，但不能證明訪客是真人。瀏覽器端檢查只可作提示，不能成為唯一閘口。伺服器紀錄應保留決定類別、時間及簡短請求參照，方便員工查核有爭議的拒絕；不應只為調校過濾規則而長期保存整段訊息或原始裝置指紋，應訂明保留期及查閱權。若表格會發電郵，限制也要涵蓋寄送動作，否則攻擊者仍可用入口大量發信。若團隊看不到有多少請求獲接受、延遲、要求額外驗證或遭拒，就無從判斷新規則是在保護容量，還是在把真正需求藏起來。

有需要才加入額外驗證

若基本控制後垃圾訊息仍多，可考慮只對較可疑的請求增加驗證，而非每位訪客都要過關。Cloudflare Turnstile 之類服務只是一種實作選擇，並不能保證寄件人一定是真人。Cloudflare 明言瀏覽器小工具必須配合伺服器向 Siteverify 核實；單靠畫面上的小工具無法保護入口。伺服器應在接受查詢前驗證傳回的權杖。Cloudflare 文件列明權杖只能使用一次，並在產生後 300 秒內有效。顧客寫長篇查詢時，權杖可能先到期。表格應容許重新取得驗證並再送出，同時保留已輸入的文字；不應要求顧客從頭填寫，或悄悄丟失查詢。

把驗證服務本身視為一項依賴。應在非正式表格測試有效、缺少、逾期、重用權杖及服務出錯等情況，逐一決定顧客會看到甚麼。若第一次查詢其實已被接受，重試不應在員工佇列產生重複個案。當顧客無法完成驗證，也須有真正有人監看的其他聯絡途徑，例如電郵或電話。OWASP 明確建議為面向使用者的驗證題提供無障礙替代方案。亦要檢視私隱通知及供應商安排，了解哪些資料會送到驗證服務。不要聲稱某小工具對每個人都無感或在所有瀏覽器都能用；應按目標受眾測試鍵盤、屏幕閱讀器、手機及較慢網絡。

同時測試垃圾訊息與真顧客重試

假設一家本地維修公司突然收到大量內容相近的查詢。公司在伺服器設定重複提交限制，並把可疑訊息送入審閱佇列，而不是逐封寄給所有技術員。測試時，一名真顧客在共用辦公網絡輸入較長的故障描述，卻因驗證權杖到期而被拒。正確結果應是清楚提示、保留原文、提供新權杖途徑，最後只建立一筆員工紀錄。團隊再模擬快速大量提交，核實通知數量受到控制。這些是示範測試個案，並非某家公司已量得的成效。有效的驗收要兼顧兩面：濫用受到控制，正常顧客亦找得到人。

上線後要訂檢視節奏。初期可每天抽查獲接受和被拒個案，比對員工佇列與伺服器接受紀錄，並記下每次調整規則的原因。保護措施更新後，若正常查詢突然減少，也要追查；不能只因垃圾訊息下降而高興。把所有流量擋住，防濫用圖表或許很好看，業務卻失去聯絡入口。給員工一個簡短程序，讓他們可從隔離佇列救回真查詢，並在重複攻擊時升級處理，同時避免廣泛散播顧客內容。日後若改表格設計、語言、通知服務或驗證供應商，應重跑整條路徑的測試。成果應是可靠的聯絡渠道，而非宣稱機械人從此消失。

為各種結果訂處理方法

實用的處理表不應只有「通過」與「封鎖」。明顯不合規格的輸入，可在到達員工前拒絕，並向真顧客指出要修正哪個欄位；高度確定的重複垃圾訊息可限速或隔離；界線不清的請求，可進入受限制的審閱佇列，而非反覆通知員工。驗證失敗時可要求新權杖，同時保留草稿。驗證供應商故障時，亦要有預先訂好的安排：暫時提供有人監看的其他聯絡渠道、清楚告知表格暫停，或採用受限制的後備規則。選擇取決於查詢敏感程度及流量，不能等故障時才臨時決定。請求若只是被擋或掉進無人查看的佇列，就不可顯示「成功送出」。

員工審閱佇列也要真正可用。每項訊息旁顯示原因類別、提交時間及已遮蓋敏感資料的預覽，讓獲授權者可標記真查詢，並留下可追蹤操作。不要把所有連結或非英文內容自動判作垃圾訊息：香港顧客可能用繁體中文、英文或兩者混寫，也可能貼出與問題有關的產品頁。評估誤擋時，要把這些正常模式納入。若網站同時提供英文和中文表格，應逐條語言路徑測試至員工接收，包括錯誤提示和替代聯絡資料。若規則只通過英文測試，卻漏掉中文查詢，即使整體垃圾訊息下降，仍是業務失敗。

可設一組簡單營運指標：到達入口的請求、伺服器接受的請求、員工實際收到的紀錄、隔離個案、重複提交，以及從審閱中救回的真查詢。這些數字要一起看。員工收到的訊息減少，可能是成功過濾，也可能是電郵整合壞了或錯誤封鎖。重試增加，可能代表顧客看不到確認訊息。調整限制前，先查幾宗完整流程，避免只為信箱整潔而調校，卻讓銷售團隊失去真正商機。量測應屬於該業務，並標示觀察日期；在真正取得資料前，預期成效仍只是假設。