CSP（Content Security Policy）は、ブラウザに「どのJavaScriptや外部リソースの読み込みを許可するか」を指示する仕組みで、HTTPヘッダーとして動作します。

Webの脆弱性、とくにXSS（クロスサイトスクリプティング）は入力対策だけで完全に封じるのが難しく、万一スクリプトが混入しても実行させないことで被害を抑えられるのがCSPの強みです。

本記事では、CSPの基本と登場背景、公式仕様としての位置づけを整理しつつ、XSS対策で必要な理由、サーバー側対策との役割分担、そしてCSPでできること・できないこと（過信が危険な点）まで分かりやすく解説します。

CSPの理解を深めたい方は是非最後までご覧になってください。

CSP（Content Security Policy）とは何か

CSPは、ブラウザに「どのリソース（JavaScript,CSS,Imgなど）の実行を許可するか」をヘッダーで伝える仕組みで、サイト側の設定によって制御します。

書き方や設定方法を誤ると想定どおりに制限できず、「動かない」状態になったり、unsafe-inline を許してしまい回避されやすくなることもあるので、仕組みを理解して設定する必要があります。

Content Security Policyの基本的な仕組み

CSPの仕組み

図のように、CSPはWebサーバがレスポンスヘッダーで「読み込むリソースのルール」をブラウザに伝え、ブラウザ側がそのルールをもとに実行可否を判断する仕組みです。

ページ内でJavaScriptの実行や外部リソースの読み込みが発生するたびに、ブラウザはCSPの許可リストを確認します。

許可されていれば表示や実行が行われ、許可されていなければブラウザが自動的にブロックします。サーバは実行を制御せず、判断と防御を担うのはあくまでブラウザです。

CSPが登場した背景とWebの脆弱性

Webでは長年、入力欄などに仕込まれた悪意あるJavaScriptが実行されるクロスサイトスクリプティング（XSS）の脆弱性が問題となってきました。

従来はエスケープ処理などで回避していましたが、実装漏れや書き方の違いにより完全な対策は困難でした。そこで登場したのがCSPです。CSPはヘッダーで実行元を制限する設定を行い、ブラウザ側で不正なスクリプトを止めます。

なぜCSPがXSS対策に欠かせないのか

XSSは、Webアプリケーションの脆弱性を突いて不正なJavaScriptを実行させる攻撃ですが、入力チェックやエスケープなどの従来対策だけでは、実装漏れや想定外の経路から完全に防ぐことが難しいのが現実です。そこで重要になるのが、実行そのものを制御するCSPという仕組みです。

本章では、なぜXSS対策にCSPが欠かせないのかを理解していきましょう。

参考記事：クロスサイトスクリプティング（XSS）を図解で理解！攻撃事例と対策を徹底解説

XSSはなぜ完全に防ぐことが難しいのか

XSSが完全に防ぎきれない理由は、攻撃経路が一つではなく、すべての入力と出力を常に正しく扱うことが非常に難しいためです。

Webアプリケーションでは、フォーム入力だけでなく、URLパラメータや外部サービスから取得したデータなど、JavaScriptが関与する箇所が多岐にわたります。エスケープ処理や入力検証を行っていても、書き忘れや仕様変更による抜け漏れが生じやすく、結果として脆弱性が残ってしまいます。

このように、人の実装に依存する対策だけでは限界がある点が、XSS対策を難しくしている要因です。

CSPがXSS被害を抑止できる理由

CSPがXSS被害を抑止できる理由は、攻撃コードがページ内に入り込んだとしても、ブラウザがその実行を許可しない仕組みを持っている点にあります。

CSPでは、サーバーがあらかじめ許可したJavaScriptの実行元や読み込み先だけをブラウザに伝え、それ以外のスクリプトは自動的にブロックされます。

そのため、入力値に悪意あるコードが混入しても、実行されず被害に発展しにくくなります。アプリケーションの実装ミスを前提にして被害を抑える点が、CSPの大きな特徴です。

