SSLは本当に必要？フォーム送信システム導入にあたっておさえるべきポイント【2024年最新版】

フォームによるデータ通信はECサイトでのクレジットカード使用時はもちろん、住所や氏名、会社名などを打ち込む必要のある問い合わせなどで必須となっています。
特にセキュリティに詳しいインターネットユーザーだけでなく、主婦や学生などふつうのインターネットユーザーの間でも、フォームについての安全性の意識が高まっています。

したがって、サービスを提供する側がフォームの暗号化に対応しているかどうかは、安全なサイトを提供しているのかどうかの判断基準とされ、ECサイトにおけるコンバージョン率や、問い合わせ率の向上/低下などにも直結してきます。
また、GoogleがSEOにおいてhttps対応サイト（SSL対応サイト）を優遇して検索上位に表示するなどの点も見逃すことができません。

ウェブサイトの他社との差別化においてSSL対応は重要なポイントとなっており、この点をおろそかにしていくら商品や顧客サービスを充実させてもインターネットでは意味がない、とさえ言える時代になっています。

フォームサービスの導入にあたってはSSLの仕組みと働きを最低限押さえておかないと、「そもそも本当にSSLは必要なのか」「必要だとすればどんなSSLが必要なのか」といった基本的な部分が混乱してしまい、製品の比較が十分にできません。

SSLをめぐる話題について十分に必要なことを押さえていないウェブ担当者の方は、この記事を読むことでしっかりポイントを把握することが可能です。

最近では、メールフォームのURLが「http://XXXX.com」などではなく「https://XXXX.com」などであることが当たり前になってきました。
この「s」がいわゆるSSL（Secure Socket Layer）暗号化通信対応をしているという証明になっていて、ユーザーに一定の安心感を与えています。
情報保護法が浸透して個人情報に関するユーザーの意識も高まり、多くの企業がこのSSLを採用しています。

しかし、このSSL通信はあくまでもフォームに入力された内容が、このサービスを提供しているサーバー（もちろんレンタルサーバを含みます）に届くまで暗号化された状態なので安全であることを保証しているにすぎません。
つまり暗号化されているのは、あなたのブラウザとWebサーバとの間であり、サーバにデータが届いた後までは、通常暗号化されていません。

たとえば、ショッピングサイトで商品を注文したときにフォームに入力されたデータは、レンタルサーバー会社やレンタルフォームサービスを提供している会社までは、たしかに安全にSSL通信が行われますが、そこからショッピングサイトを運営する会社に注文データをメールで転送したりする場合には、SSL通信は行われません。

SSLによって暗号化されているのはユーザーがフォーム入力する地点からWebサイトまでであって、Webサイトから「注文がありました！」というメールが転送される経路で情報が盗み見られるようなことがありえます。

もっともレンタルサーバーのすべてが危険なのではなく、メールの転送を受けず、注文履歴はすべてWebサーバのデータベースに注文データを直接見に行くというケースなら安全でしょう。

しかし現実的には、「注文がありました！」という転送サービスを受けているケースがほとんどでしょう。
また、Webサーバをまるごとレンタルしている場合には、転送サービスを受けないという選択肢もありますが、フォームだけを無料、もしくは格安でレンタルしている場合などはWebサーバを直接見に行くのではなく、メールによる転送サービスしか用意されていないケースが一般的です。

こうした場合には、「SSL通信対応」とうたっても事実上有名無実となってしまっています。
このしくみ自体はユーザーからはわかりませんが、「SSL通信対応でセキュリティ万全！」をうたっていながら情報漏えいが発覚し、ユーザーが名ばかりのSSL対応のずさんさに気がつくという、最悪のケースも起こりえます。
こうした場合には、もともとSSL対応をしていなかったときよりもユーザーの不信感は強いものになりますから、取り返しのつかない信用毀損になることは間違いありません。

