サイバー攻撃を防ぐために実際にECサイトで実施したセキュリティ対策を全て公開

「カートはECサービスに任せている。でも、何年も前に追加したブログや問い合わせフォームは、誰が更新しているのだろう」

自社サイトを確認するとき、こんな疑問を持ったことはないでしょうか。商品ページは問題なく表示され、問い合わせも受け付けている。それでも、追加したプログラムの状態や、バックアップから戻せる範囲までは、すぐに答えられないことがあります。

最初に行うのは、EC・ブログ・フォーム・外部サービスの担当と、直近の確認記録を一枚にまとめることです。 そのうえで、使っていない処理を止め、必要な機能を直し、変更後の動作を確かめます。

株式会社レイズでは、あるEC事業者のサイトを点検し、独自プログラムやバックアップの扱いを見直しました。この記事では、その際に実施した内容と確認結果、自社で同じ点を確認する手順を紹介します。

対象は、ECの表示部分、追加したフォーム、併設する2つのブログが中心です。関連する公開3サイトで行った対応は、後半の別表にまとめています。2026年10月の作業記録に基づき、10月16日時点の状態を示します。

第9章には、10月21日に架空データで行った追加実験を掲載しました。顧客サイトの測定とは分け、説明用プログラムで同時受付の仕組みを確かめています。

ここでいう「全て」は、今回の点検範囲で実施した対応の一覧です。管理情報を使った個別調査・改修を含み、カートや決済基盤までを網羅した診断ではありません。どの対策も、変更した対象と、確かめた範囲を併せて紹介します。

1. ECのどこを誰が管理しているか整理する

同じサイトに見えても、管理する場所は異なる

ECサイトには、カート機能のほかにも、ブログ、商品紹介用の動き、問い合わせフォーム、外部の入力サービスなどが組み合わされています。一つのドメインで見られることと、すべてを同じ会社が保守していることは別です。

例えば、ECサービスが管理する機能と、制作時に独自追加したプログラムでは、更新する担当が異なる場合があります。futureshopも、店舗が独自に導入したプログラムについて、管理や公開後の更新対応を開発元・発注先へ確認するよう案内しています。futureshop：ECサイトのセキュリティ

今回も、まず確認する範囲を分けました。

自社では、まず次の順番で整理してください。

1. 商品ページ、ブログ、問い合わせ、外部サービスのURLと用途を並べる。
2. それぞれの社内担当、保守先、サービス提供元を書く。
3. 契約書や制作資料で、更新・障害対応・バックアップの分担を確認する。
4. 最後に何を確認したか、作業記録を添える。
5. 担当や状態が不明なものに、確認先と回答期限を付ける。

「保守契約がある」だけでは、作業範囲は決まりません。「ブログのプラグイン更新は含まれるか」「独自フォームの改修は誰が担当するか」まで具体的に確かめます。IPA：ECサイト構築・運用セキュリティガイドライン

新人社員：ECサービス側が、追加したブログも全部更新してくれるんですか？

R.A.I：追加したプログラムは管理担当を確認しましょう。サービスの契約範囲と、制作会社の保守範囲を一枚に書くところから始めます。

R.A.Iは、レイズの公式AIキャラクターです。この記事では、セキュリティを解説する架空の案内役として登場します。

変更する前に、元の状態と確認項目を残す

セキュリティの修正でも、商品リンクや問い合わせの動作が変わる場合があります。そこで、変更前のコード・設定を保全し、問題が起きたときに戻す方法を準備しました。

同時に、修正後に見る画面と操作を決めます。公開ページが表示されるか、必要なリンクが残っているか、フォームの項目・送信先が変わっていないか。修正対象によって確認するものを選び、PCとスマートフォンの両方で比較しました。

元の状態を保存するときは、公開ページから取得できる場所へ無造作に置かないことも必要です。バックアップの保管については、後半で詳しく説明します。

今回のEC・ブログで実施したこと

次の一覧には、コードや設定を変えた対応と、既存設定を点検した対応を含めています。後者は「点検・変更なし」と表示しました。

以下では、それぞれの対応を選んだ理由と、確認した結果を説明します。

2. 使っていない通知処理を停止し、残すフォームを見極める

画面から消えた機能も、送信処理が残ることがある

以前使っていた通知やフォームは、ページからリンクを外したあとも、サーバー側の処理が残っている場合があります。画面にボタンがないだけでは、その処理が呼び出されないとは判断できません。

今回、使っていないことを確認できた通知処理が2つありました。元のコードを保全したうえで、メールを送らない処理へ変更し、本番でも停止後の応答を確認しました。

