お問い合わせフォームのセキュリティ対策｜スパム・情報漏えいを防ぐ

お問い合わせフォームのセキュリティ対策は、①HTTPSで通信を暗号化する、②reCAPTCHAなどでボットによるスパム送信を防ぐ、③入力値をサーバー側で検証し、攻撃に使われないようにする、④受け取った個人情報を安全に保管・管理するの4つが柱です。あわせて、フォームのプラグインやCMSを最新の状態に保つことが前提になります。

フォームは、外部の誰もが自由にデータを送り込める数少ない入口です。対策が不十分だと、大量のスパムが届くだけでなく、自動返信メールが迷惑メールの「踏み台」にされたり、脆弱性を突かれて情報が漏れたりするおそれがあります。

この記事では、フォームで起きる被害の種類から、具体的な対策、個人情報保護法で求められる対応、漏えい時の報告義務までを順に解説します。

お問い合わせフォームで起きるセキュリティ被害

フォームで起きる被害は、「スパムの大量送信」「自動返信メールの悪用」「通信の盗み見」「脆弱性を突いた攻撃」「受信データの漏えい」の5種類に分けられます。 それぞれ原因と対策が異なります。

Webサイトが狙われる理由や攻撃手口の全体像は「Webサイトが狙われる理由と主な攻撃手口」で解説しています。

HTTPS化：フォームの送信内容を暗号化する

個人情報を受け取るフォームは、HTTPSで通信を暗号化することが最低条件です。 HTTPのままでは、送信された氏名やメールアドレスが通信途中で読まれたり、書き換えられたりするおそれがあります。

Google Chromeのヘルプでは、HTTPSを使っていないサイトでは「保護されていない通信（Not secure）」と表示され、送受信する情報を第三者に見られたり変更されたりする可能性があると説明しています（出典：Google Chrome ヘルプ「Check if a site’s connection is secure」）。問い合わせを検討している人がこの表示を見れば、入力をためらう原因になります。

フォームまわりでは、次の点も確認しましょう。

• フォームのページだけでなく、送信先（確認画面・完了画面・送信処理のURL）もHTTPSになっているか
• フォームを外部サービスの埋め込みで設置している場合、その埋め込み先もHTTPSか
• ページ内に http:// の画像やスクリプトが混ざっていないか（混在コンテンツ）

SSL証明書の種類や常時SSL化の手順は「SSL（HTTPS化）とは？必要性と導入手順」で詳しく解説しています。

スパム対策：reCAPTCHAなどのボット対策をどう選ぶ？

フォームへのスパムの多くはプログラム（ボット）による自動送信のため、人間とボットを見分ける仕組みを入れるのが基本です。 代表的なのがGoogleのreCAPTCHAとCloudflareのTurnstileです。

reCAPTCHA：スコアで判定し、画面操作を求めない方式も

reCAPTCHA v3は、利用者に画像選択などの操作を求めず、アクセスごとに0.0〜1.0のスコアを返します。1.0は正常な利用の可能性が高く、0.0はボットの可能性が高いことを示し、既定では0.5をしきい値として使えるとされています。スコアの検証は、ブラウザ側ではなくサーバー側（バックエンド）で行うよう案内されています（出典：Google for Developers「reCAPTCHA v3」最終更新2024年7月10日）。

なお、reCAPTCHAは現在「Google Cloud Fraud Defense」の一部と位置づけられています。無料枠（Essentials）は組織単位で月10,000回の評価までで、組織内のすべてのサイトの利用が合算されます（出典：Google Cloud「Compare features between Google Cloud Fraud Defense tiers」2026年10月6日更新）。複数サイトを同じ組織で運用する場合は、上限に注意しましょう。

Cloudflare Turnstile：CDNを使わなくても導入できる

Cloudflare Turnstileは、CloudflareがCAPTCHAの代替として提供している仕組みで、Cloudflareを経由させずにどのWebサイトにも埋め込めるとされています（出典：Cloudflare Docs「Turnstile」）。料金・プランの条件は公式サイトで確認してください。

どちらを選ぶか

