問い合わせフォームを公開してしばらくすると、意味の分からない英文や、広告のURLばかりが書かれた投稿が届くようになることがあります。1日に数件でも、担当者が本物の問い合わせと見分ける手間がかかり、大事な相談を見落とす原因になります。

ただ、フォームのスパム対策で考えたいのは、届く迷惑だけではありません。フォームの仕組みを悪用されて、自社のメールサーバーから第三者に迷惑メールを送らされる被害もあります。こちらは、自社が加害者のように見えてしまうため、影響がより大きくなります。

この記事では、2つの迷惑への対策を、仕組みごとの向き不向きとあわせて整理します。入力項目の減らし方など、フォームの使いやすさの改善や、問い合わせメールが届かないときの確認方法は別の記事で扱っています。

IPA（情報処理推進機構）は、「コンピュータウイルス・不正アクセスの届出事例［2020年上半期（1月～6月）］」で、問い合わせフォームの自動返信機能が悪用された事例を紹介しています。

届出者のウェブサイトには、問い合わせフォームに投稿すると、投稿者に受付のメールが自動で返信される機能がありました。攻撃者は、投稿者氏名の欄に不正なサイトのURLを、メールアドレスの欄に不特定多数のメールアドレスを入力しました。自動返信メールには投稿者氏名がそのまま記載される仕様だったため、フィッシングサイトと思われるURLが書かれたメールが10万件以上送信されました。

さらに、大量の不正なメールを送ったことで、届出者のメールサーバーが公開ブロックリストに登録され、正規の業務メールの送信にも支障が出たとされています。 IPAはこの事例の着目点として、機械的な動作による投稿を排除する仕組みの導入、自動返信するメールに投稿者が入力した文字列を含めないこと、URLのような文字列を受け付けないことを対策として挙げています。

自動返信メールは、多くのホームページで使われている便利な機能です。だからこそ、返信の文面に何を含めているかを一度確認しておく価値があります。

IPAの「安全なウェブサイトの作り方」では、メールヘッダ・インジェクションという脆弱性が解説されています。利用者が入力した内容を管理者宛てにメールで送る機能を持つウェブサイトが影響を受け、該当する機能として「問い合わせページ」や「アンケート」が挙げられています。

この脆弱性があると、外部から改行コードを差し込まれて、任意の宛先にメールを送信する迷惑メールの中継に悪用されるおそれがあります。IPAが示す根本的な解決策は、メールヘッダを固定値にして、外部からの入力はすべてメール本文に出力することです。メールヘッダを固定値にできない場合は、実行環境や言語に用意されているメール送信用のAPIを使うことが挙げられています。

独自に作ったフォームや、長く更新していないフォームのプログラムを使っている場合は、reCAPTCHAなどを入れる前に、この点を制作会社や保守の担当者に確認してもらってください。

Googleが提供するreCAPTCHAは、フォームに入れられるスパム対策としてよく使われています。公式ドキュメントでは、ウェブサイト向けに次の種類が案内されています。
　 reCAPTCHA v2（チェックボックス）：「私はロボットではありません」にチェックを入れてもらい、必要に応じて画像を選ぶなどのチャレンジを求める
　reCAPTCHA v2（非表示バッジ）：チェックボックスを押す必要はなく、送信ボタンを押したときに判定し、疑わしい場合にだけチャレンジを求める
　reCAPTCHA v3：利用者の操作を求めず、リクエストごとに0.0から1.0のスコアを返す。

1.0は適切な操作、0.0はbotの可能性が非常に高いことを表す v3は利用者に操作を求めない代わりに、返ってきたスコアでどう扱うかをサイト側で決める必要があります。公式ドキュメントでは、管理コンソールでトラフィックを確認してしきい値を決める方法が案内されており、しきい値の例として0.5が示されています。スコアが低い送信をすぐに拒否するのか、受け付けたうえで担当者の確認に回すのかは、問い合わせの性質によって判断します。

reCAPTCHAを入れるときは、次の点も確認しておきます。
　 無料で使える範囲：公式FAQでは、reCAPTCHA Enterpriseは1か月あたり最大10,000件の評価を無料で利用できると案内されています。料金体系は変わることがあるため、導入時に公式の料金ページを確認してください
　バッジの扱い：画面の右下に表示されるバッジは、利用の流れの中でreCAPTCHAを使っていることを明示すれば非表示にでき、その場合に表示する文言が公式FAQで示されています
　Cookie：reCAPTCHAはリスク分析のために必要なCookie（_GRECAPTCHA）を設定すると公式FAQに書かれています