一方、古いフォームの一つは、利用状況を確定できませんでした。そこで、削除せずに入力・送信方法・回数の制限を補強しました。必要な機能かどうかが分からない状態で停止すると、現場の問い合わせを失うおそれがあるためです。

自社で進めるときは、保守担当へ「どのページから呼び出されるか」「メールや別システムからも使われていないか」を確認します。未使用と判断したら、元の状態を保全してサーバー側の処理を停止し、古い入口からも送信されないことを確かめてください。IPA：安全なウェブサイトの運用管理に向けての20ヶ条

新人社員：ページにボタンがなければ、もう使えませんよね？

R.A.I：送信先の処理だけ残っていることがあります。画面とサーバー側の処理を、両方確認しましょう。

3. フォームは入力・同時受付・記録の失敗まで確かめる

ブラウザの必須項目だけに頼らない

問い合わせフォームでは、名前、メールアドレス、本文などを受け付けます。画面で「必須」と表示されていても、サーバー側で同じ条件を確認する必要があります。

例えば、文字を受け付ける欄へ想定外の種類のデータが来た場合、本文が極端に長い場合、メールアドレスの形式が不正な場合に、どう扱うかを決めます。入力条件は、画面の見た目ではなく、処理を受ける側にも必要です。WordPress：Validating Data

今回の主要4フォームでは、共通の処理を見直し、文字の種類・長さ・データの型などの条件を補強しました。古いフォームにも、必要項目やメールアドレスの確認、送信方法の限定、ボット向けの簡易対策を加えました。

ボット向けの簡易対策には、人が通常入力しない欄への記入を手掛かりにする方法もあります。ただし、それだけで不正送信を止めようとはせず、入力条件や受付数の制限と組み合わせました。

回数制限は「確認」と「記録」を一組にする

フォームの送信回数を制限するには、これまでの受付数を読み、上限内かを判断し、新しい受付数を記録します。ここで注意したいのが、複数の入力が同時に届く場合です。

説明用の例として、残り受付枠が1件の状態を考えます。処理Aも処理Bも、更新前の記録を見て「あと1件受け付けられる」と判断すると、両方を受け付ける可能性があります。1件ずつ順番に送った試験では、このすれ違いが見えない場合があります。

そこで今回、受付記録を読む → 上限を判断する → 記録を更新するという一連の処理を、同じ排他処理の中に収めました。排他処理は、同じ記録を複数の処理が同時に書き換えないための仕組みです。

ファイルのロックを使う場合は、同じ記録に触る処理が同じ方法でロックを使うことなど、動作の前提があります。複数サーバーで受付を分担している構成では、共有する記録の管理方法から検討します。PHP：flock

記録できないときに、制限を飛ばして送信しない

制限用の記録が壊れている、書き込めない、必要な情報を取得できない。このような場合に「確認できなかったので、そのまま送る」とすると、制限を維持できません。

今回は、受付記録を正常に扱えない場合に、メール送信を進めない処理へ補強しました。制限の仕組みが動かないときに、受付成功の表示だけを返さないことも重要です。

読者のサイトで同様の対応をするなら、利用者へ伝えるエラー表示と、再試行や電話などの代替窓口も確認してください。社内では、いつ、どの処理が失敗したかを調べられる記録を用意します。エラーの内容に秘密情報や問い合わせ本文を必要以上に含めないようにします。

実施した試験と、メールの到達確認を分ける

主要フォームの共通処理は、実メールを送らない環境で60ケースを確認しました。同時処理や記録の異常も含めています。古いフォームでは、メール処理を模擬化した31ケースを確認しました。

本番では、不正な入力を拒否することや、送信を起こさない条件での応答を確認しました。主要4フォームすべての実メール到達を確認した結果ではありません。実際に宛先へ届くかは、フォームと受信先を特定して別に確かめます。

新人社員：1回送れたら、フォームの確認は終わりですか？

R.A.I：続けて届く場合、同時に届く場合、記録できない場合も確かめます。必要なメールが届くかは、対象を決めて別に確認しましょう。

外部フォームも、自社の設定を確認する

外部サービスを使うフォームでは、管理画面の設定を確認しました。連続投稿の制限、通知先、自動返信、公開ページの個人情報に関する案内などが対象です。今回の対象では、基本設定を点検した結果、設定を変えずに維持しました。対象フォームの通知メールの到達も確認しています。

外部フォームは、契約プランや提供形態によって使える機能が異なります。サービスの紹介ページを読むだけで、自社のフォームに同じ機能が設定されているとは判断しません。現在の管理画面と契約内容を照合してください。フォームメーラー：セキュリティ

