ECサイト・スマホアプリのリリース前脆弱性診断ガイド｜チェックリストと進め方
目次[非表示]
「リリース日はもう決まっている。でも、セキュリティをいつ、どうやって確認するかは決まっていない」。本記事は、ECサイトや会員向けスマホアプリの新規構築・リニューアルを控え、そんな不安を抱えるEC責任者・開発プロジェクトマネージャーの方に向けた記事です。
結論から言えば、リリース前に第三者の脆弱性診断を受け、修正と再診断の時間まで逆算してスケジュールに組み込むことで、公開後の情報漏えいと手戻りを大きく減らせます。ECサイトとスマホアプリには、氏名、住所、購入履歴、クレジットカード情報など、攻撃者が欲しい情報が1か所に集まっているからです。
2026年には、多くのEC事業者が利用する国内のECサイト構築サービスで不正アクセスが発生し、2,000万人を超える規模の個人情報が漏えいしたと公表されました。原因は、サーバー上で動くアプリケーションの脆弱性を悪用されたことでした。
本記事では、この事案から読み取れる教訓、ECサイトとスマホアプリが狙われる理由、クレジットカード・セキュリティガイドラインが求める脆弱性対策、リリース前に確認すべき5つの観点とチェックリスト（抜粋）、そして脆弱性診断の期間と進め方を順に解説します。全39項目のチェックリストは、別資料としてダウンロードいただけます。
2026年のEC情報漏えい事案から見えること
ECの情報漏えいは、1社の問題にとどまらず、プラットフォームを通じて数千の店舗とその顧客に広がります。
2026年に公表されたECサイト構築サービスへの不正アクセスは、その典型例です。公表資料と報道から、要点を整理します。
項目 | 公表内容（要約） |
影響の範囲 | 現在の利用店舗に加え、過去に利用していた店舗を含む数千店舗。漏えい対象者は2,000万人を超える規模 |
原因 | サーバー上で稼働するアプリケーションの脆弱性を悪用され、不正なプログラムを実行された |
漏えいした情報 | 購入者・会員の氏名、住所、電話番号、メールアドレス、会員ID、暗号化されたパスワード、店舗管理画面のログイン情報など |
カード情報 | 一部の購入者について、カード名義、カード番号の一部、有効期限。完全なカード番号とセキュリティコードは含まれない |
発覚までの期間 | 不正アクセスは2か月以上続いていた |
※事業者の公表資料および報道（2026年8月・10月）をもとに当社で要約
この事案は、特定の事業者だけの問題ではありません。同じ構造のリスクは、自社開発のECサイトにも、SaaS型ECのカスタマイズ部分にも存在します。EC事業者が押さえておきたい教訓は3つあります。
1つ目は、公表される件数は調査の進行とともに変わることです。初期の公表では同じ顧客の重複を含む可能性がある件数が示され、最終的には重複を除いた人数が示されました。単位の異なる数字を並べて比べたり、初期の数字だけで影響を判断したりしないことが大切です。
2つ目は、被害が現在の利用店舗だけでなく、過去に利用していた店舗の顧客にも及んだことです。サービスの利用をやめても、預けたデータが残っていれば影響を受けます。顧客データをいつまで保持し、いつ削除するかも、セキュリティ設計の一部です。
3つ目は、原因がアプリケーションの脆弱性だったことです。ファイアウォールなどの防御製品を整えていても、アプリケーションの作りに穴があれば突破されます。玄関の鍵を最新にしても、裏口が開いていれば意味がないのと同じです。だからこそ、リリース前や改修時に、アプリケーションそのものを検査する必要があります。
なぜECサイトとスマホアプリは狙われるのか
ECサイトとスマホアプリが狙われる理由は、情報の価値、改修の頻度、外部連携の多さの3つに整理できます。
理由 | 内容 |
情報の価値が高い | 個人情報とカード情報がそろえば、不正利用や転売にすぐ使える |
改修の頻度が高い | セールやキャンペーンのたびに機能が追加され、新しい脆弱性が生まれやすい |
外部連携が多い | 決済代行、配送、ポイント、レビュー、広告タグなど、攻撃の入口が多い |
1つ目の情報の価値について、攻撃者にとってECのデータベースは「換金しやすい資産」です。会員のメールアドレスとパスワードは、他サイトへのなりすましログインにも転用されます。
2つ目の改修頻度は、EC特有の事情です。年末商戦や大型セールに合わせて、短期間で新機能を追加するケースは少なくありません。リリース日が先に決まっていると、セキュリティの確認は後回しになりがちです。
3つ目の外部連携は、自社で書いたコード以外にもリスクがあることを意味します。決済画面に読み込んでいる広告タグが改ざんされれば、自社のコードに問題がなくてもカード情報が盗まれる可能性があります。
さらに、AIを悪用した攻撃の自動化により、攻撃者は多数のサイトを同時に探索できるようになっています（出典：NTTドコモビジネス「AIを悪用したサイバー攻撃」）。「中小規模のサイトだから狙われない」という前提は、もう成り立ちません。
クレジットカード・セキュリティガイドラインが求める脆弱性対策
クレジットカード決済を扱うEC加盟店には、業界のガイドラインで脆弱性対策の実施が求められています。
「やったほうがよい」ではなく、取引上の前提条件になりつつある点を押さえておきましょう。
「クレジットカード・セキュリティガイドライン」は、クレジット取引セキュリティ対策協議会がとりまとめた指針です。経済産業省が所管する「割賦販売法（後払い分野）に基づく監督の基本指針」で、同法が定めるセキュリティ対策義務の「実務上の指針」と位置づけられています（出典：ScanNetSecurity（2025年3月13日））。
2025年3月に公表された6.0版では、EC加盟店向けに次の対策が追加されました（出典：ペイメントナビ（2026年4月21日））。
- カード情報保護対策として、システムやWebサイトの改ざん・ウイルス感染を防ぐ脆弱性対策
- 不正利用対策として、本人になりすましたログインを防ぐ適切な不正ログイン対策
- 不正利用対策として、本人認証の仕組みであるEMV 3-Dセキュアの導入
協議会は追加の背景として、EC加盟店が不正利用被害額の約9割を占めることを挙げています（同出典）。2026年3月11日には6.1版が公表されましたが、これは6.0版の対策を着実に実施するための理解促進を目的とした改訂とされています（出典：ペイメントナビ（2026年3月12日））。
EC加盟店に求められる5つの脆弱性対策
EC加盟店の脆弱性対策としては、次の5つが示されています（出典：ペイメントナビ（2026年4月21日））。右列は、リリース前に確認したい具体的な点の例です。
対策 | リリース前に確認したいことの例 |
① システム管理画面のアクセス制限と管理者のID/パスワード管理 | 管理画面へのアクセス元の制限、多要素認証、不要な管理者アカウントの削除 |
② データディレクトリの露見に伴う設定不備への対策 | Webから見える場所にバックアップや設定ファイルが置かれていないか、ファイル一覧が表示されないか |
③ Webアプリケーションの脆弱性対策 | 脆弱性診断などによる問題の発見と、見つかった問題の修正 |
④ マルウェア対策としてのウイルス対策ソフトの導入 | サーバーへのウイルス対策ソフトの導入と、定義ファイルの更新 |
⑤ 悪質な有効性確認、クレジットマスターへの対策 | 短時間に繰り返される決済の試行を検知・制限できるか |
※各対策の正式な名称と要件は、クレジット取引セキュリティ対策協議会の公表資料でご確認ください。
「非保持化」済みでも対策は必要です
カード情報を自社で保持しない「非保持化」を済ませていても、対策が不要になるわけではありません。理由は2つあります。1つは、氏名、住所、会員IDとパスワードなど、カード以外の個人情報は自社のシステムに残ることです。もう1つは、決済画面が改ざんされると、カード情報が入力された瞬間に盗まれることです（観点3で解説します）。
なお、本章は一般的な解説です。自社が求められる対策の範囲は、契約先のカード会社や決済代行会社にご確認ください。
リリース前に確認したい5つの観点
リリース前の確認は、認証、決済と個人情報、改ざん対策、プラットフォーム管理、スマホアプリとAPIの5つの観点で整理すると漏れが減ります。
ここでは各観点で「なぜ確認が必要か」を解説します。具体的な確認項目は、次章のリリース前チェックリスト（抜粋）と、ダウンロード資料にまとめています。
観点1：認証・会員機能
ログインまわりは、攻撃者が最初に試す入口です。代表的なのが、他サイトから流出したIDとパスワードの組み合わせを機械的に試す「リスト型攻撃」です。ログイン試行回数の制限や、不審なログインの検知がないと、パスワードを使い回している会員のアカウントは簡単に乗っ取られます。
見落とされやすいのが、パスワード再設定の仕組みです。再設定用のURLが推測できたり、有効期限がなかったりすると、他人のアカウントを乗っ取れる場合があります。管理画面は特に重要で、多要素認証の有効化とアクセス元の制限が欠かせません。ガイドラインの5つの対策の①にあたる部分です。
観点2：決済・個人情報
決済まわりでは、カード情報を自社サーバーで保持・通過させない構成になっているかを、まず確認します。そのうえで、ガイドラインが求めるEMV 3-Dセキュアの導入状況も確認しましょう。
個人情報の画面で多いのが、URLやリクエストに含まれる注文番号や会員IDを書き換えると、他人の情報が表示されてしまう問題です。専門用語では「認可制御の不備」と呼ばれます。画面上は正しく動いているように見えるため、通常の機能テストでは見つかりにくい欠陥です。
あわせて、バックアップファイルや設定ファイル、管理用に書き出したCSVなどが、Webから見える場所に置かれていないかも確認します。ガイドラインの5つの対策の②にあたる部分です。
観点3：改ざん・不正なスクリプトの埋め込み
近年のカード情報窃取では、決済画面に不正なスクリプトを埋め込み、入力されたカード情報を外部へ送信させる「ウェブスキミング」と呼ばれる手口が知られています。カード情報を保持しない構成でも、入力の瞬間を狙われれば防げません。
対策の第一歩は、決済画面で読み込んでいる外部タグ（広告・アクセス解析など）の棚卸しです。「誰がいつ追加したか分からないタグ」が残っていないかを確認し、ページの改ざんを検知する仕組みも検討します。
観点4：プラットフォーム・サーバー設定
ECプラットフォームやプラグインは、脆弱性が公表されると、修正版を適用していないサイトが一斉に狙われます。本体と拡張機能を最新版に保つ運用は、リリース後も続く課題です。
リリース前には、使っていないプラグインや、退職者・旧委託先の管理アカウントが残っていないかも確認しましょう。前述の事案で過去の利用店舗まで影響が及んだように、「使っていないもの」が思わぬ入口になります。
観点5：スマホアプリとサーバー側（API）
スマホアプリは、アプリ本体とサーバー側のAPI（アプリとサーバーがデータをやり取りする窓口）の両方を確認します。アプリ本体では、APIキーなどの秘密情報を直接書き込んでいないか、端末内のデータを暗号化しているか、リリース版にデバッグ機能が残っていないかが主な確認点です。
よくある誤解が「アプリの画面から操作できないから安全」という考え方です。攻撃者はアプリを解析し、APIを直接呼び出します。画面上の制限はセキュリティ対策にはならず、守りはAPI側で固める必要があります。
リリース前セキュリティチェックリスト（抜粋）
5つの観点に運用体制と診断の準備を加えた8カテゴリから、代表的な確認項目を抜粋しました。
開発会社・運用担当と一緒に、各項目に「はい」と答えられるかを確認してください。「いいえ」「分からない」が1つでもあれば、リリース前に対応方針を決めておくべきポイントです。
カテゴリ | 代表的な確認項目 |
1. 認証・会員機能 | ☐ ログイン試行回数の制限と、不審なログインの検知がある ☐ 管理画面は多要素認証を有効にし、アクセス元を制限している |
2. 決済・個人情報 | ☐ カード情報を自社サーバーで保持・通過させず、EMV 3-Dセキュアを導入している ☐ URLのIDを書き換えても、他人の注文履歴や会員情報を見られない |
3. 改ざん・不正なスクリプト | ☐ 決済画面で読み込む外部タグを棚卸しし、必要最小限に絞っている |
4. プラットフォーム・サーバー設定 | ☐ 本体とプラグインが最新版で、使っていないプラグインや管理アカウントが残っていない ☐ Webから見える場所に設定ファイルやバックアップが置かれていない |
5. 運用・体制 | ☐ 情報漏えいや改ざんが疑われたときの連絡先と初動手順が決まっている |
6. アプリ本体 | ☐ APIキーなどの秘密情報を、アプリ内に直接書き込んでいない |
7. サーバー側（API） | ☐ アプリからしか呼ばれない想定のAPIも、直接呼び出されることを前提に守られている |
8. 診断に向けた準備 | ☐ 診断結果を受けて修正し、再診断するまでの期間をスケジュールに確保している |
全39項目のチェックリストでは、クレジットカード・セキュリティガイドラインの5つの脆弱性対策との対応表と、結果を書き込める集計シートもご用意しています。
チェックリストだけでは足りない理由
チェックリストは確認漏れを防ぐ道具として有効ですが、それだけで安全を保証することはできません。
理由は2つあります。
1つ目は、作った本人は設計の前提を疑いにくいことです。「この画面には会員本人しかアクセスしない」という前提で作った機能は、その前提が崩れる操作を想定していません。チェックリストに「はい」と答えても、実装に穴が残る場合があります。
2つ目は、深刻な脆弱性の多くが、正しく作ったつもりの機能の組み合わせで起きることです。観点2で触れた「IDを書き換えると他人の情報が見える」問題は、その典型です。機能テストと脆弱性診断は、確かめる対象がそもそも異なります。
比較の観点 | 機能テスト | 脆弱性診断 |
確かめること | 仕様どおりに動くか | 仕様外の使われ方をしたときに何が起きるか |
想定する利用者 | 正しい利用者による正しい操作 | 改ざん、なりすまし、大量の試行を行う攻撃者 |
見つかる問題の例 | 計算の誤り、画面遷移の不具合 | 他人の情報が見える、不正な命令が実行される |
目的が異なるため、機能テストを丁寧に行っても脆弱性診断の代わりにはなりません。たとえるなら、チェックリストは建物の「点検表」、脆弱性診断は専門家による「侵入テスト」です。点検表で鍵の有無は確かめられますが、窓の隙間から入れるかどうかは、実際に試してみないと分かりません。そのため、リリース前には第三者による脆弱性診断をおすすめします。
リリース前診断の進め方と、開発・テスト・診断を一体で進めるメリット
リリース前診断は、修正と再診断の時間を逆算してスケジュールに組み込むことが成功の鍵です。
一般的な流れ
- 診断範囲を決める：対象の画面、API、アプリの対応OS、外部連携先を洗い出します。決済・会員・管理画面など、被害が大きい機能から優先します。
- 診断時期を決める：主要機能の実装が固まった段階で実施します。リリース直前では、見つかった問題を直す時間がありません。
- 診断を実施する：Webアプリケーション、API、スマホアプリ本体を、それぞれの観点で検査します。
- 結果を評価する：検出された問題を重大度で分類し、リリース前に直すものと、リリース後に計画的に直すものを判断します。
- 修正と再診断を行う：修正が正しく行われ、新たな問題が生じていないことを再診断で確認します。
- リリース後も続ける：認証・決済・個人情報に関わる改修時と、定期診断のタイミングで再度確認します。
この中で特に計画から漏れやすいのが、手順5の修正と再診断の期間です。診断を「リリース前の最終関門」とだけ捉えると、重大な問題が見つかった時点でリリース延期か、リスクを抱えたままの公開かの二択を迫られます。
診断期間とスケジュールの目安
診断にかかる期間は、対象の規模と診断の深さで変わります。コウェルの場合、目安は次のとおりです。
診断の種類 | プラン | 診断期間の目安 |
シンプル | 5営業日〜 | |
Webアプリケーション脆弱性診断（DAST） | エントリー | 7営業日〜 |
シンプル | 約1週間 | |
スマホアプリ脆弱性診断 | エントリー | 約2週間 |
いずれも | カスタム | 個別にご相談 |
※2026年10月時点のサービスページの記載です。対象範囲によって変わります。
これに修正と再診断の期間を加えると、リリースの1か月以上前には診断を始める計画が安心です。たとえば、次のように逆算します。
時期 | やること |
リリース8〜6週前 | 診断範囲と優先する機能を決め、診断用の環境とテストアカウントを用意する |
リリース6〜4週前 | 診断を実施する（Webアプリケーション、API、スマホアプリ本体） |
リリース4〜2週前 | 結果を評価し、リリース前に直す問題を修正する |
リリース2〜1週前 | 再診断で修正を確認し、リリースの可否を判断する |
※スケジュールの一例です。診断範囲や修正の量によって前後します。
開発・テスト・診断を一体で進めるメリット
コウェルは、脆弱性診断を「開発とテストの延長で行う品質保証の一部」と位置づけています。
コウェルは、EC構築とソフトウェアテストを主力事業としてきた会社です。Adobe Commerce（Magento）やShopifyでのEC構築、スマホアプリを含むシステム開発、ソフトウェアテストを提供しています。
その経験から、脆弱性診断を「リリース直前に別会社へ頼む特別な作業」ではなく、開発・テストと一体で進めることをおすすめしています。一体で進めるメリットは3つです。
- 診断で見つかった問題を、そのまま修正と再診断につなげられる
- 機能テストと診断のスケジュールを一体で組めるため、リリース直前の手戻りを減らせる
- 仕様を理解したうえで診断するため、確認すべき箇所を絞り込みやすい
診断のメニューは、対象に合わせて選べます。Webアプリケーション脆弱性診断では、稼働中のサイトやAPIを外部から検査する動的診断（DAST）、利用しているオープンソースの既知の脆弱性を調べるソフトウェア構成分析（SCA）、アプリケーション内部から実行時の挙動を監視するインタラクティブ診断（IAST）を用意しています。スマホアプリ脆弱性診断では、静的解析、動的解析、リバースエンジニアリング耐性テストを組み合わせ、OWASP Mobile Top 10 2024に準拠して確認します。情報処理安全確保支援士による検出結果の精査や、開発チームによる改修支援にも対応しています。
すでにコウェルでEC構築や保守をご依頼いただいているお客様は、次回リリースのスケジュールに診断を組み込む形でもご相談いただけます。
事例：ECサイトのリニューアル前診断から、改修・再診断まで
アパレル企業様のECサイトのフルリニューアルで、リリース前に脆弱性診断を実施した事例です。お客様は以前、他社の診断で報告書を受け取ったものの、改修方法が分からず困ったご経験をお持ちでした。
DAST・SAST・IASTを組み合わせて診断した結果、商品検索APIのSQLインジェクションを含む高リスクの脆弱性が2件、中リスクが2件、低リスクが1件、併設するWordPressで3件の問題が見つかりました。開発チームと連携して改修し、再診断ですべて解消されたことを確認しています。
項目 | 初回診断 | 再診断 |
高リスクの脆弱性 | 2件 | 0件 |
中リスクの脆弱性 | 2件 | 0件 |
低リスクの脆弱性 | 1件 | 0件 |
WordPress関連 | 3件 | 0件 |
▶ 事例の詳細：ECサイトリニューアルで発覚した脆弱性―開発チームと連携した診断・改修の全記録
ソフトウェアテストでも、ECサイトの品質を支えた事例があります。大手倉庫・物流会社のECサイトの大規模リニューアルでは、決済・在庫・受発注などの基幹機能を重点に約2万件のテストを設計・実行しました。D2C統合支援プラットフォームの事例では、ログイン、カート、決済、注文確定などの基幹フローをE2Eで自動化し、回帰テストを数日から数時間単位に短縮しています。
よくある質問
Q. ShopifyなどのSaaS型ECでも脆弱性診断は必要ですか？
A. プラットフォーム本体は提供元が管理していますが、追加したアプリ、テーマのカスタマイズ、外部連携は自社の責任範囲です。カスタマイズや外部連携が多い場合は、診断をおすすめします。
Q. 診断はリリースのどのくらい前に行えばよいですか？
A. コウェルの場合、診断期間の目安はWebアプリケーション診断で5営業日〜、スマホアプリ診断で約1〜2週間です。修正と再診断の期間を加え、リリースの1か月以上前には診断を始める計画をおすすめします。
Q. リリースまで時間がない場合は、どうすればよいですか？
A. 決済・会員・管理画面など被害が大きい機能と、そのAPIに範囲を絞って先に診断し、残りはリリース後の定期診断で確認する方法があります。ただし、重大な問題が見つかったときに備え、修正と再診断の時間だけは必ず確保してください。
Q. 脆弱性診断の費用は何で決まりますか？
A. 主に、診断範囲（画面やAPIの数、アプリの対応OS）、診断手法（ツールによる検査か、専門家による精査を含むか）、報告書の詳しさ、再診断の有無で決まります。コウェルのWebアプリケーション脆弱性診断の料金の目安は、サービスページに掲載しています。
Q. アプリのアップデートのたびに診断が必要ですか？
A. 認証、決済、個人情報に関わる機能を変更した場合はおすすめします。軽微な画面変更のみなら、定期診断でカバーする方法もあります。
Q. カード情報を保持していなければ、ガイドラインの脆弱性対策は不要ですか？
A. 不要にはなりません。ガイドライン6.0版では、カード情報を保持しないEC加盟店も含めて脆弱性対策が求められています。対象範囲は契約先のカード会社や決済代行会社にご確認ください。
まとめと次のステップ
- 2026年のEC大規模漏えいの原因はアプリケーションの脆弱性で、被害は過去の利用店舗の顧客にも及んだ
- ECサイトとスマホアプリは、情報の価値・改修頻度・外部連携の多さから狙われやすい
- カード決済を扱うEC加盟店には、ガイドラインで脆弱性対策が求められている
- リリース前に、認証、決済、改ざん対策、プラグイン管理、API保護の5観点を確認する
- チェックリストには限界があり、第三者の脆弱性診断と、修正・再診断の期間確保が有効
コウェルの無料相談では、次の2つの進め方からお選びいただけます。
進め方 | 内容 | 向いている企業 |
リリース前診断のみ | 既存または開発中のサイト・アプリを診断し、修正方針を報告 | 開発会社は決まっている、診断だけ第三者に頼みたい |
開発・テスト・診断を一体で | 構築・改修、機能テスト、脆弱性診断をまとめて計画 | これから構築・リニューアルする、手戻りを減らしたい |
ECサイト・スマホアプリのリリース前に、
脆弱性診断をご相談ください。
「診断だけを第三者に頼みたい」「構築・テスト・診断をまとめて計画したい」——
リリース予定日と、対象のURL（アプリの場合は対応OS）をお知らせいただくと、初回のお打ち合わせで診断範囲とスケジュールをご提案します。
