【入門編】 Content-Security-Policy (CSP) によるクロスサイトスクリプティング(XSS)の緩和 – ガバナンス・リスク管理 & 生成AIセキュリティ防御ガイド

こんにちは。セキュリティの現場の最前線で「いかに泥棒の侵入を防ぎ、かつ家の中の快適さを守るか」を考え続けているエンジニアです。

今日は、Webサイトを守るための強力な盾、「Content Security Policy（CSP）」についてお話しします。難しそうな名前に聞こえるかもしれませんが、実は「家の防犯」と同じくらいシンプルな仕組みなんですよ。一緒に紐解いていきましょう。

—

1. Webサイトの「泥棒」は、どうやって侵入してくるの？

まず、なぜCSPが必要なのかを理解するために、Webサイトにおける「泥棒」の正体、つまりXSS（クロスサイトスクリプティング）について考えてみましょう。

想像してください。あなたが大切にしているお家に、見知らぬ誰かが「宅配便です」と嘘をついて、勝手に偽の鍵を置いていったり、壁に落書きをしたりする様子を。
WebサイトにおけるXSSは、まさにこれと同じです。悪意のある第三者が、あなたのサイトの入力フォームや掲示板などに「悪意のあるスクリプト」をこっそり書き込みます。

そのページを訪れた無実のユーザーのブラウザは、その「偽の命令書（スクリプト）」を信じ込んでしまい、ユーザーのCookieを盗んだり、別の偽サイトへ誘導したりしてしまうのです。

2. CSPは「信頼できる人のリスト」

では、この被害を防ぐにはどうすればいいでしょうか？「誰が書いたか分からない命令書は、そもそも受け取らない」というルールを決めればいいですよね。これがCSP（Content Security Policy）の役割です。

CSPは、Webサーバーからブラウザに向けて「このサイトでは、この場所から届いたプログラムしか実行しちゃダメだよ！」と伝えるための「通行手形」のようなものなんです。

CSPの仕組みを例えると…

script-src: 「このサイトで動かしていいプログラムは、うちの庭（自分のドメイン）か、信頼できる特定の倉庫（CDNなど）から来たものだけだよ！」と制限をかけるルールです。
object-src: 「Flashのような古いプラグインは一切禁止！」と、古い泥棒の侵入経路を塞ぐルールです。

これらをヘッダーに設定するだけで、ブラウザは「怪しい命令書」を受け取った瞬間に、「あ、これは許可リストに入ってないな。無視しよう！」と自動的に遮断してくれるようになります。

—

3. 実践！CSPを設定してみよう

では、実際にどのように設定するのか、コードを見てみましょう。サーバーの設定ファイル（ApacheやNginxなど）や、アプリケーションのレスポンスヘッダーに以下のような記述を追加します。

# CSPヘッダーの例
Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com; object-src 'none';

この設定が意味するのは以下の通りです。

default-src 'self': 基本的に、すべて自分のサイト内のものだけを許可する。
script-src 'self' https://trusted-cdn.com: スクリプトは「自分のサイト」と「信頼できるcdn.com」からのみ読み込みを許可する。
object-src 'none': プラグインの実行は一切許可しない（セキュリティ上、これが最も安全です）。

開発者がやってしまいがちな「やってはいけないこと」

よくある間違いとして、'unsafe-inline' という設定を使ってしまうケースがあります。これは「HTMLの中に直接書かれた <script>alert('ハック！')</script> のようなコードを許可する」という設定です。
これをしてしまうと、せっかくの盾が穴だらけになってしまいます。可能な限り、プログラムは外部ファイルに切り出し、この設定を避けるのがプロの流儀です。

—

4. 導入の際の注意点：いきなり厳しくしすぎない

最初から完璧なルールを作ろうとすると、サイトが動かなくなって焦ることもあります。そんな時は Content-Security-Policy-Report-Only というヘッダーを使いましょう。

これは「もしルールを適用したら何がブロックされるか」をテストするためのモードです。

# テストモードで運用する例
Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; report-uri /csp-violation-report

これを使えば、実際にブロックは行わずに、ブラウザが「あ、このスクリプトは許可されてないですよ」というレポートをあなたのサーバーに送信してくれます。これを確認しながら、徐々にルールを厳しくしていくのが、現場での賢い進め方です。

—

最後に：セキュリティは「継続的なメンテナンス」

いかがでしたか？ CSPは一度設定して終わりではなく、新しい機能を追加したり外部サービスと連携したりするたびに、「このルールでまだ大丈夫かな？」と見直す必要があります。

家の鍵を定期的にチェックするように、Webサイトの防犯ルールも日頃から見守ってあげてくださいね。一歩ずつ、確実に知識を積み上げていけば、あなたのサイトはもっと強固で、ユーザーに愛される場所になるはずです。

もし「設定したらログイン機能が動かなくなった！」なんてトラブルがあったら、それはログを読み解くチャンスです。泥臭い調査の先にこそ、本当のセキュリティの実力がついてくるものです。応援していますよ！