自社での確認は、次の順に進めます。

1. 独自フォームか、外部サービスかを確認する。
2. 入力条件と送信制限を確認する担当を決める。
3. 通常・異常・同時受付の試験条件を作る。
4. 検証環境で外部送信を模擬化し、結果を記録する。
5. 本番反映後は、対象を限定した表示・応答確認と、許可された到達確認を行う。

4. 古いJavaScriptを整理し、文字を安全に表示する

読み込まれる部品を一覧にする

サイトを長く運用すると、過去の改修で追加した部品が残り、同じライブラリを複数回読み込むことがあります。担当者が変わると、どの機能に必要なのかが分からなくなる場合もあります。

今回も、対象のヘッダーやページで古いjQueryや重複した読込を確認しました。使っている機能を調べ、一部を標準JavaScriptへ置き換えて、不要な読込を除去しました。

古い部品を見つけたときは、開発元の修正情報と、自社での使い方を確認します。例えばjQueryでは、過去にHTMLを扱う処理のセキュリティ修正が行われています。版が古いという事実だけで、その画面で攻撃が成立したと断定することはできませんが、更新や置換を検討する根拠になります。jQuery公式：3.5.0のリリース

今回の対応は、確認した対象の古い・重複した読込の整理です。既存機能に必要な共通部品は残しており、すべてのライブラリを最新版へ更新した結果ではありません。

商品名は文字として表示し、URLは別に確認する

閲覧履歴の表示では、商品名などのデータをHTMLの文字列へ組み込む処理を見直しました。画面の部品を組み立て、商品名は文字として代入する方法へ変更しています。

例えば、架空の商品名「<限定> 収納用品」を表示するなら、その文字をそのまま見せたいはずです。HTMLとして解釈させる必要はありません。JavaScriptでは、文字の表示にtextContentなどを使う方法があります。OWASP：DOM based XSS Prevention

一方、リンクや画像のURLは、文字として表示するだけでは目的を果たせません。今回はHTTPSであることや、許可するホストかどうかを別に確認しました。文字、HTML、URLでは、確認する条件が異なります。WordPress：Escaping Data

この表示処理は、架空データを使う20ケースなどで確かめました。確認したのは対象の表示処理とURL条件であり、サイトの全画面を対象にしたXSS診断ではありません。

古い依存を外したあとも、必要な操作を維持する

部品を削除した結果、画像が動かない、商品リンクへ進めない、スマートフォンで操作できない、といった状態にしてはいけません。

対象ページのスライダーは、標準JavaScriptとCSSで組み直しました。画像・文章・リンクを維持し、PC・スマートフォン、スワイプ、ボタン、キーボードの操作を確認しています。これは、古い依存を整理する際に、必要な機能を維持するための対応です。

フッターでは、使われていないフォーム関連の処理を整理し、注意書きの書換えを意図した対象に限定しました。対象5ページをPC・スマートフォンの計10条件で比較しています。なお、画面側の呼出コードを消したことだけで、サーバー側のAPIも廃止したとは判断しません。

自社では、次の順に依頼すると確認が進みます。

1. ページが読み込むスクリプトと、呼び出す場所を一覧にする。
2. 必要なもの、重複、廃止候補を分ける。
3. 更新・置換・廃止の方法と、影響する機能を決める。
4. 表示データとURLの扱いを確認する。
5. 商品リンク、履歴、スライダー、問い合わせをPC・スマートフォンで比較する。

新人社員：新しいライブラリを入れれば、表示処理も安全になりますか？

R.A.I：更新に加えて、データを画面へ渡す方法も確認します。文字の表示とリンク先の確認は、それぞれ必要です。

5. 独自プラグインの権限と、設定を消さない処理を直す

ログインできることと、その操作を許可することは別

WordPressへ独自機能を追加している場合は、操作を受ける処理にも確認が必要です。管理画面にボタンを表示しないだけでは、その処理の保護にはなりません。

今回の対象プラグインでは、管理に必要な権限があるか、正規の画面操作に伴う値が付いているか、想定した送信方法かを確認する処理を追加しました。直接実行への制限も加えています。

ここで使うnonceは、意図しない操作を第三者に実行させられる攻撃であるCSRFへの対策に使う値です。操作権限の代わりにはなりません。WordPressの公式文書も、nonceに認証・認可を任せず、操作権限を別に確認するよう説明しています。WordPress：Nonces、current_user_can

2つのブログでは、想定しない送信方法や、nonceがない・一致しない条件で拒否することを確認しました。正規の値を使う確認も、AI生成や投稿を発火させない条件で行っています。

新人社員：管理画面に入れない人は、その処理も動かせないですよね？

