Webアプリケーション攻撃

CSP（コンテンツセキュリティポリシー）こんてんつせきゅりてぃぽりしー

XSS対策HTTPヘッダーコンテンツセキュリティポリシーインラインスクリプトホワイトリストクロスサイトスクリプティング

CSPって何？

簡単に言うとこんな感じ！

Webサイトに「このスクリプトは自分のサーバーのものしか動かしてはダメ！」って命令できる仕組みだよ。悪意のあるコードを第三者に埋め込まれても、ブラウザ側で「許可リストにないから実行しない！」とブロックしてくれるんだ！

CSP（コンテンツセキュリティポリシー）とは

CSP（Content Security Policy） とは、Webサーバーがブラウザに対して「このページで読み込んでよいリソース（スクリプト・画像・スタイルシートなど）の出所はここだけ」と宣言するセキュリティ機能です。HTTPレスポンスヘッダーまたはHTMLの<meta>タグを使って設定します。

CSPの主な目的は XSS（クロスサイトスクリプティング）攻撃の被害を最小化 することです。XSSとは、攻撃者がWebページに悪意のあるJavaScriptを埋め込み、閲覧者の情報を盗んだりなりすましを行う攻撃手法です。CSPはあくまでXSSの「被害を抑える防衛策」であり、XSS脆弱性をなくすものではありませんが、脆弱性が悪用されたときのダメージを大幅に減らせます。

仮にCSPなしのサイトに攻撃者がスクリプトを埋め込んだ場合、ブラウザはそれを「正規のコード」として実行してしまいます。しかしCSPを設定しておけば、許可されていないオリジン（出どころ）からのスクリプト実行をブラウザ自身が拒否します。「ブラウザを門番にする」 イメージです。

CSPの仕組みと主なディレクティブ

CSPは ディレクティブ（指示文） の組み合わせで構成されます。各ディレクティブがリソースの種類ごとの読み込みルールを定義します。

ディレクティブ	制御対象	設定例
`script-src`	JavaScriptの読み込み元	`'self'` `https://cdn.example.com`
`style-src`	CSSの読み込み元	`'self'` `'unsafe-inline'`
`img-src`	画像の読み込み元	`'self'` `data:`
`connect-src`	Ajax/WebSocket接続先	`'self'` `https://api.example.com`
`font-src`	Webフォントの読み込み元	`https://fonts.gstatic.com`
`frame-src`	iframe埋め込み元	`'none'`
`default-src`	上記すべてのデフォルト値	`'self'`

よく使うキーワードの意味

キーワード	意味
`'self'`	同じオリジン（ドメイン）からのみ許可
`'none'`	すべて禁止
`'unsafe-inline'`	インラインスクリプト・スタイルを許可（非推奨）
`'unsafe-eval'`	`eval()`などの動的コード実行を許可（非推奨）
`'nonce-xxxxx'`	指定した使い捨てトークンを持つスクリプトのみ許可

HTTPヘッダーの書き方（例）

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://cdn.example.com;
  img-src 'self' data:;
  style-src 'self' 'unsafe-inline';
  frame-src 'none';

これは「スクリプトは自ドメインとcdn.example.comだけ、iframeは完全禁止」というポリシーです。

報告モード（Report-Only）

いきなり本番適用するとサイトが壊れるリスクがあるため、まず Content-Security-Policy-Report-Only ヘッダーを使うのが定石です。ブロックはせずに違反ログだけを収集でき、段階的に安全に導入できます。

Content-Security-Policy-Report-Only:
  default-src 'self';
  report-uri /csp-report-endpoint;

歴史と背景

2004年頃 — XSS攻撃が急増。HTMLエスケープ処理だけでは防ぎきれないケースが増加し、ブラウザレベルでの防御が必要とされ始める
2010年 — Mozillaが独自に X-Content-Security-Policy ヘッダーをFirefoxに実装（非標準）
2012年 — W3Cが CSP Level 1 を勧告。Content-Security-Policy ヘッダーが標準化され、Chrome・Safariも対応
2015年 — CSP Level 2 勧告。nonce（使い捨てトークン）やhashによる細かい制御が追加。インラインスクリプトを安全に扱う手段が整備される
2018年 — CSP Level 3 策定中（現在も進行中）。'strict-dynamic'など、より柔軟で安全なディレクティブが追加。現在の主流バージョン
現在 — 主要ブラウザはすべてCSP Level 2以上に対応。大手Webサービス（Google, GitHub, Twitterなど）での採用が標準的に

CSPとXSSの関係・防御の多層構造

CSP単体はXSS脆弱性を「なくす」ものではありません。多層防御（Defense in Depth） の一部として機能します。

CSPとWAFの違い

観点	CSP	WAF（Webアプリケーションファイアウォール）
動作場所	ブラウザ側で実行をブロック	サーバー手前で通信をブロック
主な対策対象	XSS（クライアントサイド）	SQLインジェクション・XSSなど多数
設定主体	開発者（コード・ヘッダー）	インフラ担当者（ネットワーク機器）
コスト	無料（設定工数のみ）	有料製品が多い
向き不向き	細かいスクリプト制御	広範な攻撃パターンの一括遮断

規格・仕様	内容
W3C CSP Level 1 (2012)	CSPの最初の公式仕様。基本ディレクティブを定義
W3C CSP Level 2 (2015)	nonce・hash・`child-src`などを追加
W3C CSP Level 3 (進行中)	`'strict-dynamic'`・`'unsafe-hashes'`などを追加
RFC 7762	CSPのMIMEタイプ登録に関する参考文書
OWASP XSS Prevention Cheat Sheet	CSPを含むXSS対策のベストプラクティス集