どちらも、利用しているフォームプラグインやフォームサービスが対応しているかで選ぶのが現実的です。また、ボット対策は「導入したから終わり」ではありません。スコアのしきい値が厳しすぎると、本物の問い合わせまで弾いてしまう場合があります。導入後しばらくは、管理画面で判定結果を確認しましょう。

自動返信メールが「踏み台」にされるのを防ぐ

近年、フォームの自動返信メール機能を悪用したスパム配信が問題になっています。エックスサーバーのマニュアルでは、次の手口が説明されています（出典：エックスサーバー「メールフォームを悪用した不正アクセスについて」）。

1. 攻撃者が、メールアドレス欄に無関係な第三者のアドレスを入力する
2. 本文欄にフィッシングサイトのURLや広告を書き込んで送信する
3. フォームの自動返信機能により、そのスパムが第三者に届く

被害として、サーバーのIPアドレスの評判が下がってブラックリストに登録され、正常なメールまで送れなくなるおそれがあるとされています。対策として、reCAPTCHAの導入、自動返信機能の無効化、WordPress・プラグイン・テーマの更新、脆弱性情報の確認、不審なファイルの確認が挙げられています（出典：同上）。

自動返信をやめると、問い合わせた人が「届いたか分からない」と不安になる場合があります。自動返信を残すなら、本文に入力内容をそのまま載せない（「お問い合わせを受け付けました」という定型文のみにする）設定にすると、スパムの文面を第三者に届けにくくなります。

入力値の検証：フォーム経由の攻撃を防ぐ

フォームに入力された値は「信頼できないデータ」として扱い、サーバー側で検証することが基本です。 ブラウザ側のチェックは便利ですが、簡単に回避できます。

ブラウザ側のチェックだけでは不十分

OWASP（Webアプリケーションのセキュリティに関する国際的なコミュニティ）の入力値検証チートシートは、ブラウザで同じ項目をチェックしていても、サーバー側でも検証するよう求めています。また、悪意ある文字列をすべて見つけようとするのではなく、「許可する形式」を定めてそれ以外を拒否する考え方を勧めています（出典：OWASP Cheat Sheet Series「Input Validation Cheat Sheet」）。

たとえば次のような検証です。

• 電話番号欄：数字とハイフンのみ、桁数の上限を設ける
• 郵便番号欄：決まった桁数の数字のみ
• 選択項目：用意した選択肢以外の値は受け付けない
• 自由記述欄：文字数の上限を設ける

入力値の検証だけでは攻撃は防げない

同じチートシートは、怪しい文字を取り除くだけでは、SQLインジェクション対策の「パラメータ化されたクエリ」や、クロスサイト・スクリプティング対策の「出力時のエンコード（エスケープ）」の代わりにはならないとしています（出典：同上）。

IPAの「安全なウェブサイトの作り方」（改訂第7版）では、フォームに関係の深い脆弱性として、SQLインジェクション、クロスサイト・スクリプティング、CSRF（クロスサイト・リクエスト・フォージェリ）、メールヘッダ・インジェクションなどの対策を解説しています（出典：IPA「安全なウェブサイトの作り方」）。

自作のフォームプログラムを使っている場合は、これらの対策が入っているかを制作会社に確認しましょう。フォームプラグインやフォームサービスを使う場合でも、プラグイン自体に脆弱性が見つかることがあるため、更新が欠かせません。

フォームプラグインの脆弱性は「更新」で防ぐ

たとえば、WordPress用のフォームプラグイン「Forminator」では、2024年4月18日に複数の脆弱性がJVN（Japan Vulnerability Notes）で公表されました。危険なタイプのファイルの無制限アップロード（CVSS基本値9.8）、SQLインジェクション、クロスサイト・スクリプティングが含まれ、対策は開発者の情報に従って最新版に更新することとされています（出典：JVN「JVN#50132400」）。

このように、広く使われているプラグインでも脆弱性は見つかります。WordPressの場合の更新手順は「WordPressの更新（アップデート）の進め方」、プラグイン選びは「WordPressのセキュリティプラグイン」を参考にしてください。

ファイル添付機能は本当に必要か見直す

履歴書や図面を受け取るためにファイル添付機能を付けることがありますが、上記の例のように、ファイルアップロードは深刻な脆弱性につながりやすい機能です。必要がなければ添付機能は外し、必要な場合は受け付けるファイル形式とサイズを限定しましょう。