R.A.I：画面の表示だけで判断せず、処理を受ける側も確認しましょう。その操作を許可された人か、そこで確かめます。

再有効化のたびに設定を初期化しない

もう一つ確認したのが、プラグインを有効にしたときの処理です。初回の導入では必要だった初期化が、再有効化でも動くと、運用中の設定を消す原因になります。

対象プラグインでは、既存の設定テーブルがある場合に、それを破棄して作り直さない処理へ見直しました。別の独自プラグインでは、一度だけ必要だったデータ構造の変更が繰り返し実行されないよう、破壊的な処理を撤去しました。

プラグインのデータ更新は、現在の構造や版を確認して進める必要があります。WordPressの開発文書にも、既存構造と必要な構造を比較する仕組みや、データ構造の版を記録する考え方が示されています。WordPress：Creating Tables with Plugins

実データを壊さずに、処理と変更前後を確認する

再有効化を確かめるために、本番で何度もプラグインを無効・有効にする方法は選びませんでした。まず模擬データで処理を確認し、反映前後の実データの構造や設定を照合しました。

破壊的な処理を撤去したプラグインでは、ローカルの84ケースに加え、本番と同じPHP実行環境で、模擬DBを使って対象の処理を20回呼び出しました。その条件では、DBへの呼出が0回であることを確認しています。実際の本番データを使って再有効化を20回行ったという意味ではありません。

自社の独自プラグインでは、開発元と更新担当を確認したうえで、「誰が何を操作できるか」「有効化時に何が実行されるか」「既存設定が変わらないことをどう確かめたか」を尋ねてください。

新人社員：再有効化のテストは、本番で何度も試すんですか？

R.A.I：まず模擬データで調べます。今回も、模擬DBで処理を呼ぶ試験と、本番データの変更前後の照合を分けています。

6. 秘密情報とバックアップを公開範囲から切り離す

アプリが読むことと、Webで配信することを分ける

外部サービスへ接続するAPIキーなどは、アプリが使うための認証情報です。Webページの閲覧者へ配信する必要はありません。

今回の対象モジュールでは、秘密を含むファイルを公開範囲外へ移し、公開側には秘密そのものを含まない読込処理を置きました。そのうえで、アプリからの読込が一致すること、対象URLへアクセスしても秘密を配信しないこと、通常のブログ表示を維持していることを確かめました。

これは対象モジュールの保管方法を変えた対応です。キーの置き場所を変えることと、漏えいが疑われるキーを失効・再発行することは別の作業です。秘密の管理では、保管・利用権限・更新・失効をそれぞれ確認します。OWASP：Secrets Management

公開範囲外へ移せば、サーバーへの侵入など、あらゆる経路から秘密を守れるという意味ではありません。ここでは、Webから取得される経路を制限し、必要なアプリの読込を維持しています。

バックアップは、保護設定が書き換わる操作のあとにも確認する

バックアップには、記事や画像に加え、設定やデータベースが含まれる場合があります。保存できるだけでなく、公開ページから取得されないことも確認しなければなりません。

今回、対象のバックアップファイルを公開範囲から退避し、アクセスを拒否する設定を行いました。ところが、確認を進めると、プラグイン自身の処理によって保護用の設定ファイルが書き換わることが分かりました。

一度確認した拒否設定が、その後の操作でも維持されるとは限らなかったのです。

そこで、プラグインが書き換える場所だけに依存せず、その上位側で保護する方法へ変更しました。無害な確認用ファイルを使い、プラグインの無効化・再有効化のあとにも拒否応答を確認しています。同時に、通常のブログとCSSが表示されることも確かめました。

この経験から、確認項目には「現在は保護されているか」に加え、「設定を書き換える操作のあとも保護されているか」を入れる必要があると分かります。将来の更新では、その時点の変更内容に合わせて再確認します。

IPAも、公開すべきでないファイルを、インターネットからアクセスできない場所へ保管するよう案内しています。IPA：安全なウェブサイトの運用管理に向けての20ヶ条

新人社員：今はアクセスを拒否しているなら、以前も問題なかったと言えますか？

R.A.I：確認できるのは、試験した時点の応答です。過去のアクセスについては、別に記録を調べる必要があります。

「権限エラー」の表示から、原因を一つずつ切り分ける

バックアップ作成では、権限に関するエラーにも対応しました。ここで、すぐに書込権限を広げることはしませんでした。

最初に、処理を実行する利用者とファイルの所有者、設定されている権限を確認します。次に、小さなファイルを実際に書けるかを確かめます。今回の環境では、必要な場所へ書き込むこと自体は可能でした。