SSL通信の正しいイメージは「第三者による“盗聴”や“なりすまし”などの危険を防止できる」というものです。
現在の世界最高水準の暗号強度は128bitSSLですが、この強度ですと、暗号化されたデータを解読するのにおよそ数百兆年の時間が必要だと言われています。

こうした安全性のイメージを抱いているユーザーに対して、SSL対応という安心感をアピールしておきながら、実態はかけ離れているという事態は非常に危険であると言わざるをえないでしょう。

とはいえ、全面的に本格的なSSLを導入するには予算や導入の手間などの問題もあります。
安価で簡便な方法として共用SSLの利用も考えられますが、検討する際にはこうした危険性をきちんと把握しておくことが必要です。

フォームのSSL対応というと、SSL暗号化通信対応をすぐに連想する人がほとんどでしょう。
しかし、SSLにはもう一つ大きな役割があります。
それがフィッシング詐欺対策につながる、正しい電子証明書のインストールというトピックスです。

このことを整理して、SSL対応フォーム導入の注意点についての理解をさらに深めておきましょう。

SSL暗号化のしくみを理解する上で押さえておくべきなのは、暗号化（普通の文章を暗号対応にすること）と復号化（暗号を元に戻す事）に必要な「鍵」です。

ユーザーがSSL利用のページにアクセスすると、まずWebサーバからユーザーのブラウザに電子証明書が送られます。
そしてその電子証明書に含まれる「公開鍵」情報（Webサーバにアクセスしてきた人に対して公開されているという意味で「公開」という名前がついています）によってユーザーからのフォームを介した通信が暗号化されます。

このとき暗号化された情報はSSL通信によってユーザーのブラウザからWebサーバに送られ、Webサーバ側では受け取った暗号化情報を「秘密鍵」（暗号解読にだけ使われる非公開の鍵という意味で「秘密」という名前がついています）で復号化（暗号を元に戻す）します。

ここで大切なのは、この「暗号化」と「復号化」には、電子証明書がインストールされたWebサーバが重要な役割を果たしているという点です。

つまり、SSL対応というと第一に暗号化が注目されますが、ニセの電子証明書がインストールされている偽サーバで暗号化が実施されているという場合もありえるわけです。

この場合は、SSLに問題はなくても悪意のあるサーバに誘導されているという状態も考えられます。
これがいわゆる「なりますまし」という状態になります。

SSLのフォームを導入する際には、暗号化通信だけでなく、この「なりすまし」にもきちんと対応できているかに注目する必要があります。次の項目でそれを詳しく見てみましょう。

銀行口座のログイン画面などにそっくりのインターフェースを用意しておき、電子メールで「長らくパスワードが更新されていませんのですぐに更新してください」などの文面を送りつけ、悪意あるログイン画面に誘導する。
これが典型的なフィッシング（なりすまし）詐欺の手口です。

これは、実際に大手銀行でかなりの頻度で起こっている事例です。
もちろん銀行だけが標的となるわけではなく、ECサイトや、その他の個人情報を入力させるサイトでも同様の事例が発生しています。
つまり、技術的には会社のサイトのフォームを偽造してあなたの会社を装った上で、悪意あるフォーム画面から個人情報を抜き出してしまうということは簡単に出てきてしまうのです。

このとき注意しておかねばならないこととして、こうした悪意あるサイトでも「https://XXXX.com」という暗号化通信には対応できていることです。
つまり、「https://XXXX.com」となっているからといって、そのサイトがフィッシングサイトでないことにはなりません。

フィッシングサイトでないかどうかについては、ユーザー側でSSLサーバ証明書を確認する必要があります。
確認方法は簡単で、ブラウザに表示される鍵マークをクリックすれば、以下の３つのレベルの証明書を確認することができます。

レンタルサーバー事業者が提供する「共用SSL」サービスはそのレンタルサーバー事業者が取得した電子証明書を複数ユーザーで共有しているもので、上記の「ドメイン認証」を使っているケースが多いです。
どのパターンであったとしても、暗号化するページのURLが、突然レンタルサーバー事業者のドメインになってしまいますので、お客様によってはセキュリティに不安を抱く可能性もあるので注意が必要です。
実際に、ドメイン名が変わってしまうと、接続されたドメインが、共用SSLなのか、悪意のあるサイトなのか見分けがつきません。

