EC情報メディア詳細
ECサイトで情報漏えいが起こるとどうなる? 安心できるサイト作りに欠かせない対策方法

「うちのECサイトに限って情報漏えいは起きないだろう」——そう思っているEC担当者ほど、リスクにさらされている可能性があります。
2024年4〜6月のわずか3ヶ月間で、ECサイトからのクレジットカード情報流出件数は前年同期比11倍超の12万件超に急増しました(かっこ株式会社・株式会社リンク調査)。被害を受けた企業のすべてが「対策をしていなかった」わけではありません。むしろ、対策の抜け漏れや、使用しているECシステムの構造的な脆弱性が原因となるケースが大半です。
本記事では、ECサイトで情報漏えいが起きた際のリスク、漏えいが発生する原因の4分類、そして実践的な7つの対策を解説します。あわせて、ECシステムの種類によってセキュリティリスクがどう異なるかも整理しているので、プラットフォームの選定や見直しを検討している方にも参考になる内容です。
『メルカート』サービス概要資料
こんな人におすすめ
・メルカートのサービス概要を詳しく知りたい方
・機能や料金プランを知りたい方
・一般的なカートシステムとの比較を知りたい方
【目次】
・ ECサイトの情報漏えいはなぜ起きるのか——原因を4つに分類する
・ ECサイトの情報漏えい事例——実際に起きたインシデントから学ぶ
・ ECシステムの種類によってセキュリティリスクは大きく変わる
・ まとめ
ECサイトで情報漏えいが起きると何が起こるのか
ECサイトは顧客の氏名・住所・電話番号・メールアドレス、そしてクレジットカード情報という「二重の機密データ」を日常的に扱います。これらが外部に流出した場合、事業者が被る損失は想像以上に広範にわたります。
損害賠償・訴訟リスク
情報漏えいが発生した場合、被害を受けた顧客一人ひとりに対して損害賠償責任を負う可能性があります。過去には、数万件規模の個人情報が流出した企業が、数千万〜数億円規模の賠償金を支払った事例も存在します。賠償金の規模によっては、事業継続そのものが困難になるケースもあります。
また、個人情報保護法に基づき、個人情報保護委員会への報告義務(漏えい件数が1,000件以上、または要配慮個人情報が含まれる場合など)が発生し、対応コストも相応にかかります。
ブランド毀損と顧客離れ
情報漏えいが報道されると、「セキュリティ管理がずさんな企業」というレッテルはSNSで瞬時に拡散します。顧客の離反だけでなく、新規顧客の獲得コストが跳ね上がり、長期的な売上ダメージが続きます。一度失った信頼の回復には、一般的に数年単位の時間と多額のPRコストが必要です。
事業継続そのものへの打撃
インシデント発覚後はサイトの一時停止・フォレンジック調査・システム改修・顧客への個別通知・カード再発行費用の負担など、業務が長期にわたって停止・圧迫されます。中堅・中小規模のEC事業者にとっては、1件のインシデントが経営の根幹を揺るがすリスクになります。
ECサイトの情報漏えいはなぜ起きるのか——原因を4つに分類する
「対策をしているのになぜ漏えいが起きるのか」を理解するには、原因の全体像を把握することが先決です。情報漏えいの原因は大きく4つに分類できます。それぞれの特徴と、どのサイト・どのシステムで起きやすいかを整理します。
外部攻撃① 不正アクセス・SQLインジェクション
攻撃者がECサイトの管理画面やデータベースに不正侵入し、顧客情報やカード情報を窃取する手口です。パスワードリスト攻撃(他のサービスから流出したIDとパスワードを試しあてる手法)やブルートフォース攻撃(総当たりでパスワードを試みる手法)、SQLインジェクション(データベースへの不正命令注入)が代表的です。
特に、管理画面のURLが推測しやすい・パスワードが単純・多要素認証を設定していないECサイトで発生しやすいです。
外部攻撃② サイト改ざん・スキミング
決済ページやカード入力フォームに悪意あるスクリプトを埋め込み、顧客がカード情報を入力した瞬間に情報を外部サーバーへ送信する攻撃手法です。「Webスキミング」とも呼ばれます。被害が表面化するまでに数ヶ月〜1年以上かかるケースもあり、発覚が遅れるほど流出件数が膨らみます。
オープンソース系ECサイト(WordPressベースのWooCommerce、Magento等)で特に多く確認されており、プラグインやテーマの脆弱性が攻撃の起点になるケースが目立ちます。
内部要因 従業員のミス・不正持ち出し
外部からの攻撃だけが原因ではありません。誤送信(顧客情報をメールで誤って別の宛先に送付)、不審なリンクのクリックによるマルウェア感染、退職者による意図的な情報持ち出しなど、内部の人的要因による漏えいも相当数を占めます。
アクセス権限の管理が甘く、多くの従業員が顧客の全データを閲覧・ダウンロードできる状態になっているECサイトはリスクが高くなります。
システム老朽化 アップデート未対応による脆弱性
ECシステムやサーバーOSのバージョンが古いままになっていると、既知の脆弱性(セキュリティホール)を突かれる危険があります。「古いシステムを使い続けているから大丈夫」という発想は逆で、攻撃者は公開済みの脆弱性情報を使って古いバージョンのシステムを集中的に狙います。
オンプレミス型やパッケージ型ECでは、アップデートの適用がシステム担当者の手動作業となるため、対応が後回しになりやすい点に注意が必要です。
ECサイトの情報漏えい事例——実際に起きたインシデントから学ぶ
情報漏えいは決して他人事ではありません。実際に発生したインシデントを見ると、被害の構造が見えてきます。
2023年末〜2024年初頭に発覚したある衣料品ECサイトのケースでは、2021年から約2年以上にわたって決済ページが改ざんされ、約3,900名のカード情報(番号・有効期限・セキュリティコード)が流出しました。発覚の端緒はカード会社からの「不正利用懸念」の問い合わせでした。サイト側が気づく前に、顧客が被害を受けていたのです。
また、経済産業省の調査では、オープンソース系ECサイトを起点としたサイト改ざんによるカード情報流出が継続的に確認されており、EC事業者への注意喚起が繰り返されています。(出典:経済産業省「最近の主な漏えい事案」)
共通しているのは「対策をしていなかったわけではない」という点です。被害が起きた多くのケースで、何らかのセキュリティ対策は講じられていました。しかし、使っているシステムの構造的なリスクや、アップデート対応の遅れが漏えいの温床になっていました。
情報漏えいを防ぐための7つの対策
ECサイトの情報漏えいを防ぐには、技術的な対策と運用面の対策を組み合わせることが基本です。以下の7つを体系的に実施することで、リスクを大幅に低減できます。
①システムを常に最新の状態に保つ
サーバーOS・ECシステム・利用しているプラグインやライブラリを定期的にアップデートし、最新バージョンを維持することが最も基本的な対策です。脆弱性情報(CVE)は公開されると即座に攻撃に転用されるため、アップデートの遅れは直接的なリスクにつながります。
クラウド型・SaaS型のECプラットフォームでは、プラットフォーム側がアップデートを自動適用するため、この対応コストをゼロにできます。一方、オンプレミス型やオープンソース系では、担当者が個別に管理する必要があります。
②二要素認証・強固なログイン設定を導入する
IDとパスワードだけのログインは、リスト型攻撃に対して非常に脆弱です。管理画面には必ず二要素認証(2FA)を設定し、ワンタイムパスワードや認証アプリを組み合わせることでなりすましを防ぎます。
あわせて、管理画面へのアクセスをIPアドレスで制限し、社内ネットワーク・特定の端末からしかログインできない設定にすることも効果的です。
③クレジットカード情報の非保持化・トークン化を進める
自社サイトのサーバーにカード情報を保持しないことで、万が一サーバーに侵入されてもカード情報の流出リスクをゼロに近づけられます。具体的な方法としては、カード情報を暗号化されたトークンに置き換える「トークン型接続」や、決済代行会社のページで決済処理を行う「リンク型接続」があります。
ただし、カード情報の非保持化だけで完全ではありません。決済フォームそのものが改ざんされて情報を抜かれる「Webスキミング」は非保持化環境でも発生します。サイト全体の脆弱性対策と組み合わせることが不可欠です。
※関連記事: 3Dセキュア2.0とは?メリットや義務化のタイミング、対応に向けた準備を紹介!
④WAFを導入してサイバー攻撃を遮断する
WAF(Web Application Firewall)は、WebサイトへのHTTP/HTTPSリクエストを常時監視し、SQLインジェクション・クロスサイトスクリプティング(XSS)・CSRF攻撃などの不正リクエストを自動的にブロックするセキュリティツールです。
ECサイトに対する外部攻撃の多くは、WAFで防御できるパターンに該当します。クラウド型のECプラットフォームでは標準搭載されているケースが増えていますが、オープンソース系サイトでは別途導入・設定が必要です。
⑤アクセス権限を最小化し情報の閲覧者を絞る
「必要な人が、必要な情報だけにアクセスできる」という「最小権限の原則」を徹底します。顧客の全データを誰でも閲覧・ダウンロードできる状態は、内部不正や誤操作によるリスクを大幅に高めます。
業務上の役割に応じてアクセス権限を細かく設定し、操作ログを取得する仕組みを整えることで、内部からの漏えいを抑止できます。万が一問題が起きた際も、ログがあれば原因の特定が迅速になります。
⑥従業員へのセキュリティ教育を定期的に実施する
技術的な対策だけでは防げないのが人的ミスです。フィッシングメールの見分け方、パスワード管理のルール、不審なリンクを開いた際の対処手順など、ECサイト運営に関わる全スタッフへの定期的なセキュリティ教育が不可欠です。
年に1〜2回の研修を形式的に実施するだけでなく、実際のフィッシングメールを模した「標的型メール訓練」を行うと、社員の実践的なリテラシーが向上します。
⑦インシデント発生時の対応フローを事前に整備しておく
情報漏えいが発生した際に、「誰が」「何を」「いつまでに」対応するかが決まっていないと、初動が遅れてさらに被害が拡大します。あらかじめ以下を整備しておくことを推奨します。
- サイト停止・被害隔離の判断基準と手順
- 個人情報保護委員会・警察への報告フロー
- 顧客への通知文のひな形
- フォレンジック調査会社の連絡先の事前確認
「インシデントが起きてから考える」では遅すぎます。平時の準備がそのまま被害の最小化につながります。
ECシステムの種類によってセキュリティリスクは大きく変わる
7つの対策を実施することはもちろん重要ですが、そもそも使っているECシステムの種類によって、リスクの構造が根本的に異なります。プラットフォームの選定・見直しはセキュリティ対策の最上流の意思決定です。
オープンソース系(WordPress/Magento等)のリスク
初期コストが低く自由度が高い反面、セキュリティ対策のほぼすべてを自社で担う必要があります。プラグインやテーマが脆弱性の温床になりやすく、アップデートを怠ると攻撃を受けるリスクが急上昇します。経済産業省の調査でも、オープンソース系ECでのサイト改ざんによる情報漏えいが繰り返し報告されています。「安価に構築できた」代わりに、セキュリティ維持のランニングコストと専門知識が継続的に求められます。
オンプレミス・パッケージ型のリスク
自社サーバーで運用するオンプレミス型や、ライセンス購入型のパッケージ型ECは、カスタマイズ性が高い一方で、OSやミドルウェアのアップデート管理・セキュリティパッチの適用を自社IT部門が責任を持って行う必要があります。担当者の異動や退職によって、アップデート対応が停滞するリスクがあります。また、24時間365日の監視体制を自社で構築するコストも相当なものになります。
クラウド型SaaS ECのリスク管理の違い
クラウド型・SaaS型のECプラットフォームでは、セキュリティ基盤の維持管理をプラットフォーム事業者が担います。OS・ミドルウェアのアップデートは自動適用され、WAFも標準装備されているケースが多く、EC事業者側の対応コストを大幅に削減できます。
メルカートのような国産クラウドECでは、WAFの標準適用・DDoS対策・24時間365日の監視体制に加え、年間240回のアップデートをプラットフォーム側が実施するため、EC事業者がシステムのセキュリティ更新を個別管理する必要がありません。PCI DSS v4.0.1準拠・ISMS認証取得といった第三者認証の維持もプラットフォーム側の責任範囲となります。
※関連記事: SSLとは?役割や導入手順などを解説
| 比較項目 | オープンソース系 | オンプレミス・パッケージ型 | クラウド型SaaS |
|---|---|---|---|
| アップデート管理 | 自社で手動対応 | 自社IT部門が対応 | プラットフォーム側が自動適用 |
| WAF | 別途導入が必要 | 別途導入が必要 | 標準搭載が多い |
| 24時間監視 | 自社で構築が必要 | 自社で構築が必要 | プラットフォーム側が担保 |
| 第三者認証(PCI DSS等) | 自社で取得・維持 | 自社で取得・維持 | プラットフォームが取得・維持 |
| セキュリティコスト | 高(継続的に発生) | 高(専門人材が必要) | 低(プラットフォームに集約) |
※関連記事: 【2026年版】ECプラットフォームとは?種類・特徴や選び方がわかる完全ガイド
メルカートなら情報漏えいリスクをこう低減できる
メルカートは、PCI DSS v4.0.1準拠・ISMS認証取得・セキュリティ事故0件を継続している国産クラウド型ECプラットフォームです。EC事業者が個別に構築・維持しなければならないセキュリティ対策を、プラットフォームの基盤として提供しています。
主なセキュリティ機能は以下の通りです。
- WAF標準適用:SQLインジェクション・XSS・CSRFなどの外部攻撃を自動遮断
- DDoS対策:地理的に多様なネットワーク構成と高帯域幅回路で大量アクセス攻撃を緩和
- 年間240回のアップデート:脆弱性対応を含むシステム更新をプラットフォーム側が自動実施
- 24時間365日の監視体制:稼働環境を常時モニタリングし、異常を即座に検知
- PCI DSS v4.0.1準拠:国際的なカード情報セキュリティ基準に準拠した決済環境を提供
- ISMS認証取得:情報セキュリティマネジメントシステムの第三者認証を維持
EC事業者にとって本来の仕事は「セキュリティの維持管理」ではなく「売上を伸ばすこと」です。セキュリティ基盤をプラットフォームに委ねることで、担当者はマーケティングや顧客体験の向上に集中できます。
『メルカート』サービス概要資料
こんな人におすすめ
・メルカートのサービス概要を詳しく知りたい方
・機能や料金プランを知りたい方
・一般的なカートシステムとの比較を知りたい方
よくある質問(FAQ)
ここでは、ECサイトの情報漏えい対策に関するよくある質問とその回答についてまとめました。
Q1: 情報漏えいが起きた場合、まず何をすべきですか?
A: 最初にすべきことは「被害の拡大を止めること」です。具体的には、①対象システム・サイトの一時停止または隔離、②原因の初期調査と証拠保全(ログの取得)、③個人情報保護委員会への速報(漏えい件数・内容によっては72時間以内の報告義務が発生します)、④顧客への通知、の順で対応を進めます。フォレンジック調査が必要な場合は専門業者に依頼し、自社での証拠改ざんを避けることが重要です。こうした対応フローをインシデント前に整備しておくことが、被害を最小化する最大の備えです。
Q2: クレジットカード情報の非保持化だけで十分ですか?
A: 十分ではありません。カード情報の非保持化は有効な対策の一つですが、決済フォームや入力画面が改ざんされて情報を外部送信される「Webスキミング」は、非保持化環境でも発生します。非保持化に加えて、WAFの導入・システムの最新状態の維持・定期的な脆弱性診断を組み合わせることが必要です。また、PCI DSSへの準拠を目指すことで、包括的なセキュリティ対策の基準を満たすことができます。
Q3: クラウド型ECとオープンソース系ECでは、セキュリティにどんな違いがありますか?
A: 最大の違いは「誰がセキュリティを維持管理するか」です。クラウド型・SaaS型のECでは、WAFの適用・システムアップデート・24時間監視・PCI DSS準拠をプラットフォーム事業者が担うため、EC事業者はセキュリティ維持の工数・コストを大幅に削減できます。一方、WordPressやMagentoなどのオープンソース系では、プラグインの脆弱性対応やシステムの更新管理をすべて自社で行う必要があります。セキュリティ専任の担当者がいない場合、クラウド型プラットフォームへの移行はセキュリティリスク低減の現実的な選択肢です。
まとめ
ECサイトの情報漏えいは、対策の有無にかかわらず発生しています。重要なのは、リスクの原因を正確に理解したうえで、技術・運用・システム選定の3つの側面から多層的に対策を講じることです。
本記事のポイントを整理します。
- 情報漏えいの原因は「外部攻撃(不正アクセス・サイト改ざん)」「内部要因」「システム老朽化」の4つに分類される
- 対策は「システムの最新化」「二要素認証」「カード情報の非保持化」「WAF導入」「権限管理」「従業員教育」「対応フローの整備」の7つを組み合わせる
- 使っているECシステムの種類によってセキュリティリスクの構造が根本的に異なる。クラウド型SaaSはプラットフォーム側がセキュリティを担うため、EC事業者の負担を大幅に削減できる
現在のECサイトのセキュリティ体制に不安がある場合や、プラットフォームの見直しを検討している場合は、まずは現状のリスク診断から始めることをおすすめします。
構築・運用・サポート
売れ続ける仕組みが作れるECネットショップ制作サービスをお探しの方はメルカートへ
成功のノウハウを集めた
実例集プレゼント!
デモも
受付中
株式会社メルカート
代表取締役渡邉 章公
クラウドECプラットフォーム『メルカート』の立ち上げメンバーとして、2018年のサービスローンチから事業に携わる。2010年よりエンジニアとしてECサイト構築支援に従事し、2016年からSaaS型ECプラットフォーム事業に参画。2018年に新サービス『メルカート』を立ち上げ、2020年に株式会社エートゥジェイの執行役員、2024年に取締役を歴任。2025年の事業分社化に伴い株式会社メルカートの代表取締役社長に就任。現在は中堅・大手企業向けクラウドECとしてメルカートを次世代のCXプラットフォームへと進化させ、事業者と消費者をつなぐ新しい価値の創出を目指している。
専門領域:クラウドEC、ECプラットフォーム、SaaS事業開発、CX、BtoB / D2C / BtoB EC

この記事が気に入ったら
いいね!しよう
最新情報をお届けします