さらに調べると、プラグインが保護ファイルを作るために使うPHP関数が、実行環境で無効になっていました。画面のエラー名だけでは、この違いを判断できません。

そこで、公式配布物と照合した保護ファイルを補う方法を取り、バックアップの作成・取得を確認しました。書込権限を一律に広げたり、環境側で無効になっている関数を有効にしたりする対応はしていません。

読者のサイトで同じエラーが出た場合も、この結果だけを見て同じファイルを置くのではなく、保守担当に「実際に書けないのか」「必要な関数や環境条件がそろっているか」を確認してもらってください。

新人社員：「権限エラー」なら、書込権限を広げれば直りますか？

R.A.I：まず、本当に書けないのか確かめます。画面に出たエラー名と、実際の原因が一致しない場合があります。

警告は、何を検知しているかを調べてから扱う

別のバックアップ機能では、復元用ファイルに関する警告が表示されました。警告だけで漏えいを断定せず、指摘されたファイルの内容と、外部から取得できるかを確認しました。

確認した範囲では、対象の状態ファイルにDB接続情報はなく、展開されたDBやアーカイブもありませんでした。外部からのアクセスは拒否され、通常ページの表示は維持されていました。公式の整理機能を使ったあとにも保護用ファイルが検知される状態があり、確認結果を記録して、対象管理者の通知を整理しました。

検知処理自体を修正したわけではないため、修正版と通知設定の見直しは継続する作業として残しました。「警告が気になるから非表示にする」を一般的な解決方法にはできません。

自社で確認するときは、次の順に進めます。

1. 管理画面やサーバー設定から、対象ファイルと公開範囲を確認する。
2. 必要なアプリの読込を維持して、公開を制限する。
3. 無害な確認用ファイルなど、対象を決めた方法で未認証アクセスを確かめる。
4. 通常ページ、画像、CSSが表示されることも確認する。
5. プラグイン操作や復元後に、保護が維持されるか再確認する。

機密ファイルをダウンロードして確認材料を増やす必要はありません。過去に第三者が取得したかどうかは、現在の拒否応答だけでは判断できません。

7. 更新した状態を確認し、バックアップから何が戻るか確かめる

プラグインを一つずつ更新し、有効状態も確認する

今回、2つのブログで、サイトごとの更新作業として計7件の一般プラグインを更新しました。同じ製品を両方で更新したものがあるため、7種類の製品という意味ではありません。

更新は対象を確認して進め、変更後の版、有効・無効の状態、公開ページの表示を確かめました。元が無効だったプラグインは、確認後に元の無効状態へ戻しています。

管理画面に「更新完了」と出たことに加え、自社が使う機能が維持されているかを確認します。独自の追加機能がある場合は、その設定や動作も対象に含めます。

ファイルとデータベースを一組で保管する

WordPressのバックアップでは、ファイルとデータベースの両方が必要です。画像やプログラムのファイルがあっても、記事や設定を持つデータベースがなければ、同じ状態に戻せません。WordPress：Backups

今回は2つのブログのバックアップを作成し、暗号化してサーバー外の保管先へ保存しました。復元時には、外部へのメールやAPI通信を止めた隔離環境を使い、保存した内容を戻して確認しました。

バックアップを暗号化する場合は、復号に必要な鍵の管理も必要です。保管先が故障したとき、誰がどの経路でバックアップと鍵を使えるかを確認してください。ファイルを一度保管できたことと、継続的な保管運用の完成は区別します。

記事・画像・独自設定を照合する

復元したあと、記事、画像、独自設定などを確認しました。次の数値は、作業時点の保存・復元対象です。

単に件数がそろったことだけを、完全な復元の証明にはしていません。対象ファイルの照合や設定の確認を行い、インポート処理によって一時データが変わる場合は、その差の理由も記録しました。

使用する移行ツールが何を取り込み、何を除外するかも確認します。ツールの手順に従うことと、自社の必要なデータが戻ったことの確認は、それぞれ必要です。ServMask：Migration Instructions

ブログが戻ることと、EC全体が戻ることは分ける

ブログAのローカル復元では、EC側から配信されるスクリプトがバックアップに含まれていませんでした。外部通信も遮断していたため、画面の一部で外部依存に関するエラーが残りました。

記事、ローカルの画像、独自設定は確認できましたが、ECとの連携を含む画面全体の試験は合格としていません。カートや決済を含む復旧まで確認したとも言えません。

復元の確認は、「戻せた／戻せなかった」の一言で終えず、何が戻り、何が別の復旧作業を必要とするかを分けて残してください。そうすると、次に必要な保全対象や確認条件が具体的になります。

