問い合わせフォームのスパム対策は「段階的に」行う
ホームページを運用していると、問い合わせフォームから突然スパムメールが大量に届くことがあります。
特にWordPressサイトでは、問い合わせフォームが自動投稿ボットに見つかると、数分おきに大量のメールが届くことがあります。
今回も、製品問い合わせフォームから海外の自動投稿と思われるスパムが連続して届く事例がありました。
フォームのスパム対策というと、すぐにGoogle reCAPTCHAを入れる、海外IPをブロックする、入力制限を強くする、といった対応を考えがちです。
ただし、ここで気をつけたいのは、スパム対策を強くすればするほど、通常のお客様の問い合わせ体験にも影響が出る可能性があるということです。
そのため、問い合わせフォームのスパム対策は、いきなり強い制限を入れるのではなく、ユーザーへの影響が少ないものから段階的に行うのが基本です。
大量スパムが来たからといって焦って行動しないこと
対策することはリスクと隣り合わせ
軽微な対応から様子を見ながら、段階的に進めていくのが鉄則
スパム対策で一番避けたいこと
問い合わせフォームの目的は、お客様からの問い合わせを受け取ることです。
スパムを止めるために対策を入れた結果、通常のお客様が問い合わせしにくくなったり、送信できなくなったりしては本末転倒です。
たとえば、以下のような対策は効果がある一方で、通常ユーザーにも影響する可能性があります。
- reCAPTCHAを入れる
- 「私はロボットではありません」のチェックを入れる
- 日本語が含まれない投稿を弾く
- 本文の最低文字数を長くする
- URLを含む投稿を弾く
- 海外IPを制限する
- 特定の文字列を含む投稿をブロックする
これらはスパム対策として有効な場合がありますが、やりすぎると正規の問い合わせまで止めてしまう可能性があります。
たとえば、日本語チェックを入れると、英語のみ・ローマ字のみの問い合わせは送信できなくなる可能性があります。
本文の最低文字数を上げすぎると、「在庫ありますか？」「見積希望です」などの短い正規問い合わせが弾かれる可能性があります。
reCAPTCHAも、ユーザーに余計な操作を求める場合があり、問い合わせ完了率に影響することがあります。
そのため、スパム対策は「強ければ良い」ではなく、通常のお客様が問い合わせできる状態を維持しながら、必要な範囲で段階的に強めることが大切です。
基本方針：まずは影響が少ない対策から
スパム対策は、以下のような順番で検討すると安全です。
- 現状把握
- フォーム標準機能でできる軽い対策
- 入力項目の見直し
- メール側の振り分け
- ハニーポットなどユーザー負担の少ない対策
- reCAPTCHAなどの本対策
- WAF・サーバー側の対策
- フォーム構成の見直し
いきなり強い対策を入れるのではなく、まずは小さく対応し、一定期間様子を見る。
それでも止まらなければ次の段階へ進む、という考え方です。
第1段階：まず状況を確認する
最初に行うべきことは、どのフォームからスパムが届いているかを確認することです。
確認するポイントは以下です。
- どのフォームから送信されているか
- 件名は何か
- 送信間隔はどれくらいか
- どの項目にどんな内容が入っているか
- 本文は英語だけか、日本語を含むか
- 同じメールアドレスや電話番号が使われているか
- SQLインジェクションのような不自然な文字列が含まれているか
- 求人応募、製品問い合わせ、資料請求など複数フォームにまたがっているか
今回のように、特定の製品問い合わせフォームから集中して届いている場合は、まずそのフォームを優先して確認します。
逆に、複数のフォームから同時に届いている場合は、フォーム単体ではなく、サイト全体でのスパム対策を考える必要があります。
第2段階：フォーム標準機能でできる軽い対策
最初に行う対策は、フォームプラグインの管理画面からできる範囲に留めるのが安全です。
たとえば、MW WP FormやContact Form 7などでは、以下のような設定ができる場合があります。
- 必須項目の確認
- メールアドレス形式のチェック
- 電話番号形式のチェック
- 文字数制限
- 最小文字数の設定
- 確認画面の有無
- 送信前の確認項目追加
今回のケースでは、スパムの本文が「20」のように極端に短いものが多かったため、お問い合わせ内容欄に最低文字数のチェックを追加しました。
たとえば、本文を5文字以上にするだけでも、極端に短い自動投稿は弾ける可能性があります。
ただし、最低文字数を上げすぎると正規問い合わせにも影響します。
「在庫ありますか？」のような短い問い合わせもあり得るため、最初は5文字程度、必要に応じて10文字程度までが現実的です。
第3段階：フォームに確認項目を追加する
reCAPTCHAよりも軽い対策として、フォームに送信確認用の項目を追加する方法があります。
たとえば、
「内容を確認しました」
「スパム対策のため、確認にチェックを入れてください」
といったチェックボックスを設置し、必須項目にします。
これはユーザーに少し手間をかけますが、reCAPTCHAほど大きな負担ではありません。
単純なボットであれば、このような確認項目で止まることもあります。
ただし、すべての項目を自動入力するタイプのボットには突破される可能性があります。
そのため、あくまで軽めの追加対策として考えます。
第4段階：メール側で一時的に振り分ける
サイト側で完全に止める前に、受信箱が埋もれないようにすることも大切です。
Gmailなどでは、スパムに共通する文字列をもとにフィルタを作成できます。
たとえば、今回のようなスパムであれば、
- testing@example.com
- Laguna Street
- 555-666-0606
- 件名「HPから製品のお問い合わせ」
- 本文に特定の不自然な文字列が含まれる
などを条件にして、ラベル付けやアーカイブを行うことができます。
これは根本対策ではありませんが、通常のお問い合わせが埋もれるリスクを下げるという意味では有効です。
特にスパムが大量に届いている時は、サイト側の対応と並行して、メール側の整理も検討します。
第5段階：日本語チェックなどの入力制限を検討する
海外からの自動投稿が多い場合、本文に日本語が含まれていない投稿を弾く方法があります。
たとえば、
「お問い合わせ内容に、ひらがな・カタカナ・漢字のいずれかが1文字も含まれていない場合は送信不可」
という条件です。
これは海外スパムには有効な場合があります。
ただし、通常のお客様にも影響する可能性があります。
特に以下のようなケースは弾かれる可能性があります。
- 英語のみの問い合わせ
- 外国籍のお客様からのローマ字問い合わせ
- 型番や数字だけの問い合わせ
- 短いメモのような問い合わせ
そのため、日本語チェックは便利ですが、導入には注意が必要です。
また、WordPressのフォームが商品詳細ページと連動している場合や、テンプレート内で商品名を引き渡している場合は、入力制限の追加によってフォームの動作に影響が出る可能性があります。
そのため、本番サイトで急いでPHPコードを追加するような対応は慎重に行うべきです。
今回のケースでは、日本語チェックも検討しましたが、フォームが商品詳細ページから商品名を引き渡す特殊な構成だったため、無理に追加せず見送りました。
通常のお客様からのお問い合わせを止めないことを優先した判断です。
第6段階：ハニーポットを検討する
ハニーポットとは、ユーザーには見えない入力欄をフォーム内に用意し、そこに入力があった場合にスパムと判定する方法です。
人間のユーザーには見えない項目なので、通常の問い合わせには影響しにくいのがメリットです。
一方で、ボットはフォーム内のすべての項目を埋めようとすることがあるため、ハニーポットに引っかかる場合があります。
reCAPTCHAと違って、ユーザーに追加操作を求めにくい点がメリットです。
ただし、すべてのボットに効くわけではありません。
また、フォームプラグインやテーマとの相性確認も必要です。
第7段階：Google reCAPTCHAを導入する
スパムが継続する場合は、Google reCAPTCHAの導入を検討します。
reCAPTCHAは、ロボットによる自動投稿を抑制する代表的な方法です。
今回のように短時間で大量に送られる自動投稿型のスパムには、有効な可能性が高いです。
ただし、reCAPTCHAを入れれば完全にゼロになるわけではありません。
また、導入には以下の確認が必要です。
- Google側でサイトキー・シークレットキーを取得する
- フォームプラグイン側に設定する
- 入力画面で正しく動作するか確認する
- 確認画面で問題が出ないか確認する
- 完了画面まで進めるか確認する
- 管理者宛メールが届くか確認する
- 自動返信メールがある場合は正常に届くか確認する
- 商品名などの引き渡し項目が壊れていないか確認する
- スマホ・PCの両方で送信テストを行う
- キャッシュや高速化設定の影響を確認する
特にWordPressで、商品詳細ページからフォームに商品名を引き渡しているような構成では、単純にreCAPTCHAを追加するだけでは済みません。
設置後に、フォーム全体の動作確認が必要です。
そのため、reCAPTCHA導入は「軽い応急処置」ではなく、ある程度作業時間を確保して行う本対策と考えた方が安全です。
第8段階：WAFやセキュリティプラグイン側で制限する
Wordfenceなどのセキュリティプラグインが入っている場合は、同じIPからの大量アクセスを制限できることがあります。
また、サーバー側のWAFで不正なリクエストをブロックできる場合もあります。
ただし、ボットはIPを変えてくることも多いため、IPブロックだけで完全に止まるとは限りません。
また、WAFを強くしすぎると、管理画面の保存や通常のフォーム送信までブロックされることがあります。
今回も、管理画面でスパム対策用のコードを保存しようとした際に、サーバー側のセキュリティ機能が反応し、403エラーが出る場面がありました。
これはサイトを守る機能としては正常な反応とも言えますが、本番サイトでの作業には注意が必要です。
第9段階：フォーム構成そのものを見直す
スパムが継続する場合は、フォームプラグインやフォーム構成自体の見直しも検討します。
たとえば、
- フォームプラグインを変更する
- フォームの設置場所を見直す
- 商品詳細ページとの連動方法を変更する
- フォーム数を整理する
- LINEや電話など別導線を強化する
- 問い合わせフォームの項目を見直す
などです。
ただし、フォーム移行は作業範囲が大きくなります。
商品名の引き渡し、確認画面、完了画面、メール文面、自動返信、管理者宛通知など、確認すべき項目が多いため、最後の選択肢として考えます。
スパム対策の判断基準
スパム対策を行う際は、以下のように考えると判断しやすくなります。
すぐ行ってよい対策
- 送信元フォームの確認
- スパム内容の確認
- メール側のフィルタ設定
- フォーム標準機能での最低文字数チェック
- 必須項目の見直し
- 通常問い合わせに影響しにくい確認項目の追加
慎重に行う対策
- 日本語チェック
- URL禁止
- 特定キーワードの禁止
- 海外IP制限
- PHPコードによる独自バリデーション
- セキュリティプラグインの強い制限
作業時間を確保して行う対策
- Google reCAPTCHA導入
- ハニーポット導入
- フォームプラグインの変更
- サーバー側WAF設定変更
- フォーム全体の再設計
まとめ
問い合わせフォームのスパム対策は、焦って強い制限を入れすぎないことが大切です。
スパムを止めることは重要ですが、それ以上に大切なのは、通常のお客様が問題なく問い合わせできる状態を維持することです。
そのため、基本方針は以下です。
- まず状況を確認する
- 影響の少ない対策から行う
- 一定期間様子を見る
- それでも止まらなければ次の対策を行う
- ユーザー体験を下げる対策は慎重に判断する
- 本格的な対策はバックアップとテストを前提に行う
フォームのスパム対策は、一度で完璧に止めるものではなく、状況に応じて段階的に調整していくものです。
特に、商品詳細ページと連動しているフォームや、確認画面・完了画面を持つフォームでは、対策を追加することで別の不具合が起きる可能性もあります。
「スパムを止める」だけでなく、「正規のお客様を止めない」こと。
これを前提に、段階的に対策していくのが安全です。