問い合わせフォームの迷惑投稿は、いきなり強いCAPTCHAを全員へ求めるのではなく、発生量と送信パターンを測ります。そのうえで、利用者への影響が小さい対策から重ねます。送信回数の制限と、見えない項目を使う自動投稿判定を先に確認します。サーバー側の入力検証も整え、それでも残る不審な送信へ追加認証を使う方が運用しやすいです。

迷惑な営業投稿と、脆弱性を探す攻撃、通知メールの配送不良は別の問題です。受信箱で迷惑メールへ振り分けるだけではフォームへの負荷は減らず、WAFだけでは業務上正しい形式の営業投稿を判断できません。どの段階で止めるかを分けて考えます。

最初に迷惑投稿の量と正規送信を測る

対策前に、発生時期と対象フォームを確認します。届く量も基準にします。本文と送信時刻を必要な範囲で記録し、接続元やUser-Agentをログで確認します。

処理結果と合わせて、同じ内容の連続送信がないかを見ます。短時間の集中や特定項目への機械的入力も手掛かりです。個人情報を含むログは、閲覧権限と保存期間を決めます。

正規の問い合わせ数も同時に記録します。迷惑投稿だけが減っても、入力しづらくなって利用者まで離脱したら改善とは言えません。送信完了率、担当者が正規と判断した件数、誤って遮断された報告を変更前後で比較します。

通知メールの件数だけでは実際の投稿数を判断できません。フォーム側では保存に成功していても通知だけ届かない場合があります。フォームの送信記録、WebサーバーやWAFのログ、メール配送ログを分けて確認します。通知トラブルは「問い合わせフォームのメールが届かない原因と確認方法」で扱う範囲です。

自動投稿は一つの判定に頼らず入口で減らす

OWASPの自動化対策では、エッジとアプリケーションの対策を組み合わせます。業務処理も含む複数層で考える方法です。一つの対策は回避や誤判定が起こり得るため、役割の異なる軽い判定を重ねます。

フォーム単位のレート制限は、短時間に大量送信される状態を抑える基礎になります。ただし、IPアドレスだけで厳しく制限すると、会社や携帯回線を共有する正規利用者を巻き込む場合があります。接続元とセッションを組み合わせます。送信間隔や同一内容も判定に使い、通常の送信量を見て基準を調整します。

人には表示しない入力欄を置き、機械が埋めた場合だけ除外するハニーポットも利用者への負担が小さい方法です。ページを開いてから送信までが不自然に短い場合を保留にする方法もあります。これらは単独で完全に止める機能ではなく、明らかな自動送信を早い段階で減らすために使います。

CAPTCHAは残った不審な送信への追加確認に使う

画像選択や文字入力を求めるCAPTCHAは、迷惑投稿を減らせる場合があります。一方、視覚や認知の特性によって正規利用者の負担になります。操作環境の影響も受け、代行や自動解析で回避される可能性があります。最初から全員へ常時表示するより、不審な速度や回数を検知したときだけ追加する使い方を検討します。

導入後は、フォームの表示速度とスマートフォンでの操作を確認します。プライバシー表示も検査対象です。JavaScriptを制限した環境での動作も試します。外部の判定サービスが停止したときに、問い合わせを全面的に受けられなくなる構成かどうかも見ます。

対策の強さは問い合わせの価値と被害量で変わります。採用応募や緊急連絡のように一件を失う影響が大きいフォームでは、疑わしい投稿を即時削除せず、保留キューで確認する方法もあります。営業投稿の削減率だけでなく、正規送信を救える運用を残します。

入力値はブラウザーではなくサーバー側で検証する

必須項目や文字数をJavaScriptで確認すると、利用者の入力ミスは減らせます。しかし、ブラウザーを経由せず直接リクエストを送る相手には回避されます。OWASPの入力検証ガイドが示すとおり、セキュリティのための検証はサーバー側で行います。

名前とメールアドレスについて、最小・最大長を定義します。選択項目は許可する値を固定し、本文は文字コードと長さを確認します。自由記述欄へ禁止語を並べるだけでは安全になりません。

受け取った値を画面へ表示するときは、表示先に合うエンコードを行います。通知メールと管理画面にも、それぞれ適切な処理が必要です。

Fromヘッダーへ訪問者が入力したメールアドレスをそのまま使わない方が良いです。ヘッダーへ改行などを混ぜられないように検証し、通知は自社の認証済み送信元から送ります。訪問者のアドレスはReply-Toとして安全に設定し、送信処理が失敗した場合も詳細な内部エラーを画面へ表示しません。

添付ファイルは通常の入力項目より厳しく扱う

添付機能が必要なければ、設置しないことが最も分かりやすい対策です。採用書類などで必要な場合は、拡張子だけを見て受け入れません。OWASPのファイルアップロード対策では、許可する種類とファイルの実体を確認します。容量、ファイル名、保存場所も別の層で制限します。

業務に必要な形式だけを許可し、Content-Typeは利用者側から送られるため単独では信用しません。保存時はサーバー側で新しい名前を付け、可能なら公開領域の外へ置きます。アップロードしたファイルをURLから直接開ける構成では、個人情報の漏えいや不正ファイルの公開につながる可能性があります。

ウイルス検査を利用できる場合も、それだけで安全と断定しません。容量上限と圧縮ファイルの扱いを決めます。保管期間と閲覧権限も必要です。メールへ添付して担当者全員へ転送する運用は複製を増やすため、保護された管理画面から必要な担当者だけが確認する方法も検討します。

WAFと更新はフォーム本体の代わりにならない

OWASPのWAF解説にあるように、WAFはHTTP通信へルールを適用し、SQLインジェクションやXSSなど既知の攻撃パターンを検知する仕組みです。サーバー付属WAFを有効にする価値はありますが、正しい形式で送られた営業文面の良し悪しまでは判断できません。

WAFを有効にしたら、フォーム送信が遮断されていないか、ブロックログを確認します。フォームやプラグインを変更すると、以前は正常だった通信が誤検知される場合があります。除外設定を広げる前に、どのルールと項目が原因かを特定します。

WordPress本体とフォームプラグインは更新を続けます。テーマとPHPも保守対象です。迷惑投稿が減っていても、古い処理の脆弱性が修正されるわけではありません。

更新前のバックアップと検証環境を用意し、送信と保存を確認します。通知と管理画面の表示も試します。

変更後は外部から一件送り、翌週に再判定する

対策を追加した日は、社内回線とスマートフォン回線から正規の問い合わせを送ります。送信完了画面とフォーム側の保存を確認します。通知メールから担当者の返信まで追い、どの層でも欠落していないか確認します。

不審な投稿も削除件数だけで見ません。遮断・保留・通過の内訳を確認します。

一週間ほど運用したら、迷惑投稿数と正規送信成功率を変更前と比較します。効果が足りないときだけ次の層を追加し、誤遮断が増えたら基準を戻します。まず現在のフォームへ外部から一件送信し、送信記録と通知の両方を確認できるか試すことが、安全に改善を始める第一歩です。