新人社員：バックアップのファイルが作れたら、復旧準備は完了ですか？

R.A.I：別の環境に戻して、記事・画像・設定を確認しましょう。ECとの連携や購入操作は、その先にある確認です。

復元後に、あとから加えたセキュリティ修正を適用する

バックアップは、保存した時点の状態です。保存後にプラグインを直したり、秘密の置き場所を変えたり、公開制限を追加したりした場合、その変更が古いバックアップに含まれているとは限りません。

今回も、バックアップから戻したあとに再適用する修正や、別に配置する非公開設定がありました。復元手順には、データを戻す操作に加え、その後に必要な修正を記録しています。

自社の復元手順には、次の6つを含めてください。

1. ファイルとデータベースの取得日時、保存対象。
2. 保管先、暗号化の方法、鍵を利用できる担当。
3. 外部送信を止めた検証環境への復元方法。
4. 記事、画像、設定などの照合項目。
5. 外部サービスや、バックアップに含まれない設定。
6. 取得後の修正と、復元後に確認する業務操作。

新人社員：古いバックアップへ戻せば、直した設定もそのままですか？

R.A.I：保存した時点へ戻るので、あとから加えた修正が含まれない場合があります。復元後に適用する修正も一緒に残しましょう。

更新の準備と、本番への適用を分けて記録する

2026年10月16日時点で、EC併設環境のPHP更新は、隔離環境での互換性確認と提供元との日程調整まで進めていました。本番の更新完了を示す状態ではありません。ブログの子テーマ化も、候補の作成・比較と本番切替を分けて管理しています。

PHPはWebプログラムを動かす実行環境です。更新先のサポート状態を公式資料で確認し、利用するプログラムとの互換性、変更後の確認、問題時の切戻しまで決めて進めます。PHP：Supported Versions

「検証環境では動いた」「更新日が決まった」「本番に適用した」「本番で必要な機能を確認した」は、別々の状態として記録してください。

8. 拒否できることと、必要な機能が動くことを両方確認する

セキュリティ対策では、拒否すべき入力が止まることと、通常の利用を維持することの両方が必要です。保護設定を厳しくした結果、商品画像が見えない、問い合わせを送れない、といった状態にしてはいけません。

今回も、対象ファイルへの拒否応答と、通常ページやCSSの表示を組み合わせて確認しました。JavaScriptの整理では、PC・スマートフォンの画面と操作を比較しています。

確認結果を読むときは、次の違いを見ると、どこまで確かめたかが分かります。

試験を実施した日時、対象、条件、結果、未確認事項をそろえてください。「対策済み」とだけ書かれた報告では、次の担当者が同じ状態を確認できません。

IPAも、限定した検査で問題が見つからなかったことを、サイト全体の安全宣言にはつなげないよう説明しています。IPA：安全なウェブサイトの作り方

新人社員：チェックが全部緑なら、会社のサイト全体が安全ですか？

R.A.I：その緑が何を確認した結果かを見ましょう。対象、条件、日時、まだ試していない操作まで記録にそろっていることが大切です。

関連する公開3サイトでも行った対応

EC・ブログとは別に、関連する3つの公開サイトでも点検・対応を進めました。次の表は、その実施内容です。すべての項目を3サイトすべてへ適用した意味ではなく、必要な対象ごとに対応しています。

WAFは、Webへの通信を検査して不正な通信を抑止する仕組みです。設定の有効表示を確認することと、特定の攻撃を遮断した結果を得ることは区別します。提供元のWAF案内

メール送信に使うPHPMailerなどの部品も、公式の修正情報を確認して更新します。PHPMailer公式リリース

フォームでは、送信側の処理が成功したことに加え、対象の受信メールでも到達を確認しました。一方、この確認結果を、別のフォームやすべての宛先の結果として使うことはできません。サイトが複数ある場合は、サイト名・フォーム・受信先を記録の単位にしてください。

9. 独自検証：順番に送れるフォームは、同時受付でも制限を守るか

上限を5件にした説明用プログラムで、同時受付が46〜60件に増えることを確認しました。しかも、受付記録には「5件」と残っていました。 一方、受付数の確認から更新までを一つの排他処理に収めると、10回すべて受付5件・記録5件で一致しました。

第3章で説明した「確認と更新のすれ違い」が、どう結果に表れるか。2026年10月21日、レイズのローカル環境で架空の問い合わせを使い、説明用のPHPプログラムを実行しました。実行と集計はCodexが担当しています。顧客のコードや実データは使用していません。

60件の入力を、順番に処理する場合と同時に処理する場合で比較

