【入門編】Content-Security-Policy (CSP) のscript-srcディレクティブによる実行制御 – アプリケーションセキュリティ & 安全な開発防御ガイド

泥棒を家に入れない！「CSP」で守るWebサイトの防犯術

こんにちは！セキュリティの現場で日々、巧妙な攻撃者たちとチェスをしているエンジニアです。

今日は、Web開発の現場で「避けては通れないけれど、ちょっと難しそう」と思われがちなContent-Security-Policy（CSP）についてお話しします。

「インジェクション攻撃」なんて言葉を聞くと身構えてしまうかもしれませんが、実はこれ、「あなたの家の防犯」を考えるのと同じくらいシンプルなんです。一緒に、泥棒を寄せ付けない強固なWebサイトの作り方を学んでいきましょう！

—

1. そもそも「インジェクション攻撃」って何？

Webサイトにおけるインジェクション攻撃（特にXSS：クロスサイトスクリプティング）を、あなたの「自宅」に例えてみましょう。

正規の訪問者： あなたが信頼して招き入れた友人（正当なJavaScriptファイル）。
泥棒（攻撃者）： 窓の隙間から勝手に侵入して、家の中の物を盗んだり、勝手に模様替えをして他の訪問者を騙そうとする悪党。

攻撃者は、Webサイトの入力フォームなどに「悪意のあるスクリプト（命令）」を紛れ込ませます。これをWebサイトが「あ、これも正当な訪問者からのメッセージだな」と勘違いして実行してしまうのが、インジェクション攻撃の正体です。

2. 最強の防犯ゲート「CSP（Content-Security-Policy）」

ここで登場するのが、ブラウザに「誰を信じて、誰を追い出すか」を指示するCSP（コンテンツセキュリティポリシー）というヘッダーです。

これは、玄関に「身元保証がない人は絶対に入れない」「怪しい道具（evalなど）は持ち込ませない」という厳しいルールを貼り出すようなものです。

script-src ディレクティブで「実行許可」を絞る

CSPの中で最も重要なのが script-src です。これは「どの場所から来たスクリプトなら動かしていいか」を定義する設定です。

3. なぜ「インラインスクリプト」が危ないのか？

初心者のうちは、HTMLの中に直接と書いてしまう「インラインスクリプト」を多用しがちです。

しかし、これは「家の鍵を玄関マットの下に隠している」のと同じくらい危険です。泥棒は、家の外からでもその鍵を自由に使えてしまいます。

対策：インラインスクリプトを禁止する

CSPで安全な運用をするなら、インラインスクリプトを禁止するのが鉄則です。

インラインスクリプトやeval（危険な命令実行）を禁止する設定
Content-Security-Policy: script-src ‘self’; object-src ‘none’;

もし「どうしてもインラインで書きたい！」という場合は、「Nonce（ナンス）」という使い捨てのパスワードのような仕組みを使います。

このように設定すると、サーバーが発行した「使い捨てパスワード」を持っていないスクリプトは、たとえサイト内に紛れ込んでいても一切実行されなくなります。

—

4. 今日からできる一歩

セキュリティ対策は、一気にすべてを完璧にしようとすると疲れてしまいます。まずは以下のステップで進めてみてください。

1. 現状を知る： CSPを Content-Security-Policy-Report-Only ヘッダーで設定してみる。（これならブロックされず、違反ログだけをサーバーに送ってくれるので、既存のサイトを壊さずに安全を確認できます！）
2. 許可リストを絞る： 必要なドメインだけを script-src に追加する。
3. インラインを排除する： 少しずつ外部JSファイルに切り出していく。

セキュリティは「泥棒とのいたちごっこ」と言われますが、「守る側のルール（CSP）」をしっかり決めておくだけで、攻撃者のハードルは劇的に上がります。

「難しそう」と避けていた機能も、こうして「家の防犯」に置き換えると、やるべきことが見えてくるはずです。ぜひ、あなたのWebサイトの玄関に、最強の防犯ゲートを設置してあげてくださいね！

何か分からないことがあれば、またいつでも聞きに来てください。一緒に、より安全なWebの世界を作っていきましょう！