ECサイトを運営していると、突然こんな事態が起きることがあります。「カード情報が漏洩した」という報告が届いた——でもサイトを確認しても、見た目には何も変わっていない。TLS（HTTPS）もちゃんと使っている。それなのに、なぜ？
実はこのケース、フォームジャッキングと呼ばれる攻撃手法が原因かもしれません。ECサイトの決済フォームに不正なJavaScriptを埋め込み、入力されたカード情報をリアルタイムで攻撃者のサーバーへ送り続ける——サイトオーナーも利用者も気づかないまま、情報が流れ続ける手口です。
この記事では、フォームジャッキングの仕組み・攻撃手口・被害を防ぐための具体的な設定方法まで、現場で使えるレベルで解説します。ECサイト運営者、Web開発者、そして社内SEとして決済系システムに関わる方に、ぜひ知っておいてほしい内容です。
フォームジャッキングとは？
フォームジャッキング（Formjacking）とは、Webサイトの入力フォーム——特にオンライン決済フォーム——に不正なJavaScriptコードを仕込み、ユーザーが入力したクレジットカード番号・有効期限・セキュリティコードなどをリアルタイムで盗み取る攻撃手法です。
「Magecart（マジカート）攻撃」とも呼ばれ、2015年ごろから世界的に被害が拡大しています。大手チケット販売サイトや小売チェーンのECサイトが被害を受けた事例が国際的に報告されており、日本国内でも複数のECサイトでカード情報漏洩事件として表面化しています。
フォームジャッキングが危険な理由は、攻撃の精度にあります。フィッシング詐欺のように「偽サイト」に誘導するのではなく、本物のサイト上で本物の決済フローの中でデータを盗みます。利用者がどれだけ注意深くURL確認やHTTPS確認を行っても防ぎきれないのが、この攻撃の本質的な脅威です。
XSSとの違い
フォームジャッキングはXSS（クロスサイトスクリプティング）と混同されることがありますが、目的と手口が異なります。
・XSS: ユーザーのブラウザ上でスクリプトを実行させ、セッション盗用や改ざんを狙う
・フォームジャッキング: サーバー側のファイルやサードパーティスクリプトを汚染し、フォーム入力データの傍受を専ら目的とする
XSSは攻撃者がユーザーに悪意あるURLを踏ませる必要がありますが、フォームジャッキングは一度スクリプトが埋め込まれれば、そのサイトを訪問したすべてのユーザーが被害者になります。管理者が気づいて削除するまで、被害は静かに継続します。
攻撃の仕組み（敵を知る）
フォームジャッキング攻撃は、大きく3つのフェーズで進みます。
1. ターゲットサイトへの侵入
攻撃者がスクリプトを埋め込むには、まずECサイトのコードを変更できる権限を得る必要があります。主な侵入経路は以下の通りです。
・CMS・プラグインの脆弱性悪用: WordPressやMagentoの未パッチの脆弱性を突いてサーバーへ侵入し、テーマファイルやJavaScriptファイルを改ざんする
・管理画面への不正ログイン: 弱いパスワードや流出した認証情報を使ってCMS管理画面へ侵入する
・サードパーティスクリプトのサプライチェーン汚染: 広告配信・チャットツール・アナリティクスなど、自サイトに埋め込んでいる外部スクリプトのCDNや配信サーバーが攻撃され、汚染されたスクリプトが自サイト経由で配信される
サードパーティスクリプト経由のケースが特に深刻です。自サイトのコードを一切変えなくても被害が発生するため、「自分のサーバーは安全だから大丈夫」という認識が通用しません。信頼していた外部ベンダーのスクリプト配信サーバーが改ざんされた結果、そのスクリプトを読み込む何千ものサイトが同時に被害を受けた事例が国際的に報告されています。
関連する攻撃手法として、サプライチェーン攻撃全般についてはサプライチェーン攻撃とは？仕組み・被害事例・対策をわかりやすく解説でも詳しく解説しています。
2. スキマースクリプトの埋め込み
侵入に成功した攻撃者は、決済フォームを持つページにスキマースクリプト（盗聴スクリプト）を埋め込みます。このスクリプトは通常、高度に難読化されており、一見しただけでは正規のコードとほぼ区別がつきません。
スクリプトの動作はシンプルです。フォームの `submit` イベントを監視し、ユーザーが「購入する」ボタンを押した瞬間、入力フィールドの値（カード番号・有効期限・CVV）を読み取って攻撃者が管理するサーバーへHTTPSで送信します。概念的には以下のような動きをします。
# スキマースクリプトの概念的な動作（実際の攻撃コードは掲載しない） # 1. フォームの送信イベントを監視 # 2. submit時にカード番号・有効期限・CVVを取得 # 3. 攻撃者の外部サーバー（例: 正規ドメインに似た偽ドメイン）へPOSTで送信 # 4. 正規の決済処理もそのまま続行（利用者は気づかない）
正規の決済処理も同時に完了するため、ユーザーから見ると購入が正常に完了したように見えます。この「何事もなかったように見える」点が、フォームジャッキングの発覚を遅らせる最大の要因です。
3. データの窃取と収集
盗まれたカード情報は攻撃者のサーバーで収集され、ダークウェブで販売されるか、不正決済に直接利用されます。一度スクリプトが埋め込まれると、管理者が気づいて削除するまで被害が続きます。数週間から数ヶ月間、発覚しないケースも珍しくありません。
なぜ発覚しにくいのか
フォームジャッキングが長期間気づかれない理由は複数あります。
・サイトの見た目は正常: 購入フローも決済完了も正しく動作するため、ユーザーからのクレームが上がりにくい
・HTTPS通信中に起きる: TLSで通信が暗号化されていても、スクリプトはブラウザ内（暗号化される前）のフォームデータを読み取るため、TLSは意味をなさない
・スクリプトが難読化・暗号化されている: 普通のソースコードレビューでは見抜きにくい
・サードパーティスクリプト起点の場合: 自サイトのコードは変わっていないため、コードの変更履歴を確認しても発覚しない
・検知ログが残りにくい: 攻撃者のサーバーへの送信は正規のHTTPS通信に見え、WAFのデフォルトルールでは素通りしやすい
実際に被害が発覚するきっかけは、カード会社からの不正利用の集中報告や、セキュリティ研究者による外部からの発見であることが多く、被害を受けたサイト側が自ら気づくケースは少ないのが実態です。
具体的な防御手順
1. CSP（Content-Security-Policy）でスクリプトの実行を制限する
CSPは、ブラウザが実行を許可するスクリプトのソースを明示的にホワイトリスト化するHTTPヘッダーです。適切に設定すれば、許可されていないドメインからのスクリプト実行をブロックできます。フォームジャッキング対策として最も根本的な防御手段です。
# Nginx設定例（Content-Security-Policy） # 自ドメインと明示的に許可した外部リソースのみスクリプト実行を許可 add_header Content-Security-Policy " default-src 'self'; script-src 'self' https://www.googletagmanager.com https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; connect-src 'self'; frame-ancestors 'none'; " always;
まず `Content-Security-Policy-Report-Only` ヘッダーで試験運用し、正規スクリプトへの影響がないことを確認してから本番適用するのが安全です。CSPの設定・確認方法の詳細はセキュリティヘッダー完全ガイド（CSP・HSTS・X-Frame-Options）設定と確認方法を参照してください。
2. SRI（Subresource Integrity）でサードパーティスクリプトを検証する
SRI（サブリソース整合性）は、外部CDNから読み込むスクリプトやCSSのハッシュ値を `