比べたのは、次の2方式です。受付上限、入力内容、記録形式はそろえました。

架空の氏名、example.invalidのメールアドレス、実験用本文を持つ60件を用意しました。実メールの代わりに、受付成功のIDを別のファイルへ記録する模擬送信を使いました。

順次条件では1プロセスで1件ずつ処理。同時条件では12プロセスを同じ開始合図で動かし、各5件、合計60件を処理しました。60件が一斉に動く条件ではありません。正常な同時条件では、処理中の入力が最大12件重なったことを実行記録でも確認しました。

競合を観察するため、受付可能と読み取った直後に、両方式とも20ミリ秒の人工的な待ち時間を入れています。 Aは読み取りのロックを解除したあと、Bはロックを保持したまま待ちます。この実験から、実際のサイトで同じ問題が何割の確率で起きるかは分かりません。

環境はmacOS上のPHP 8.5.5 CLIです。ブラウザからHTTPでフォームへ送信する試験ではなく、受付制限の処理を直接実行しました。各条件を10回繰り返し、その都度、受付記録を0件へ戻しました。

順次では両方式とも5件。同時では差が出た

次の数値は、各60件を処理した1回あたりの結果です。幅がある欄は10回の最小〜最大を示します。通常の40回で、内部エラーとタイムアウトはともに0件でした。

Aの同時条件で受け付けた件数は、順に60、60、46、58、57、60、60、60、60、60件でした。10回すべてで上限を超えています。複数の処理が同じ古い件数を読み、同じ「次の件数」を書き戻すため、受付記録だけを見ると超過を見落とします。

そこで、受付結果のIDと、別に保存した模擬送信のIDも照合しました。全試行で両者は一致し、Aの同時条件では「台帳は5件だが、模擬送信は46〜60件」という差を確認できました。

記録が使えないときは、送信へ進まなかった

Bについて、受付記録を書き込み用に開けない場合と、内容を壊した場合も各1回、60件で試しました。

読み取り専用の条件では、OSが書き込み用のオープンを拒否することを確認しました。記録破損の条件では、内容を解析できず処理が止まりました。どちらも「上限に達したので拒否」とは異なる内部エラーとして記録し、模擬送信は呼び出されませんでした。ディスク容量不足や、書き込み途中での障害は試していません。

保守担当に確認するのは、成功表示と受付記録の両方

この実験から、順番に送って上限を守れたという結果だけでは、同時受付の制限は確認できないと分かります。また、台帳の件数だけで判断せず、実際に許可した件数や送信処理の呼び出しと照合する必要があります。

保守担当には、「同時受付の入力数・許可数・拒否数・エラー数」「受付記録との一致」「記録が使えない場合の送信数」をセットで確認してください。付属の記録シートでは、2ページ目の項目04と、3ページ目の改修前後の結果欄に残せます。

今回のBで確認できたのは、一台のMac上で、同じファイルとロックの使い方を共有する説明用処理の結果です。PHPのflockも、関係する処理が同じ方法でロックに協調することを前提とします。PHP公式：flock

IP別・時間帯別の制限、複数サーバー、DDoS耐性、実際のメール到達は測っていません。受付記録の更新後にプログラムが停止した場合の送信との整合性も未検証です。人工待機とプロセス起動を含むため、処理速度の比較には使いません。

実測結果の全43試行を見る／各試行の測定表CSV。通常40試行と異常2試行に、正常入力1件の事前確認を加え、合計2,521件の入力記録を保存しました。

10. 自社のEC担当者・保守会社へ確認する12項目

ここまでの対応を、自社の確認へ置き換えるためのチェックリストです。自分でコードを変更できなくても、対象と担当を整理して、確認結果を依頼できます。

状態は「確認済み／未対応／不明／対象外」で記録します。判断できる根拠がない場合は「不明」とし、対象外には理由を残してください。不備と不明点が両方ある場合は「未対応」とし、不明点も併記します。

記入用の確認リストCSVと、印刷して使うECセキュリティ対策・確認記録シートPDFも用意しました。PDFには、対象の一覧、12項目、改修前後の記録、復元の確認欄を収録しています。

新人社員：自分でコードを直せなくても、進められますか？

R.A.I：対象と担当を整理し、この表で確認結果を依頼できます。「対策済み」だけでなく、何を確かめたかを書いてもらいましょう。

保守会社への確認依頼文

次の文面とチェックリストを渡すと、現状確認と、改修が必要な項目の整理を依頼できます。

当社のECサイト、ブログ、問い合わせフォームについて、管理対象と担当範囲を整理したいと考えています。