共用SSLを使う旨をきちんと明記して、「ここから先は○○という会社のサービスに飛びます」とアナウンスしたとしても、企業実在認証やEV証明などの厳格な証明をしていない会社の共用SSLサービスの場合には、似たような会社名でフィッシング用証明書を用意されてしまうこともありえます。

共用SSLには、暗号化通信以外に、こうしたフィッシング詐欺の落とし穴があることも注意しておきましょう。

次のトピックスでは、WordPressのシェアナンバーワンのお問い合わせプラグインが、こうした「共用SSL」の危険性を十分認識しており、公式には「共用SSL」に対応していない、という事実を検討してみます。

フォームのSSL対応を考える際に、現在自社で使っているWordPressではどうやったらよいのか知りたい人も多いでしょう。
問い合わせのプラグインとしては、圧倒的に「Contact Form 7」　を使っている人が多いと思います。

このプラグインは、WordPressの管理画面からもインストールできる公式サイトお墨付きのプラグインですので、プラグイン自体に問題はなく、裏技的な方法も使いません。
しかしながら、「Contact Form 7」は「共用SSL」では動作しない仕様になっていますので、注意が必要です。

無理やり「Contact Form 7」を「共用SSL」で動かしてしまう方法もネット上に公開されているのですが、あくまでもハックレベル（自己責任による改造レベル）なので、実験的にやってみるならまだしも信頼性第一のサービスサイトでは使わないほうが無難です。

実は「Contact Form 7」に限らず他の定番問い合わせフォームプラグインでも、「共有SSL」ではSSLは動作しません。
それは、プラグインに不備があるのではなく、WordPressで定番として使われているフォームを作成するプログラマが、WordPressでは「フォームSSL不要論」を信じているからに他なりません。

WordPressのフォームのみに対応する「共用SSL」を使った簡易なSSL対応は、プラグインの本来の動作処理を「共用SSL」対応のためにある意味でねじまげ、その結果重大なセキュリティ上の欠陥を招く恐れもあります。

結論を言うと、WordPressのフォームを「共用SSL」化すると、通信を保護するために SSL を導入しているはずが結果的には脆弱にしてしまうという、本末転倒な事態を引き起こしてしまうのです。

「今使っているWordPress＋安価に導入できる共用SSL」というパターンは、WordPressで問い合わせフォームを導入している会社が飛びついてしまう考え方ですが、重大なセキュリティ問題を含んでいることを認識しておきましょう。

ここまでみてきて分かったことを整理しておきます。

「SSL対応フォーム送信の安全性のポイントを把握しておこう」でみてきたように、SSLで暗号化しているとうたっていながら、転送メールには暗号化がかかっていなかったり、「フォーム送信でSSLはどんな働きをしているのか簡単に把握しておこう」でみてきたように、フィッシング詐欺対策がおろそかだったりする場合、むしろ「弊社は万全のSSL対応をしています！」というアナウンスをしない方がよいでしょう。

「共用SSL」を使うのではなく、自社独自にSSLサーバ証明書をインストールして使うならば「弊社は万全のSSL対応をしています！」というアナウンスをしても良いでしょう。
この場合レンタルサーバーにインストールすることでもかまいません。サーバ証明書が自社契約であればよいのです。

これが、冒頭の問題提起、「そもそも本当にSSLは必要なのか」「必要だとすればどんなSSLが必要なのか」に対する一つの回答です。

まとめますと、「定番CMS　WordPressにおける「フォームSSL不要論」も知っておこう」でみてきたように、WordPressのフォームでSSLを使う場合にも、「弊社は万全のSSL対応をしています！」というアナウンスをしたいならば、自社契約のサーバ証明書をインストールしたほうが良いでしょう。

