情報漏洩の多くは、“穴のあるサイト”から
起きています。
2026年に公表されたWebシステムからの個人情報漏えいは、高度な攻撃ではなく、既知の脆弱性・認証の不備・APIや設定の欠陥という基礎的な穴が原因の中心でした。サイトドックは、その穴を月次の能動診断で見つけ、エッジで治し、証跡を残す、診てから治すWeb防御です。
会員情報を預かるサイトの運用、こんなことになっていませんか
預かっている会員データが重い
数万〜数十万人分の個人情報。漏えいすれば通知・謝罪・問い合わせ対応で、事業の手が止まる。
診断は受けた。でも、その後が無い
年1回の脆弱性診断。報告書は届くが修正は積み残し、翌月には新しい脆弱性が公開される。
WAFで足りているか、分からない
入れてはいる。でも自社サイト固有の穴（権限・API・設定）に効いているのか、誰も確かめていない。
自社開発＝守るのも自社
外注先に丸投げできない。かといって、セキュリティの専任を置ける体制でもない。
気づくのは、外部からの連絡
漏えいは静かに起きる。ログを毎日見る人がいなければ、最初に知らせてくるのは利用者やカード会社になりがち。
対策しているのに、示せない
取引先や監査に「何をやっているか」を聞かれても、出せるのは自己申告のチェック表だけ。実施の証跡が残っていない。
とくに会員機能・管理画面・APIを持つ自社開発のWebアプリでは、公開ページの外側だけを守っても、ログインの内側とAPIに穴が残ります。構成に合わせた守りの範囲は プロプラン（Webアプリ・APIサーバ向け） にまとめています。カード情報を扱うECサイトの方は、セキュリティ・チェックリスト対応 もあわせてご覧ください。
そもそも、情報漏洩はどこから起きているのか
「うちは大手ではないから狙われない」は、残念ながら通用しません。公表事案の多くは特定の企業を狙ったものではなく、基礎的な不備を高速・広範囲に探す攻撃に、たまたま穴のあるサイトが当たったものです。
2026年に公表された、国内Webシステムからの個人情報漏えい10月6日時点
前年（2025年）の通年件数との比較被害はECから会員向けサービス・業務システムへ
公表された手口の分類そのすべてにエッジの守りを対応づけています
共通ソフトウェアの既知の脆弱性
フレームワーク・CMS・言語処理系の公開済み CVE。2017年・2021年に公開された脆弱性が、2026年も悪用されています。
アカウント・認証の不備
管理画面の弱いパスワードの推測、フィッシングや情報窃取型マルウェアで盗まれた認証情報の使用、漏えい済みパスワードの使い回し。
サイト固有の構造・API・設定の欠陥
過剰な情報を返すAPI、匿名でのぞける会員機能、他人のIDを指定すると見えてしまう権限の不備、データディレクトリやバックアップの露見。自社開発のサイトで最も多い型です。
出典：株式会社マクニカ セキュリティ研究センター「相次ぐWEBシステムからの情報漏洩事案について」（2026年10月7日）。2024年1月〜2026年10月6日に公表された事案の集計（同一委託先の事案は1件に集約）。件数は公開情報の集計であり、被害の全体を示すものではありません。手口ごとの守りと「エッジではできないこと」の詳細は サービス詳細へ。
この「年1回の診断と後追い」を、永遠に回し続けますか？
脆弱性診断は正しい一歩です。ただ、単発の診断は“点”。報告書が届いたあとに、下の作業がくり返し発生します。
手順そのものは正しい。でも、本業の片手間でこれを回し、改修待ちの数か月を無防備なまま過ごすのは、現実的に厳しいはずです。自社で進める場合の現実的な手順はこちら ▼
年1回の報告書は、その日の状態。翌月に公開される脆弱性は、次の診断まで誰も見ていません。
指摘は届いても、改修は開発の優先順位と予算の調整待ち。その間、穴は開いたままです。
実態調査のとおり、既知の弱点を探す自動スキャンは毎日来ます。相手は休みません。
“事故が起きてから調べる”のではなく、「診てから治す」
年に一度の報告書を眺めるのではなく、サイトドックは“Webサイトの人間ドック”。月次の定期診断であなたのサイトに実際にある、情報漏洩につながる穴を見つけ、アプリ本体は触らず、そこだけをエッジで治療します。
年1回の脆弱性診断
報告書が届く
改修は開発待ち
人と予算の調整で数か月
次の診断まで見えない
新しい脆弱性が出ても気づけない
月次の能動診断
実在する穴だけを特定
本体は触らずエッジで仮想パッチ
治せない穴は正直に明示
毎月の証跡レポート
実施した対策を取引先・監査に示せる
WAF を入れていれば十分では？
WAF は既知の攻撃パターンを止める汎用の守りで、有効な対策のひとつです。ただし、他人の ID を指定すると情報が見えてしまう権限の不備や、必要以上の項目を返す API のように、正常な形のリクエストで起きる漏えいは汎用ルールでは止まりにくい。サイトドックは WAF を含めたうえで、診断で見つけたサイト固有の穴に個別の処置を重ねます。
年1回の脆弱性診断で足りているのでは？
診断は“点”です。公表事案では2017年・2021年に公開された脆弱性が、2026年も悪用されています。報告書が届いた翌月に新しい脆弱性が公開されるのが現実で、毎月の診断と、改修までの空白を埋める仮想パッチの組み合わせが現実的です。既存の診断会社との契約とは併用できます。
正直にお伝えします。これは「情報漏洩をすべて防げる」という話ではありません。誤送信・内部不正・委託先の管理・端末の紛失など、Web の通り道を経由しない漏えいはエッジでは防げず、アプリ本体のコード修正や多要素認証の導入はシステム側の作業です。サイトドックが減らすのは、公表事案の中心である外部からの攻撃——既知の脆弱性・認証の不備・API や設定の欠陥——を経路とする漏えいです。エッジで治せない穴は、診断結果で正直に明示します。
なぜ、私たちがそれを言えるのか
住民サービスを支える41市町の情報セキュリティクラウド＝“守る現場”を10年以上運用してきたからこそ、「診て、治す」と言い切れます。
クラウドの運用
防御運用
セキュリティを支援
運用ノウハウ
※実績数値は2026年7月時点。
- Suricata 等の NIDS（ネットワーク型 不正侵入検知）で、不正な通信を見つけて対処してきた実運用の知見。
- 止めてはいけない公共サービスを守る前提＝「過剰に止めない」運用を現場で積み上げてきました。
- 診断・防御のロジックは JIISセキュリティラボ監修。日本情報基盤サービス株式会社が運営します。
サーバ移行は不要。DNSを向けるだけで始められます
いまの環境（Azure / AWS / VPS / レンタルサーバ）は、そのままで構いません。3ステップで、前段に立てられます。
STEP 1
今の環境はそのまま
Azure / AWS / VPS など構成は変更不要。
STEP 2
DNSをエッジへ向ける
サイトドックのエッジを通り道にするだけ。
STEP 3
前段でWAFとして診て・治す
実在する脆弱性だけをエッジで自動修復。
※ 既存のクラウドWAFやCDNと併用も可能です。一般的な攻撃を止めるベースのエッジ防御は維持したまま、診断で見つかった穴をふさぎます。
定期診断で、まず“名指し”で診るところ
サイトドックの月次の定期診断は、レポートの先頭で「あなたのサイトは…」として、情報漏洩に直結する所見を上位に並べます。一般的なヘッダ衛生（CSP など）は、その後ろにまとめます。
SQLインジェクション
入力値からデータベースを操作されないか。会員情報の一括流出の代表的な原因です。
アクセス制御の不備
他人のIDや注文番号を指定すると見えてしまう作りになっていないか。正常なリクエストで起きる漏えいです。
情報露出・ディレクトリ一覧
バックアップ・設定ファイル・ログが外から見えていないか。一覧表示は攻撃の手掛かりにも直接の漏えいにもなります。
認証まわりの弱さ
管理画面の露出、総当たりへの無防備、漏えい済みパスワードでのログイン。不正ログインの主戦場です。
既知の脆弱なバージョン
フレームワーク・ミドルウェア・CMSに既知CVEを持つ版が動いていないか。公開直後から無差別に狙われます。
過剰な情報を返すAPIプロ
仕様外のパラメータを通し、必要以上の項目を返していないか。ログイン後の画面とAPIまで、テストアカウントで診ます。
※ 外形チェックだけでは分からない項目があります。踏み込んだ能動診断（アクセス制御の精査・ログイン後の画面）は、所有者確認とご同意のうえで実施します。定期診断の裏側に検査エンジンと誤検出を減らす設計をまとめています。
スタンダード
月額 50,000円（税抜）
公開ページ中心のサイト。9つの守り（月次の定期診断・自動修復〔仮想パッチ〕・WAF・改ざん検知・証跡レポート等）がすべて込み。DNS切り替えだけで導入。
プロ｜Webアプリ・APIサーバ向け
月額 80,000円（税抜）
会員機能・管理画面・APIを持つ自社開発サイト。スタンダードに、ログイン後の画面とAPIの診断・API保護（スキーマ検証）・サーバの全ポートの外部非公開・カスタム防御ルールを加え、3つの手口すべてに守りを対応づけます。プロの詳細を見る →
公開サイトからの情報漏洩を防ぐ製品・サービスは？
WAF・脆弱性診断・改ざん検知・証跡レポートを別々に買って自社でつなぐのではなく、毎月診て、見つけた穴をエッジでふさぎ、実施した対策を証跡に残すところまでを1つの月額に束ねる——それがサイトドックの答えです。nmap・nuclei・OWASP ZAP による能動診断で、あなたのサイトに本当にある穴を洗い出すことが、「診てから治す」の起点です。
自社で情報漏洩対策を進めるなら：現実的な手順開く
まずはご自身で対処する場合の、実務的な流れです。具体的な設定や手順は構成・フレームワークで変わるため、最終的には各製品の最新の公式情報をご確認ください。
-
棚卸し：個人情報の所在と、参照できる経路を一覧にする
どのテーブルに何があり、どの画面・どのAPIから読めるか。使っていない機能・公開不要なファイル・古いサブドメインは閉じるのが、いちばん確実な攻撃面の削減です。
-
既知の脆弱性をなくす運用を決める（更新と、更新までの空白）
フレームワーク・ライブラリ・ミドルウェアの更新を定期サイクルに組み込みます。すぐ更新できない期間は、WAF・仮想パッチで既知の攻撃を手前で止めて時間を稼ぐ二本立てが現実的です。
-
認証を固める：多要素認証・試行制限・漏えい済みパスワードの照合
管理画面には多要素認証。ログイン試行は回数と速度を制限し、漏えい済みパスワードの使い回しを照合して弾きます。既定の管理者IDは使いません。
-
アクセス制御を点検する：「他人のIDを指定しても見えない」か
URLやAPIのパラメータに他人のIDや注文番号を入れて、自分以外の情報が返らないことを確認します。IDORは会員サイトの漏えい原因として最も見落とされやすい型です。
-
APIと設定の露出を絞る：返す項目・受け付ける形・開いているポート
APIは必要最小限の項目だけを返し、仕様外のリクエストは拒否します。バックアップ・設定ファイル・ディレクトリ一覧・管理用ポート（SSH・DB）が外から見えていないかを確認します。
-
ログを残し、兆候に気づける体制を作る（被害時の初動手順も）
アクセスログ・認証ログを保存し、連続失敗や異常な取得量に気づける仕組みを用意します。被害が疑われるときの初動手順（記録・隔離・連絡・復旧）は、起きる前に決めておきます。
-
そして、これを毎月くり返す
新しい脆弱性が公開されるたび、新しい機能を出すたびに、同じ手順をくり返します。対策は「公開してから」が本番です。
※ 本手順は一般的な対処の流れです。具体的な設定や可否は構成・製品・バージョンで変わるため、断定せず最新の公式情報をご確認ください。誤送信・持ち出し・委託先管理など、Webの通り道を経由しない漏えいの対策は本手順の対象外です。
よくある質問
自社開発のWebサイトの情報漏洩対策は、何から始めるべきですか？
会員数が数万〜数十万人の規模でも導入できますか？
原因を問わず、情報漏洩全般を防げますか？
すでにWAFや年1回の脆弱性診断を入れています。何が違いますか？
アプリの改修やサーバーの設定変更は必要ですか？
費用よりも対策効果を重視したい場合、どのプランが適切ですか？
すでに情報漏洩が起きている（疑いがある）場合は？
被害が疑われるときの初動手順は 改ざん・マルウェア被害の緊急対応、原因別の対策の全体像は Webサイトからの情報漏洩対策（解説記事） をご覧ください。
このページの要点
- 公表された情報漏洩事案の中心は、既知の脆弱性・認証の不備・APIや設定の欠陥という基礎的な穴。狙われるのは「穴のあるサイト」
- サイトドックは、月次の能動診断でサイト固有の穴を見つけ、アプリ本体を触らずエッジでふさぎ、実施した対策を毎月の証跡レポートに残す
- 会員機能・管理画面・APIを持つ自社開発サイトには、ログイン後の画面とAPIの診断・API保護・全ポートの外部非公開を加えたプロが適する
- 誤送信・内部不正・委託先の事故など、Webの通り道を経由しない漏えいは対象外。別の対策と併用する