【入門編】Content-Security-Policy (CSP) によるXSSの緩和策 – アプリケーションセキュリティ & 安全な開発防御ガイド

玄関の鍵をかけたはずが、泥棒は「窓」から入ってくる?Web開発の盲点とCSPの正体

こんにちは!セキュリティの世界へようこそ。

「ファイアウォールを入れたし、パスワードも複雑にした。これでうちは鉄壁だ!」……そう思っていませんか?実は、どれだけ頑丈な玄関の鍵を用意しても、「家の中に招き入れたはずの訪問者」が実は泥棒だったとしたら、その防御は意味をなしません。

Web開発の世界で言う「訪問者」とは、ユーザーが入力したデータや、外部から読み込むスクリプトのこと。今日は、あなたのWebサイトという「家」を守るための、最強の用心棒「CSP(Content Security Policy)」について、優しく紐解いていきましょう。

—

1. XSS(クロスサイトスクリプティング)という「見えない泥棒」

まずは、一番の宿敵「XSS(クロスサイトスクリプティング)」の話から始めましょう。

想像してみてください。あなたのWebサイトには、ユーザーが自由にコメントを書き込める掲示板があります。もし、悪意ある攻撃者がそのコメント欄に、「このページを見た人のログイン情報を盗み出すプログラム」を書き込んだらどうなるでしょう?

普通、ブラウザは「Webサイトが読み込んできたものは全部信頼できる仲間だ!」と判断して、その怪しいプログラムを一生懸命実行してしまいます。これがXSSのメカニズムです。鍵をかけていても、家の中の住人が勝手に泥棒を招き入れているようなものですね。

—

2. CSP(Content Security Policy)で「立ち入り禁止区域」を作る

そこで登場するのがCSP(Content Security Policy)という仕組みです。これは、Webサイトの管理者がブラウザに対して「このサイトでは、これ以外のスクリプトは絶対に実行しちゃダメ!」という厳格なルールブックを渡す防犯システムです。

HTTPレスポンスヘッダーに特定の文字列を仕込むだけで、ブラウザの挙動をコントロールできるんです。

基本の形を見てみよう

一番シンプルで、かつ強力な設定はこれです。

Content-Security-Policy: default-src ‘self’;

これは、「自分のドメイン(’self’)から読み込まれるもの以外は一切信用しない」という宣言です。これだけで、外部の怪しいサーバーから送られてくるスクリプトは軒並みブロックされます。

—

3. インラインスクリプトを「追い出す」のが鉄則

XSSで最も厄介なのは、HTMLの中に直接書き込まれたスクリプト(インラインスクリプト)です。


これらは「どこから来たか」の判別が難しいため、セキュリティ的には「即刻禁止」が正解です。CSPでインラインスクリプトを完全に禁止するには、以下のように設定します。

Content-Security-Policy: script-src ‘self’; object-src ‘none’;

  • script-src 'self': 自分のサーバーにあるJavaScriptファイルだけを許可。
  • object-src 'none': Flashなどの古いプラグインを一切禁止(これらは攻撃の温床になりやすいため)。

※ もしどうしてもインラインスクリプトが必要な場合は、nonce(ナンス:使い捨ての秘密鍵)という仕組みを使います。サーバー側で毎回ランダムな文字列を発行し、許可されたスクリプトタグにだけその文字列を埋め込む手法です。これなら、攻撃者が勝手に挿入したスクリプトは「鍵がない」ので実行されません。

—

4. 実戦!安全な設定のサンプル

新人のエンジニアさんがまず目指すべき、バランスの良い設定サンプルがこちらです。

サーバーの設定ファイル(ApacheやNginxなど)で設定します
Content-Security-Policy: default-src ‘self’; script-src ‘self’ https://trusted.cdn.com; object-src ‘none’; style-src ‘self’ https://fonts.googleapis.com;

この設定の意味:

  • default-src 'self': 基本は自分のサイト内のみ。
  • script-src 'self' https://trusted.cdn.com: 自分のサーバーと、信頼しているCDN(例:ライブラリ配信元など)のスクリプトだけOK。
  • object-src 'none': 外部プラグインは門前払い。
  • style-src 'self' ...: デザイン用のCSSも、信頼できる場所からしか読み込まない。

—

最後に:セキュリティは「完璧」より「継続」

いかがでしたか?CSPは、一度設定して終わりではありません。新しい機能を追加するたびに「このスクリプトは本当に必要か?」と立ち止まって考えることが大切です。

最初は少し窮屈に感じるかもしれませんが、これこそが、あなたのサイトを守り、ユーザーの信頼を守るための「一番の近道」なんです。

まずは自分のサイトのヘッダーを確認するところから、一歩ずつ対策を始めてみましょう。何か分からないことがあれば、いつでも相談してくださいね。一緒に安全なWebの世界を作っていきましょう!

コメント

タイトルとURLをコピーしました