mirolabo

CSPは「全サイト必須」ではない ― 自社サイトに必要かを5分で見分ける

中小企業サイトの多くがCSP（Content Security Policy）未対応です。ただし、すべてのサイトにCSPが必須かというと違います。自社サイトに必要かどうかを、サイトの種別から見分ける方法を整理します。

英国航空（British Airways）は2018年、自社の決済ページに忍び込んだわずか数十行のスクリプトによって、約38万件のクレジットカード情報を抜き取られました。入力内容を攻撃者のサーバーへ送っていたこのコードは、CSPで「どこへ送ってよいか」を制限していれば防げた事例として、いまでも引用されます。

このような事件を見ると「うちのサイトもCSPを入れなければ」と思いがちです。ただ、すべてのサイトにCSPが必須というわけではありません。自社サイトの種別で必要性が大きく変わります。

CSPは「XSS対策」のための仕組み

CSP（Content Security Policy）は、サイトがブラウザに「このサイトで実行していいスクリプトはこのリストの中だけ」と宣言する仕組みです。攻撃者が悪意あるスクリプトを画面に差し込もうとしても、リストにないスクリプトはブラウザが実行を拒否します。

CSPが守るのは、XSS（クロスサイトスクリプティング）という攻撃。ざっくり言えば「攻撃者が自社サイトに細工して、訪問者のブラウザで悪意あるスクリプトを動かす」攻撃です。

ここで重要なのは、XSSが成立するには「攻撃者が新しいスクリプトを差し込む経路」が必要だということです。その経路は、サイトが動的かどうかに依存します。

自社サイトはどっちか

ざっくり次の表で、自社サイトがどこに該当するか確認してください。

CSPの優先度が高いサイト（CSPが活きる）

  • 予約フォーム・問い合わせフォームがある
  • 会員ポータル・ログイン機能がある
  • 物販やオンライン決済機能がある
  • WordPressや他のCMS（コンテンツ管理システム：管理画面からブログ記事やページを更新できる仕組み）で作られている

CSPの優先度が低いサイト

  • 会社概要・営業時間・事業内容を載せているだけの情報サイト
  • フォーム・ログインがなく、動的な処理をしていない静的サイト

判断のポイントは「訪問者がサイトに何かを入力するか」「裏でCMSが動いているか」です。

WordPressを使っている会社は特に注意

中小企業のサイトはWordPressで作られていることが多く、これがひとつのリスク源になります。WordPressはプラグインの脆弱性が頻繁に発見されるソフトウェアで、更新されずに放置されたプラグインがXSSの入口になります。

具体的なシナリオを一つ挙げます。

予約カレンダーや問い合わせ系のプラグインに脆弱性があり、URLパラメータをそのまま画面に表示する処理が存在したとします。攻撃者は次のような細工をしたURLを作ります。

https://your-company.co.jp/?date=<script>...</script>

これをSMSやメールで「ご予約の確認はこちら」と顧客に送ります。顧客がリンクをクリックすると、ブラウザは正規の your-company.co.jp にアクセスしますが、プラグインが URLパラメータを画面に反映する際にスクリプトを一緒に埋め込んでしまい、顧客のブラウザで攻撃者のコードが動きます。

顧客から見ると、アドレスバーは正規のドメイン、HTTPSの鍵マークも出ている。「公式サイトを開いている」という認識のまま、偽の入力フォームに個人情報を入力してしまう、というケースが起こりえます。

CSPが厳格に設定されていれば、ブラウザは「このスクリプトは許可リストにない」と判断して実行を拒否します。これがCSPの守備範囲です。

「設定している」だけでは不十分

CSPには、制作会社やベンダーが「設定しています」と答えても実質的に効いていない設定があります。技術的には unsafe-inline という許可項目を有効にしている場合で、これだとXSSのほとんどの攻撃パターンを止められません。

経営者が中身まで判断する必要はありませんが、ベンダーに確認するときに「unsafe-inline は使っていますか」と一言付け加えるだけで、設定の質が分かります。

経営者として確認すべきこと

  1. 自社サイトに動的機能（フォーム・ログイン・予約システム）があるか確認する。あればCSPの優先度は高、なければ他の対策（HTTPS化、サーバーのパッチ適用）の方が先です。

  2. scan（サイト診断）で自社サイトをチェックする。ドメインを入れるだけで、CSPの有無が分かります。WordPressを使っているかも判定されます。

  3. WordPressを使っているなら、プラグインの更新運用をベンダーに確認する。「プラグインのアップデートは誰が、いつやっていますか」を聞いてください。CSPと並行して、根本のバグを減らす運用が必要です。

締め

「多くのサイトがCSP未対応」というデータを見ると焦りますが、すべてのサイトに必須というわけではありません。情報発信だけのシンプルなサイトであれば、CSPより先にやるべきことが他にあります。

逆に、フォーム・ログイン・WordPressのいずれかを使っているなら、CSPは入れる価値が高い対策です。「設定する／しない」の判断材料として、自社サイトがどちらの分類かをまず確認してください。

技術的にもう一歩踏み込みたい方は、CSPを技術的に深掘りする記事もあります。サイト種別ごとの詳細マトリクス、XSSの仕組み、CSPで防げないケース（Magecart型）、SRI併用、unsafe-inline の罠などを整理しています。