サーバー側対策とCSPの役割分担

観点	サーバー側対策	CSP
主な役割	不正な入力や出力を防ぐ	不正なスクリプトの実行を防ぐ
対策のタイミング	データを保存・表示する前	ブラウザで表示・実行する直前
主体	Webアプリケーション	ブラウザ
対策方法の例	入力検証、エスケープ処理、テンプレート利用	レスポンスヘッダーで実行元を制限
実装漏れの影響	漏れた箇所がそのまま脆弱性になる	漏れがあっても実行を抑止できる
防げる範囲	想定した入力・出力経路	ページ全体のスクリプト実行
位置づけ	まず行う基本対策	被害を抑える追加防御

サーバー側の対策とCSPの役割の違いをまとめました。

CSPは追加防御的な役割であり、「CSPを実装することで、よりセキュリティが強まる」という理解になります。

CSPでできること・できないこと

実行できるJavaScriptを制御できる

CSPでは、どのJavaScriptを実行してよいかをブラウザ側で制御できます。

たとえば、レスポンスヘッダーで次のように設定すると、自サイトから配信されたJavaScriptのみが実行対象になります。

Content-Security-Policy: script-src 'self';

この状態で、下記のような外部サイトのJavaScriptやインラインで書かれたスクリプトが存在すると、ブラウザは実行しません。

<!-- 実行されない例 -->
<script>
  alert('inline script');
</script>

<script src="https://attacker.example/xss.js"></script>

一方で、下記のような許可された場所に配置されたJavaScriptは通常どおり動作します。

<!-- 実行される例 -->
<script src="/app.js"></script>

このようにCSPは、ページ内にスクリプトが混入しても、許可していないJavaScriptの実行自体を防ぐことで被害を抑止します。

外部リソース読み込み制限の仕組み

CSPでは、JavaScriptだけでなく、画像やCSS、フォント、iframeなどの外部リソースの読み込み元も制御できます。

たとえば次のように設定すると、画像は自サイトと特定のドメインからのみ読み込み可能になります。

Content-Security-Policy: img-src 'self' https://images.example;

この場合、許可されていない下記のような外部サイトの画像はブラウザによってブロックされます。

<!-- 表示されない例 -->
<img src="https://attacker.example/evil.png">

一方、下記のような許可されたドメインからの読み込みは問題なく行われます。

<!-- 表示される例 -->
<img src="/logo.png">
<img src="https://images.example/banner.png">

この仕組みにより、攻撃者が外部の不正なリソースを読み込ませようとしても、ブラウザが自動的に遮断し、情報漏えいや不正な動作につながるリスクを抑えることができます。

参考記事：Content Security Policy（CSP）設定値を完全解説：主要ディレクティブ早見表

CSPでは防げない脆弱性の例

CSPは強力な防御手段ですが、すべての脆弱性を防げるわけではありません。

たとえば、認証や権限管理の不備による不正ログイン、SQLインジェクションのようなサーバー側で完結する攻撃は、CSPでは防止できません。

また、許可されたJavaScriptの中にロジック上の欠陥がある場合、その処理自体はCSPに違反しないため実行されてしまいます。さらに、設定ミスにより広い範囲を許可していると、本来想定していない挙動を防げないこともあります。

CSPは実行制御に特化した仕組みであり、他のセキュリティ対策と併用することが前提となります。

まとめ

CSP（Content Security Policy）は、従来の入力チェックやエスケープ処理だけでは実装漏れや想定外の経路による脆弱性を完全に防ぐことは困難だったクロスサイトスクリプティング（XSS)の被害を抑える追加防御として非常に有効です。

万一スクリプトが混入しても「実行させない」ことで被害を最小限に抑えますが、その一方でCSPは万能ではありません。

サーバー側対策と役割分担しながら使うことが重要です。CSPの特性と注意点を正しく理解することが、実践的なXSS対策につながります。

CSP（Content Security Policy）とは？XSS対策に欠かせない理由と注意点

目次