個人情報の扱い：個人情報保護法で押さえるポイント

お問い合わせフォームで氏名やメールアドレスを受け取る会社は、個人情報保護法に沿った扱いが必要です。 フォームに関係が深いのは、「利用目的の明示」「安全管理措置」「委託先の監督」「漏えい時の報告」の4点です。

※以下の条文番号は、個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」（令和8年6月一部改正版）の記載にもとづきます。個別の判断は、個人情報保護委員会の公式情報や専門家に確認してください。

送信ボタンの前に利用目的を示す

本人から書面（Webフォームなどの電磁的記録を含む）で直接個人情報を取得する場合は、あらかじめ本人に利用目的を明示する必要があります（法第21条第2項）。ガイドラインでは、自社のホームページ上に利用目的を明示する方法を例に挙げ、ネットワーク上で取得する場合は、本人が送信ボタン等をクリックする前に利用目的が目に留まるよう配置に留意することが望ましいとしています。利用目的が書かれた画面へ1回程度の操作で移れるリンクやボタンを置く方法でもよいとされています（出典：個人情報保護委員会 ガイドライン（通則編）3-3-4）。

実務では、送信ボタンの近くにプライバシーポリシーへのリンクと同意欄を置くのが一般的です。

受け取ったデータの安全管理措置

個人情報取扱事業者は、個人データの漏えい等を防ぐため、必要かつ適切な安全管理措置を講じなければなりません（法第23条）。ガイドラインの別添では、技術的安全管理措置として、外部からの不正アクセスや不正ソフトウェアから守る仕組みの導入、個人データを含む通信の経路または内容の暗号化などが例示されています。中小規模事業者の手法例として、機器のOSを最新に保つこと、セキュリティ対策ソフトを導入して最新の状態にすることなども挙げられています（出典：同ガイドライン 10（別添）10-6）。

フォーム運用に置き換えると、次のような点を決めておきましょう。

管理画面のパスワードや二段階認証の考え方は「不正アクセス対策の基本」で解説しています。

フォームサービスや制作会社への委託

外部のフォームサービスを使う場合や、制作会社・保守会社にフォームの管理を任せる場合、個人データの取扱いを委託していることになる場合があります。委託先に対しては、必要かつ適切な監督を行う必要があります（法第25条）。サービスの利用規約やセキュリティ対策、データの保存場所を確認しておきましょう。

漏えいしたときの報告義務

次のいずれかに当たる個人データの漏えい等（そのおそれを含む）が発生した場合、個人情報保護委員会への報告と本人への通知が必要です（法第26条）。

1. 要配慮個人情報が含まれる
2. 不正に利用されることにより財産的被害が生じるおそれがある
3. 不正の目的をもって行われたおそれがある当該個人情報取扱事業者に対する行為による
4. 本人の数が1,000人を超える

報告は、発覚日から3〜5日以内に速報、30日以内（3の不正の目的によるおそれがある場合は60日以内）に確報を提出します（出典：個人情報保護委員会「漏えい等の対応とお役立ち資料」）。

3は人数に関係なく対象になる点に注意が必要です。個人情報保護委員会のQ&Aでは、第三者が正規サイトに偽サイトへのリンクを不正に設置し、本人がそこから情報を入力した場合、報告対象となる可能性があるとしています（出典：個人情報保護委員会「よくある質問」Q6-7）。フォームの改ざんは、件数が少なくても報告対象になりうると考えて備えておきましょう。

【実例】アイエムワークスが管理するフォームで見てきたスパムと対策

アイエムワークスが対策したお客様のフォームでの実例と、新しくサイトを作るときにフォームへ入れている設定を紹介します。

月約3,000件のスパムが、対策後は約60件に

お客様のサイトで、お問い合わせフォームに月約3,000件のスパムが届いていたケースがあります。1日あたりに直すと約100件です。

届いていたのは、主に次の2種類でした。

• 本文にURLが入ったもの（怪しいサイトへの誘導）
• 意味のない文字列や、同じ内容のくり返し

