問い合わせフォームのセキュリティ対策とは、SSL化やbot対策といった単一の施策で終わらせず、攻撃の経路ごとに防御を重ねる「多層防御」を講じることです。
具体的には、以下の5つの対策を実施することが推奨されます。
- SSL/TLSによる通信の暗号化
- 入力値のバリデーションとサニタイズ
- reCAPTCHA・Turnstileによるbot対策
- WAFによるアプリケーション層の防御
- 定期的な脆弱性診断の実施
問い合わせフォームはWebサイトの中でも、外部のユーザーから値を直接受け取る場所です。常に攻撃の入口になりえるため、経路が複数ある以上、1つの対策だけでは守りきれません。
そこでこの記事では、フォームに潜むセキュリティリスクの実態から、優先度別の対策手順、Googleフォーム・WordPressといったツール別の安全性評価、実際の被害事例までを体系的に紹介します。セキュリティ業務のご担当者はぜひ参考にしてください。
問い合わせフォームにおけるセキュリティリスクとは？攻撃の手口と被害の実態
問い合わせフォームにおけるセキュリティにおいて、まず押さえておきたいのが、リスクが生まれる根本的な理由です。Webフォームは、外部のユーザーが直接入力した値をサーバーに送り込む仕組みです。この「外部から値を受け取る」という性質そのものが、攻撃者にとっての入口になります。
情報漏洩・スパム踏み台・データ改ざんといった被害はいずれも、フォームがその構造上、外部入力を拒めないことを利用しています。
ここからは、この3種類のリスクと、それぞれを引き起こす攻撃手法を順に整理します。対策の詳細は次章で扱うため、ここではリスクの全体像と攻撃の仕組みの理解に集中します。
不正アクセスによる情報漏洩とデータ改ざん
フォームに入力された個人情報は、送信後にサーバーを経由してデータベースに保存されます。通常の流れでは、この保存された情報に外部からアクセスする手段はありません。しかしフォームや連携するアプリケーションに脆弱性があると、その隙を突いた不正アクセスでデータベースの内容が丸ごと引き出されたり、書き換えられたりします。
被害の深刻度は、フォームで収集する情報の種類によって大きく変わります。氏名やメールアドレスにとどまる場合でも漏洩は問題ですが、クレジットカード番号や決済情報を扱うフォームで漏洩が発生すると、不正利用による直接的な金銭被害とブランド毀損に直結します。
自動返信メールを悪用したスパム踏み台
問い合わせフォームの自動返信機能は、攻撃者にスパム送信の踏み台として悪用されるリスクがあります。自社のメールサーバーが第三者へフィッシングメールを送り続ける状態になり、IPアドレスがブラックリストに登録されるなどの深刻な被害につながります。
具体的には、攻撃者はメールアドレス欄に無関係な第三者のアドレスを入力し、問い合わせ内容の本文欄にフィッシングサイトへのURLを埋め込みます。フォームを送信すると、自社のメールサーバーが正規の自動返信として、そのフィッシングURLを含むメールを第三者へ届けます。
自社は攻撃を受けているとは気づかず、メールを送り続けます。その結果、自社メールサーバーのIPアドレスがスパム送信元としてブラックリストに登録され、正規の取引先や顧客へのメールまで届かなくなる二次被害が生じてしまいます。
これとは別に、フォームの実装そのものに脆弱性がある場合の攻撃として、メールヘッダインジェクションがあります。氏名やメールアドレスなど、メールのヘッダに使われる入力欄に改行コード（CR/LF）を混入させ、「Bcc:」や「To:」といったヘッダを不正に追加することで、フォームメーラーに任意の宛先へメールを送らせる攻撃です。メールヘッダインジェクションも自社サーバーを大量送信の踏み台にされる原因となるため、ヘッダに用いる項目では改行・制御文字を除去または拒否する処理が欠かせません。
代表的な攻撃手法と仕組み
その他、代表的な3つの手法を以下で順に解説します。それぞれ仕組みは異なりますが、「フォームに入力された値を適切に処理しないこと」が悪用される共通の原理があります。
SQLインジェクション
SQLインジェクションは、フォームの入力値をデータベースへの命令文（SQL）の一部として実行させてしまう攻撃です。本来は名前や電話番号といった文字列を受け取るはずの入力欄でも、入力値をそのままSQL文に組み込む実装になっていると、攻撃者は欄にSQL文そのものを書き込めます。
たとえばログインフォームのユーザー名欄に「admin';--」と入力すると、後続のパスワード照合がコメントとして無効化され、パスワードを知らなくても管理者として認証を突破されます。
一方、通過すべき認証のない検索フォームでも、「' UNION SELECT …」のように別テーブルを参照するSQL文を送り込めば、本来は表示されないユーザー情報を検索結果として一括で抜き取られます。この手口により、データベース内の個人情報が一括で窃取されたり、テーブルごと削除されたりします。
SQLインジェクションについてはこちらの記事で詳しく解説していますので、ご参照ください。
クロスサイトスクリプティング（XSS）
クロスサイトスクリプティング（XSS）は、フォームに入力された悪意あるスクリプトを、別の利用者のブラウザ上で実行させる攻撃です。SQLインジェクションが入力値をSQL文に組み込む処理の不備に起因するのに対し、XSSは入力値を画面に出力する際の処理に起因します。
レビュー欄や検索ワードの再表示のように入力内容をページに表示する機能があり、それをエスケープ処理せずに出力していると、攻撃者が仕込んだJavaScriptが他の利用者のブラウザでそのまま実行されます。
その結果、ログインセッションを管理するCookieが盗まれ、攻撃者がその利用者になりすましてサービスを操作できます。
クロスサイトスクリプティングについてはこちらの記事で詳しく解説していますので、ご参照ください。
クロスサイトリクエストフォージェリ（CSRF）
CSRFは、ログイン中のユーザーを騙して、意図しないリクエストをサーバーへ送らせる攻撃です。
たとえばサービスにログインしたまま悪意のあるページを開くと、そのページに仕込まれた処理がバックグラウンドで実行され、パスワード変更や商品購入、設定の書き換えが勝手に行われます。SQLインジェクションやXSSが入力値の処理の不備を狙うのに対し、CSRFは利用者の正規のリクエスト送信そのものを悪用します。そのため、CSRFはログイン機能を伴うフォーム（会員登録後の設定変更や購入手続きなど）で特に問題になります。
クロスサイトリクエストフォージェリについては、こちらの記事で詳しく解説しています。
3つの攻撃手法はそれぞれ異なる経路で被害を引き起こしますが、いずれも「入力値がそのままシステムに渡される」状態を前提にしています。
次章で解説する入力値バリデーションやサニタイズは、この共通の弱点に対処するための施策です。
フォームのセキュリティ対策はどう始める？優先度別の5つの施策
前章で見たとおり、フォームへの攻撃は複数の経路で起こります。フォームのセキュリティ対策で陥りやすいのは、「SSLを入れたから大丈夫」「CAPTCHAを付けたから安心」と、1つの施策で完結させてしまうことです。実際には、通信の暗号化だけでは入力値の悪用は防げず、bot対策だけでは通信の盗聴には対処できません。
攻撃の経路が複数ある以上、対策も複数の層で重ねる設計が必要です。
ここで紹介する5つの施策は、導入コスト・効果・実装の容易さを考慮したうえで、優先度の高い順に並べています。順番に積み上げることで多層防御が完成する構造なので、1番から順に着手してください。
- SSL/TLSによる通信の暗号化
- 入力値のバリデーションとサニタイズ
- CSRF対策
- reCAPTCHA・Turnstileによるbot対策
- WAFによるアプリケーション層の防御
- 定期的な脆弱性診断の実施
ここから、それぞれの項目について詳しくお伝えいたします。
1. SSL/TLSによる通信の暗号化
SSL/TLS未対応のフォームは通信内容が平文で流れるため、盗聴・改ざんを防ぐ最初の対策としてHTTPS化が最優先です。名前・メールアドレス・問い合わせ内容といった個人情報が暗号化されないままネットワーク上を流れることを防ぐ、最も基本的な施策です。
実装のポイントは、フォームのページだけをHTTPS化するのではなく、サイト全体を常時SSL化することです。フォームのページが暗号化されていても、他のページからフォームへの遷移時に平文通信が発生すれば、そこで情報が漏洩する可能性があります。サイト全体をHTTPS化することで、ページ遷移中のデータ漏洩も防止できます。
SSL証明書の取得・設定はほとんどのレンタルサーバーで無料かつ数クリックで完了します。対応していない場合でも、Let's Encryptなどの無料認証局を利用できるため、コストを理由に後回しにする状況はほぼありません。これが完了していない場合、残りの5つの施策を検討する前にまず着手してください。
2. 入力値のバリデーションとサニタイズ
SQLインジェクションやXSSといった攻撃への根本的な対策として、サーバー側での入力値バリデーションとサニタイズは必須です。フォームを通じて悪意のあるコードやSQL文を送り込む攻撃の大半は、この層で塞ぐことができます。
この2つはよく混同されますが、役割が異なります。バリデーションはメールアドレス形式か・文字数は規定内かといった「入力形式のチェック」であり、サニタイズは入力値に含まれるHTMLタグや特殊文字を無害な文字列に変換するエスケープ処理です。通信の暗号化が「届くまで」の安全を守るのに対し、この2つは「届いたデータをどう扱うか」の対策です。
注意すべきは、クライアント側（ブラウザ）のバリデーションだけでは不十分な点です。JavaScriptによるチェックは、攻撃者がブラウザの開発者ツールやリクエスト改ざんツールを使えば簡単に迂回できます。クライアント側の検証はUX向上のための補助として位置づけ、必ずサーバー側でも同等の検証を実施してください。
3. CSRF対策
CSRF（クロスサイトリクエストフォージェリ）は、ログイン中のユーザーを騙して意図しないリクエストを送らせる攻撃です。前章のバリデーションやサニタイズでは防げず、会員登録後の設定変更や購入手続きなど、ログイン状態で状態を変更するフォームで専用の対策が必要になります。
対策のためにはCSRFトークンが有効です。フォーム表示時に予測困難なトークンを埋め込み、送信時にサーバー側で照合することで、外部サイト起点の偽装リクエストを弾きます。多くのWebフレームワークが標準搭載しており、まず有効化すべきでしょう。
また、これを補完するものとしてSameSite Cookie属性とOrigin／Refererヘッダ検証があります。前者はセッションCookieを他サイト起点のリクエストに付与しないよう設定し、後者はリクエストの送信元が自サイトかを検証します。いずれも単独では回避経路が残るため、トークンを柱に、補完層として対策をすることが有効となります。
4. reCAPTCHA・Turnstileによるbot対策
CAPTCHAは、フォームの送信者が人間かbotかを判別する仕組みです。導入することで、botによる大量の自動送信や、自動応答メールを悪用したスパム踏み台への被害を大幅に抑制できます。入力値の検証が「送られてきた内容の安全性」を確保するのに対し、CAPTCHAは「そもそも不正な送信者を入口で弾く」役割を担います。
長らく標準的な選択肢だったGoogle reCAPTCHAについては、2024年に無料枠が月1万件（1万評価）までに変更され、超過分は有料となりました（※1、※2）。月間アクセスが多いサイトでは費用が発生するため、代替の検討が必要な場面も出てきています。そこで注目されているのが、Cloudflare TurnstileとhCaptchaです。
どちらも無料で利用でき、とくにTurnstileはユーザーに操作を求めないため、フォームの離脱率を上げずにbot対策を実装できます。
※出典：Google│reCAPTCHA の課金に関する情報※出典：Google│reCAPTCHA の各ティア間の機能の比較
5. WAFによるアプリケーション層の防御
WAF（Web Application Firewall）は、HTTP通信のパターンをリアルタイムで監視し、SQLインジェクションやXSSなどの攻撃に特有のリクエストを自動的に検知・遮断します。通常のファイアウォールやIPSがネットワーク層・トランスポート層の通信を対象にするのに対し、WAFはアプリケーション層の攻撃パターンに特化しているため、フォームを狙った攻撃への対処に適しています。
「バリデーションとサニタイズがあればWAFは不要では」と感じるかもしれませんが、両者は補完関係にあります。バリデーションは既知の形式を検証する設計であり、未知の攻撃パターンや開発時に想定していなかった経路には対応できないことがあります。WAFはそうした漏れを網で受け止める役割です。
6. 定期的な脆弱性診断の実施
ここまでの5つの施策は、現時点で既知の攻撃手法への対策です。しかしセキュリティ対策は、一度実施したら完了ではありません。使用しているCMSやプラグイン、フレームワークには、運用中に新たな脆弱性が発見され続けます。
IPAが毎年発表する「情報セキュリティ10大脅威 2026」でも「システムの脆弱性を悪用した攻撃」が組織向け脅威として選出されており（2026年版では4位）（※1）、脅威の現役性が続いていることが確認できます。つまり、フォームを含む自社システムの脆弱性を定期的に診断し、新たなリスクをその都度つぶしていくことが、組織として求められる対策です。
定期診断の実施手段として、URLを入力するだけで自動スキャンを開始できる脆弱性検査ツールVexを活用できます。Vexは専門知識がなくても診断を始められる設計です。年間ライセンスで何度でも診断できるため、システム変更のたびに追加費用なく再診断でき、継続的な運用にも適しています。
まずは自社フォームの現状把握から始めたい場合は、Vex公式サイトから確認してみてください。
Googleフォーム・WordPressのセキュリティは十分か？ツール別のリスクと判断基準
ここまでの5つの施策は、どのツールを使う場合でも基盤となる考え方です。一方で、利用するツールによってリスクの出方は変わります。ツールの安全性を評価するには、「標準機能として何が備わっているか」と「運用上の設定ミスでどこが崩れるか」の両面を見る必要があります。
Googleフォームの安全性と見落としがちな設定ミス
Googleフォームは、すべての通信でSSL/TLSによる暗号化が標準で適用されており、Googleアカウントの2段階認証と組み合わせることで、通信経路上のセキュリティは十分な水準を確保しています。さらに、Googleアカウント側を2段階認証で保護すれば、フォームの管理画面や回答データへの不正ログインも防げます（通信経路の暗号化はSSL/TLS、アカウントの保護は2段階認証と、両者は別レイヤーの対策である点に注意してください）。フォームの作成から回答の収集まで、外部からの通信傍受という観点ではリスクは低いといえます。
しかし最大のリスクは、通信経路ではなく設定の誤りにあります。特に注意が必要なのが「結果の概要を表示する」オプションです。この設定を有効のままにしておくと、フォームに回答した人が他の回答者の入力内容を閲覧できる状態になります。
氏名やメールアドレスなどの個人情報を収集するフォームでは、この設定が無効になっていることを必ず確認してください。
共同編集設定も同様の落とし穴です。編集権限を「リンクを知っている全員」に設定すると、回答データへのアクセスが事実上無制限になります。フォームを公開する前に、必ず別のGoogleアカウントからテスト回答を行い、他の回答が見えないこと・編集権限が想定外の範囲に開いていないことを確認してください。
WordPressフォームプラグインの脆弱性と更新管理
WordPressはCMS市場で圧倒的なシェアを持ちます。それはすなわち、攻撃者にとって最も効率よく標的を探せるプラットフォームでもあります。Contact Form 7をはじめとするフォームプラグインは世界中で広く使われているため、脆弱性が発見されたときの影響範囲が他のツールと比較して格段に広くなります。
特に問題になるのが、プラグインのアップデート遅延です。開発者がセキュリティパッチを公開しても、サイト管理者が更新を適用するまでの間、既知の脆弱性がそのまま残ります。攻撃者は公開された脆弱性情報をスキャンして悪用するため、更新を怠るほどリスクは高まります。
加えて、プラグインを必要以上に導入している状態も管理上のリスクです。インストールされているプラグインの数が増えるほど、更新の見落としや相互干渉による不具合の可能性が広がります。使用していないプラグインは削除し、有効化するものは最小限に絞ることが、攻撃面を減らす基本的な判断です。
自作フォームとSaaS、セキュリティ面の選び方
自作フォームの利点は、要件に合わせたカスタマイズの自由度にあります。一方で、SQLインジェクションやXSSへの対策、ライブラリの更新対応、サーバー設定の維持まで、セキュリティに関わるすべての責任が自社に帰属します。
開発時点でしっかり作り込んでも、その後の継続的な保守を欠けばリスクは時間とともに蓄積します。
セキュリティ専任者がいない組織では、自作フォームの保守に必要な継続的なリソースを確保しにくいのが現実です。そのような環境では、ISO 27001やPマークを取得済みのSaaSフォームを選択することで、セキュリティ運用の多くをベンダー側に任せられます。ただし、ISO 27001は情報セキュリティマネジメント、Pマークは個人情報保護体制に関する組織的な認証であり、その製品自体に脆弱性がないことを保証するものではありません。認証は管理体制の目安として活用し、製品の技術的な安全性は別途確認するのが望ましいでしょう。なお、どのツールを選んでも、フォームの設定・運用は担当者が行う以上、人的ミスによるリスクはゼロになりません。
ツール選定と並行して、公開前のチェックリストや定期的な設定確認を運用に組み込んでおくことが、セキュリティ対策の実効性を高めます。
フォームの設定ミスが招いた情報漏洩事例
前章で触れた「人的ミスによるリスク」は、実際の漏洩事故として繰り返し起きています。SQLインジェクションやXSSといった攻撃手法を知らなくても、設定を一つ誤るだけで大規模な情報漏洩は起きます。以下の事例は、高度な攻撃ではなく「公開設定の見落とし」が原因で発生したものです。
技術的な防御を固める前に、まず運用上の設定を見直す必要があることを、具体的な被害規模とともに確認してください。
東京都のアンケートで個人情報が約5日間閲覧可能に
2025年5月、東京都スポーツ文化事業団のデフリンピック準備運営本部が委託した民間事業者が配信したボランティア向けアンケートで、Googleフォームの設定ミスが判明しました。アンケートに答えた945人分の氏名などが2025年5月2日19時30分頃から5月7日12時00分頃にかけて、約5日間にわたり他の回答者に見える状態になっていました（※1）。
原因は、回答後に他の回答者の内容が見えてしまう表示設定にありました。具体的には「結果の概要を表示する（回答後に『前の回答を表示』を押すと他人の回答が見える）」に類する設定が有効になっており、回答を終えた人が一定の操作をすると、他の回答者の氏名などを閲覧できる状態でした。フォームの公開自体は意図どおりに機能していても、回答データへのアクセス権限という別の設定が漏洩の入口になったわけです。
発覚まで約5日間かかっている点も見落とせません。フォームが「動いている」状態では異常に気づきにくく、定期的な設定確認がなければ漏洩期間がさらに延びていた可能性があります。東京都という公的機関でも発生したこの事例は、組織の規模や信頼性がそのままセキュリティ設定の正確さを保証しないことを示しています。
短期間に連続発生したGoogleフォームの情報流出
東京都の事例は孤立したケースではありません。2024年6月から7月にかけて、Googleフォームの共同編集設定の誤りにより、複数の組織で氏名・住所・電話番号・メールアドレス・会員IDなどの個人情報が流出しました（※2）。
共通の原因は、共同編集者の設定で「リンクを知っている全員」が選択されていたことです。この設定では、フォームのURLを知っている人物であれば組織外の第三者でも回答内容を編集・閲覧できます。フォームの作成者が「編集用のURLを共有した」つもりでも、実質的にデータを公開していることになります。
2つの事例に共通しているのは、攻撃者の介在がないにもかかわらず数百名から数千名規模の個人情報が外部から参照できる状態になった点です。暗号化やWAFを整える以前に、フォームの公開設定・共有設定を正確に理解して運用することが、設定ミス起因の漏洩を防ぐうえで最も優先度が高い対策です。
※1 出典：都庁総合ホームページ│個人情報の漏えいについて」※2 参考：Yahoo!ニュース｜急増するGoogleフォームの設定ミス。考えられる原因と対策。
フォームセキュリティ対策の要点まとめ
Webフォームは外部からの入力を受け付ける構造上、どれだけ堅牢なサイトでも攻撃の入口になりえます。SSL化やCAPTCHAの導入は出発点であり、それだけで安全と判断するのは危険です。攻撃経路が複数ある以上、対策も複数の層で重ねる多層防御の設計が必要であり、その防御は一度構築したら終わりではなく継続的に更新し続けることで機能します。
フォームを設置した後の最大のリスクが「技術的な攻撃」ではなく「設定の見落とし」である点も見逃せないポイントです。Googleフォームの共有設定ミスによる情報流出は、攻撃者の介在なしに起きています。技術的な多層防御と並行して、公開前後の設定確認を運用に組み込むことが推奨されます。
CMSやプラグインには運用中に新たな脆弱性が発見され続けます。弊社ではURLを入力するだけで自動スキャンを開始できる脆弱性検査ツールVexを提供しており、専門知識がない担当者でも診断を始められます。
年間ライセンスで何度でも診断できるため、フォームの改修やプラグインの更新のたびに追加費用なく再診断でき、継続的な運用にも組み込みやすい設計です。対策の全体像を把握したこのタイミングで、自社フォームの現状確認から着手することをおすすめします。