外部のサービスを使うことになるため、ホームページのプライバシーポリシーや、外部送信に関する公表の内容に反映が必要かどうかも確認してください。

ハニーポットは、人には見えないように隠した入力欄をフォームに置き、そこに何かが入力されていたら機械による送信と判断する方法です。自動で投稿するプログラムは、フォームの入力欄をすべて埋めようとすることが多いため、その性質を利用します。

W3Cの文書「Inaccessibility of CAPTCHA」（2021年12月のGroup Draft Note）では、ハニーポットについて、手作業で書いたマークアップでも簡単に実装でき、検討すべき方法だとしています。そのうえで、ハニーポットで十分なら、機械による攻撃の証拠が出てくるまではハニーポットを使うという考え方が示されています。

利用者が何も操作しなくてよいため、フォームの使いやすさを損ないにくい点が長所です。一方で、隠した入力欄を読み飛ばすように作られたプログラムには効きません。画面の読み上げソフトを使う人が隠した入力欄に気付いて入力してしまわないよう、見出しや説明の付け方にも配慮が必要です。

先ほどのW3Cの文書では、ゆがんだ文字の画像を読ませるなど、利用者に作業を求める方式は、その性質上、障害のある多くの人を利用から締め出してしまうと指摘しています。また、よく使われるCAPTCHAの方式の多くが、以前ほど効果的でも安全でもなくなっているという研究結果にも触れています。

問い合わせフォームは、見込み客にとって最初の接点です。スパム対策のために、本当に相談したい人が送信できなくなっては本末転倒です。利用者に作業を求める対策は、他の方法で防ぎきれないときに限って使うのが基本になります。

入力欄の制限や、送信を受け付けた後の処理でも、迷惑な投稿を減らせます。

　・氏名欄や会社名欄ではURLのような文字列を受け付けない
　・本文に含められるURLの数に上限を設ける
　・同じ送信元からの短時間での連続送信を制限する
　・自動返信メールには、投稿者が入力した氏名や本文を含めず、定型の文面にする

W3Cの文書でも、投稿の頻度を制限する方法や、一定の基準を超えた投稿を自動で除外し、疑わしいものを人の確認に回すスパムフィルターの方法が紹介されています。

入力制限は、厳しくしすぎると本物の問い合わせを弾いてしまいます。例えば、本文にURLを書けないようにすると、「このページについて質問です」という相談ができなくなります。どこまで制限するかは、実際に届いている迷惑な投稿の傾向を見て決めるのが確実です。

どの対策にも長所と短所があるため、1つで完璧に防ぐより、負担の少ないものから組み合わせる考え方が現実的です。

　1.フォームの作りに脆弱性がないか、自動返信の文面に入力内容をそのまま含めていないかを確認する
　2.ハニーポットや入力制限など、利用者に負担のない対策を入れる
　3.それでも迷惑な投稿が多い場合に、reCAPTCHA v3や非表示バッジなど、操作を求めにくい方式を加える
　4.チェックボックスや画像選択など、操作を求める方式は最後の手段として検討する

対策を入れた後は、テストの送信をして、本物の問い合わせが問題なく届くことを確認します。スパム対策を入れた直後に問い合わせが急に減った場合は、対策が正しい送信まで止めている可能性があります。

・自動返信メールに入力された氏名や本文をそのまま載せている
・reCAPTCHAを入れたが、サーバー側で結果を確認する処理がなく、実際には機能していない
・対策を強くしすぎて、本物の問い合わせまで弾いていることに気付かない
・迷惑な投稿の件数を記録しておらず、対策の効果を判断できない
・外部サービスを導入したのに、プライバシーポリシーの記載を見直していない

問い合わせフォーム改善のポイント｜入力項目・導線・離脱防止の考え方
ホームページの問い合わせメールが届かない原因｜フォーム設定と送信ドメイン認証（SPF・DKIM・DMARC）の確認方法
アクセス解析タグと外部送信規律｜自社ホームページが対象になるかの確認方法