人が手作業で送るとは考えにくい内容と量で、プログラム（ボット）による自動送信と考えられます。

当社で次の3つの対策を組み合わせた結果、スパムは月約60件まで減りました。

確認している範囲では、対策のあとに本物の問い合わせまで弾いてしまったことはありません。また、この事例では自動返信メールが踏み台にされた形跡もありませんでした。

なお、海外IPのブロックは、海外の取引先や海外在住のお客様から問い合わせがある会社では、本物の問い合わせまで弾くおそれがあります。導入する前に、問い合わせをしてくる相手を確認しましょう。

新しくサイトを作るときにフォームへ入れている設定

当社では、新しくサイトを作るとき、フォームに次の設定を基本的にすべて入れています。

ファイル添付機能は、必要な場合を除いて付けないことが多いです。

安全性と「問い合わせのしやすさ」を両立する

セキュリティ対策を重ねすぎると、本物の問い合わせまで減ってしまうことがあります。 守りと使いやすさのバランスをとりましょう。

• 入力項目は必要最小限に：受け取る個人情報が少ないほど、漏えい時の影響も小さくなる
• 利用者に操作を求めないボット対策を優先：reCAPTCHA v3のようにスコアで判定する方式は、画像選択などの手間がない
• エラー表示は具体的に：入力値の検証で弾く場合は、どの項目をどう直せばよいかを表示する
• 送信完了がわかるようにする：自動返信を止める場合は、完了画面で受付と返信の目安を伝える

フォームまでの導線や入力しやすいフォームの設計は「CTA（お問い合わせ導線）の作り方」で解説しています。

お問い合わせフォームのセキュリティチェックリスト

サイト全体の点検項目は「Webサイトのセキュリティチェックリスト」にまとめています。

まとめ：フォームは「HTTPS・ボット対策・入力値検証・データ管理」で守る

• お問い合わせフォームは、誰もがデータを送り込める入口。スパム、踏み台、盗み見、脆弱性攻撃、データ漏えいの5つのリスクがある
• HTTPSで送信内容を暗号化し、reCAPTCHAなどでボットによる自動送信を防ぐ
• 自動返信メールは、入力内容をそのまま載せない設定にするか停止する
• 入力値はサーバー側で検証し、SQLインジェクション等はプレースホルダや出力時のエスケープで防ぐ。プラグインは常に最新に
• 受け取った個人情報は、利用目的の明示、保存場所と閲覧者の管理、漏えい時の報告体制まで決めておく

まずは自社のフォームがHTTPSになっているか、ボット対策と自動返信の設定がどうなっているかを確認するところから始めましょう。セキュリティ対策の全体像は「Webサイトのセキュリティ対策とは？中小企業向け完全ガイド」で確認できます。

参考資料・出典

• Google Chrome ヘルプ「Check if a site’s connection is secure」https://support.google.com/chrome/answer/95617
• Google for Developers「reCAPTCHA v3」（最終更新2024年7月10日）https://developers.google.com/recaptcha/docs/v3
• Google Cloud「Compare features between Google Cloud Fraud Defense tiers」（2026年10月6日更新）https://docs.cloud.google.com/recaptcha/docs/compare-tiers
• Cloudflare Docs「Turnstile」https://developers.cloudflare.com/turnstile/
• エックスサーバー「メールフォームを悪用した不正アクセスについて」https://www.xserver.ne.jp/manual/man_malicious_mailform.php
• OWASP Cheat Sheet Series「Input Validation Cheat Sheet」https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html
• IPA「安全なウェブサイトの作り方」（改訂第7版第4刷、2021年3月31日）https://www.ipa.go.jp/security/vuln/websecurity/about.html
• JVN「JVN#50132400 WordPress用プラグインForminatorにおける複数の脆弱性」（2024年4月18日）https://jvn.jp/jp/JVN50132400/index.html
• 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/
• 個人情報保護委員会「漏えい等の対応とお役立ち資料」https://www.ppc.go.jp/personalinfo/legal/leakAction/
• 個人情報保護委員会「よくある質問」Q6-7 https://www.ppc.go.jp/all_faq_index/faq1-q6-7_

※各出典の内容は2026年10月時点で確認しています。