確認項目ごとに、次の内容をご記入ください。
・対象のサイト・機能
・現在の対応内容
・確認日と確認方法
・確認できた結果と、未確認の事項

改修が必要な項目は、変更内容、通常機能への影響、変更前の保全、確認方法、復旧手順、費用・日程をご提示ください。

外部へのテスト送信や購入操作が必要な場合は、対象と方法も記載してください。

回答を受け取ったら、「未対応」と「不明」について、次に行う作業、担当、期限、完了を判断する条件を決めます。一度の点検で終えず、更新や機能追加のあとにも確認する項目を引き継いでください。

具体的な異変が既にある場合は、通常の点検に先立って、不正アクセス・情報漏えいが疑われたときの初動対応マニュアルを参照してください。

11. よくある疑問

ECサービス側の対策だけでは足りないのですか？

サービス本体の管理に加え、独自に追加したブログ、フォーム、JavaScriptなどの管理範囲を確認します。サービス提供元の説明、保守契約、制作会社の作業記録を照合し、更新・改修・バックアップを誰が担当するか決めてください。

今回の対策でサイバー攻撃を完全に防げますか？

今回示したのは、対象の処理や設定を変更し、決めた条件で確認した結果です。すべての攻撃を防ぐ結果ではありません。新しい脆弱性や、構成・利用方法の変化に合わせて更新と点検を続けます。

WAFがあれば、コードの修正は不要ですか？

WAFによる通信の検査と、コード内の入力・権限確認、ファイルの公開制限は、それぞれ役割が異なります。今回も関連サイト側のWAF設定と、対象コードの修正を別に扱いました。WAFが有効だから内部の確認を省けるとは判断しません。

プラグインは全部削除した方がよいですか？

まず利用状況、更新担当、代わりの機能を確認してください。使わないものは整理し、必要なものは更新・修正して動作を確かめます。用途不明のまま削除すると、表示や管理業務に影響する場合があります。

バックアップを取れば、ランサムウェア対策も完了ですか？

この記事で扱うのは、Webの対象データの保管と復元です。社内端末、アカウント、ネットワーク、復旧時の業務手順なども確認が必要です。会社全体の備えは、自分でできるランサムウェア対策50項目へ進んでください。

無料のAIセキュリティ検査で、この記事と同じ作業をしますか？

無料検査は、公開されているWeb情報から状態を確認する入口です。この記事で紹介した内部コードの調査、設定変更、バックアップ復元などは、管理情報と個別の対応範囲を決めて進める作業です。

出典・参考資料

技術・運用の参考資料は以下のとおりです。確認日：2026年10月16日。対象事業者での実施内容と数値は、レイズの2026年10月の作業記録に基づきます。

1. IPA：ECサイト構築・運用セキュリティガイドライン — ECの構築・運用で確認する対策。
2. IPA：安全なウェブサイトの作り方 — 入力・出力・権限等と、検査範囲の考え方。
3. IPA：安全なウェブサイトの運用管理に向けての20ヶ条 — 公開範囲、不要な機能、更新、記録。
4. futureshop：ECサイトのセキュリティ — 独自導入プログラムの管理と更新。
5. WordPress：current_user_can — 操作権限の確認。
6. WordPress：Nonces — nonceの用途と権限確認との違い。
7. PHP：flock — ファイルの排他処理と前提条件。
8. WordPress：Validating Data — 入力値の検証。
9. WordPress：Escaping Data — 出力先に応じた処理。
10. OWASP：DOM based XSS Prevention — ブラウザでのデータ表示。
11. jQuery：3.5.0 Released — HTML処理に関する過去の修正例。
12. WordPress：Creating Tables with Plugins — プラグインのデータ構造と更新。
13. WordPress：Backups — ファイル・データベースの保全。
14. OWASP：Secrets Management — 秘密情報の保管・利用・失効等。
15. PHP：Supported Versions — サポート状態の確認。
16. フォームメーラー：セキュリティ — 提供元の公開説明。現契約の設定は別に確認。
17. お名前.com 共用サーバーSD：WAF案内 — 関連サイト側のWAF設定。
18. PHPMailer：7.1.1公式リリース — 関連サイトで更新したメール部品。
19. ServMask：Migration Instructions — バックアップのインポート手順。

自社サイトは、どこから確認すればよいか

まずは、公開されているWeb情報から確認できる項目をチェックしてください。Web AI Securityでは、公開最大10ページ・全40項目を、目安約3分で検査します。

結果を見ながら、保守担当へ確認することと、次に取り組む対策を整理できます。結果の見方は無料のセキュリティ相談でも相談できます。内部の詳細調査や修正は、内容と費用を合意して進めます。