GoogleがSEOにおいてhttps対応サイト（SSL対応サイト）を優遇して検索上位に表示するということについても、サイト全体がSSL対応しているサイトが優遇対象となります。

しかし、これが唯一の方法というわけではありません。

「そもそも本当にSSLは必要なのか」「必要だとすればどんなSSLが必要なのか」に対するもう一つの回答として、「弊社は必要最小限のSSL対応をしています」というスタンスで、安価で手軽な共用SSLサービス付きのフォームを利用する手もあります。

要は、万全と言いたいのなら、共用SSLサービス付きのフォームを利用してはいけませんが、現在何のSSL対応もしていないフォームを暗号化通信に対応させる場合などには共用SSLにも一定の意味はあるということです。

また、短期間のキャンペーンにのみフォームを使うという場合や、クレジットカードなどの情報は入力しない、個人情報保護にひっかからない程度の情報しかフォームで入力しないことが明らかである、いった場合なども、共用SSLサービス付きのフォームは利用する選択肢になりえます。

この点をしっかりと社内で議論した上で、SSLサービス付きのフォーム選びを行ってください。
その選び方のヒントを最後にまとめます。

フォームは、大きく分けて下記の通常３つの画面で構成されています。

フォームを送信すること自体は入力フォームがあれば良いのですが、ユーザービリティを考えると最低限の「確認画面」と「処理終了後のメッセージ画面」は必須と言ってよいでしょう。

確認画面は必須項目のエラーを表示したりしますので、技術的すぎる文言（「入力エラー」など）、上から目線の文言（「受付できません」）になっていたりしないかどうかなどを確認しましょう。
実際にフォームへの入力・送信をしてみないと分からないので、確かめる必要があります。

これまでみてきたように、ひとくちにSSL暗号化の通信に対応していると言っても、共用SSLと自社サーバにSSL証明書インストールする場合とで大きく過中身が違うことを認識しておきましょう。

「お問い合わせ・お申し込み・アンケートなどのメールフォームが無料！」このようなキャッチコピーのサービスについ目が行きがちですが、無料SSLは共用SSLである可能性が高いです。
フォームサービスの自動作成や、カスタマイズ性の高さなどをアピールしているものが多くありますが、肝心のSSL部分について共用SSLでないかどうかをしっかりチェックすることがポイントとなります。

スマートフォンに対応では、実際に画面上で使いやすさを確認することが大切です。
特に入力画面でのIME切り替えや、エラーのアナウンスが親切かなどを見てください。
また、スマホ用を別途作らなくてもレスポンシブ・ウェブデザインなどで、自動的に画面サイズによって表示を切り替えるようにしているのかどうかもチェックポイントです。

項目数は何個までか、支払い方法や送料の設定はできるのかなどをチェックします。
10個までは無料などの、個数によって料金体系を変化させているケースもあるので注意しましょう。

投票結果が円グラフまたは横棒グラフでグラフィカルに表示されるかどうか、またリアルタイムで集計できるかどうかなどがポイントです。
また、エクセル形式でメールフォームの回答を集計・閲覧・保存・ダウンロードすることができるかどうかもチェックポイントです。
ダウンロードサービスは別料金というケースもあります。

入力・確認・完了画面に、Google Analyticsのトラッキングコードを設置ですれば、資料請求フォームや注文フォーム・応募フォームなどのコンバージョン（効果測定）を計測することができます。
コンバージョンレートはアクセス解析の基本中の基本なので、できればこうした機能はあったほうが良いでしょう。

フォームの必須項目を残さず入力してもらうためには、すべてのフォームを必須にしてしまえばよいわけですが、これですと非常にユーザーに不親切なフォームとなってしまいます。
何が必須化をきちんと洗い出した上で、ユーザーが面倒だと感じさせない範囲で入力必須項目を設定することがポイントです。

