問い合わせフォームの迷惑送信対策を整える。Turnstileをサーバー側で検証する手順
公開日 ・更新日
問い合わせフォームの迷惑送信対策は、画面にチェックを表示して終わりではありません。Turnstileのトークンはブラウザ側だけで信用せず、フォームを受け取るサーバーで検証します。トークンは短時間で期限が切れ、一度しか使えないため、受信処理の最初に有効性を確かめる設計が必要です。
ブラウザとサーバーの役割を分ける
ブラウザでは、フォーム入力とTurnstileのウィジェット表示を担当します。送信時には発行されたトークンをフォームの他の値と一緒にサーバーへ渡します。ここで「画面にウィジェットが表示された」という情報だけを成功条件にしてはいけません。画面の処理は書き換えられる前提で考えます。
サーバーは、秘密鍵と受信したトークンを使って検証サービスへ問い合わせます。成功、期限切れ、形式不正、すでに使われたトークンなどの結果を受け取り、成功した場合だけ問い合わせの保存や通知へ進めます。検証できないときは、通常の利用者へ再入力を案内し、機密情報や秘密鍵をエラー画面へ出さないようにします。
送信処理を一つずつ確認する
テストでは、正常な送信、トークンなし、期限切れ、同じトークンの再送、入力値が空のケースを分けます。フォーム側がエラーを表示しても、サーバーに問い合わせや通知が残っていないかを確認してください。成功時も、二重送信で同じ問い合わせが二件にならない仕組みを合わせて点検します。
ログには、検証の成否、発生時刻、フォームの種類など、原因を追える最小限の情報を残します。トークン、秘密鍵、問い合わせ本文をそのまま記録しないことが重要です。失敗が急増したときは、ウィジェットの読み込み、サーバーの時刻、検証先への通信、通知先の順に切り分けます。
利用者の行動を止めない
迷惑送信を減らすことだけを優先すると、正しい問い合わせまで止まります。検証失敗時の文言は「送信できません」だけにせず、ページを再読み込みする、入力内容を確認する、別の連絡手段を使うなど次の行動を示します。スマートフォンの回線や古いブラウザでも、入力内容が消えない設計を確認します。
公開後は、実際の送信を一件行い、保存、担当者通知、利用者への完了表示を追跡します。週1回は失敗率と迷惑送信の傾向を見て、検証を弱めずに必要な案内だけを改善します。問い合わせフォームの防御と送信テストを一緒に整えたい方は、COZITOへご相談ください。
関連記事
著者: 松井 勇樹