問い合わせフォームの迷惑投稿には、自動送信を減らす対策と、送られた内容を判定する対策があります。大量の連続投稿なら送信回数制限やボット対策、通常の操作で届く営業文面なら内容判定や保留処理が中心になります。

どちらの場合も、入力値の検証や送信制限はサーバー側に必要です。画面に対策用のJavaScriptを置くだけでは、フォーム画面を開かずに直接送信されるリクエストを防げません。一方、厳しすぎる判定は本来の問い合わせまで止めるため、投稿の種類に合う対策を選ぶことが大切です。

届いている投稿の種類で対策が変わります

同じ本文が短時間に大量に届くなら、自動送信の可能性があります。送信回数制限やボット判定が有効な候補です。少数でも毎回異なる営業文面が届く場合は、操作の速さだけで見分けるのは難しく、内容を判定する仕組みが必要になります。

不正なコードや極端に長い文字列が送られている場合は、迷惑営業とは別に、フォームの脆弱性を探す攻撃を疑います。入力検証、フォーム本体の更新、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も保守対象です。迷惑投稿が減っていても、古い処理の脆弱性が修正されるわけではありません。

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

強く止めるより、正規の問い合わせを残せることが大切です

対策後は、通常の内容でフォームを送信でき、担当者へ届くことを確認します。保存機能がある場合は保存先にも残るかを見ます。社内では動いても、スマートフォンの回線や異なるブラウザーで判定が変わることがあります。

迷惑投稿が減らなければ、すぐ全体の制限を厳しくするのではなく、通過しているのが自動投稿か、営業文面かを見直します。内容判定に迷う投稿を保留して確認できる仕組みなら、誤判定からも戻しやすくなります。

フォームへの攻撃を防ぐことと、担当者の受信箱から迷惑営業を減らすことは、役割の違う対策です。両方を分けて整える方が、本来の問い合わせを受け付けながら負担を減らせます。