エラーチェックがかる場所についても、重要です。
いっぺんに確認画面で確認してもらって一つ前の入力画面に戻ってもらう方法もありますし、JavaScriptなどでフォームに入力した瞬間にエラーを検出する仕組みもあります。
単純に考えるとJavaScriptの方が親切に思えますが、項目が多いと最後までたどり着くのが大変だ、というイメージを与えることもありますので、入力項目数など自社の実情に沿って検討しましょう。

下記は最低限チェックしておきましょう。

IMEコントロールとは、例えばフォームを選択した瞬間にメールフォームの氏名など全角文字の入力ボックスでは日本語変換が有効化されたり、電話番号では数字入力に切り替わったりする機能です。
パソコンでも非常に便利なものですが、とくにスマートフォンでは入力切り替えを嫌がるユーザーが非常に多いので、スマホ対応する場合にはこの機能は必須だと言えるでしょう。

入力必須項目をチェックするだけでなく、JavaScriptやCGIを使えば下記のような処理も可能になります。

こうした機能に対応しているフォームもありますので、チェックしてみましょう。

簡易フォームをキャンペーン限定で使いたい場合などにプレゼント等の応募を受け付けるフォームを設置すると、景品目当てで何度も同じ人が登録をしてくる場合があります。
同じアドレスは受け付けないようにするとか、同一IPアドレスを識別して受け付けないようにするなどの方法で対処できますのでそうした機能に対応しているかどうかもチェックしてみましょう。

問い合わせや注文などでホームページに用意されたフォームに氏名やメールアドレスを入力して送信した後、自動で返信メールが行くケースが多いですが、このメールの内容をカスタマイズできるかどうかをチェックしましょう。
カスタマイズ可能であれば、そこに関連商品の案内をしてさらに売上アップに貢献させたり、商品の使い方のフォロー動画のURLをアナウンスしたりするなどのきめの細かい顧客対応をすることも可能です。

フォームから送信されたメールはメールソフトの中にたまっていくだけでは、あとから商品や資料を送付するとか集計するなどの場面で非常に使い勝手の悪いものとなってしまいます。

こうした事態を回避するためには、フォームから送ったデータをデータベースにためておき、あとから「本日の注文」「対応済みの注文」などの項目ごとに検索できるようにしておくことが必要です。

フォームメールがこうしたデータベースに対応しているかどうかは、必ず確認しましょう。

最後に、システム開発を外注した際にかかる費用相場をご紹介します。

システム開発の費用相場をご紹介しました。より正確な費用を知りたい方は料金シミュレーターをご利用ください。

以上、メールフォームでのSSL対応をするときの注意点と、SSLサービス付きのフォームをどう使うかについて整理してきました。

要するにポイントは、「弊社は万全のSSL対応をしています！」か「弊社は必要最小限のSSL対応をしています」か、どちらのスタンスで行くのかを最初に明確にすることが大切だということに尽きます。

「そうは言っても、実際は盗聴なんて滅多にされるものではない」「うちのショップだけは大丈夫」などの思い込みでSSL対応を全く行わないということは論外にせよ、「弊社は万全のSSL対応をしています！」とアナウンスしてしまっているのに、内容は万全とは言えない状態であったりしては問題です。

共用SSLで安価で手軽にフォームメールを使いたい場合には、共用SSLでできること、できないことをよく理解した上で、「弊社は必要最小限のSSL対応をしています」というスタンスでやっていくことが大切です。

そして、必要に応じて将来クレジットカードなどの情報を取り扱うときには、自社契約のサーバ証明書をインストールした形のSSL対応をするなど、段階を追ってSSL対応をより実情に合わせて強化していけばよいのです。

こうしたSSLに対するポリシーをきちんとすることで、お客さまの個人情報を守ることはもちろん、お客さまから見て「安心してサービスを利用できる」と思ってもらうことが可能になります。

自社の現状から言って、どんなSSL対応が必要なのか、その点がまだ明確化することができないでいる…という場合には、経験豊富な「アイミツ」にぜひご相談してください。
お客様にピッタリのSSL通信サービス選びのお手伝いを、自信を持ってさせていただきます。