こんにちは！Webアプリケーションの開発やインフラの管理、毎日お疲れ様です。新人のIT担当者さんや、「セキュリティってなんだか難しそう……」と少し不安を感じている開発者の方に向けて、今日から使える実践的な防犯テクニックをお話ししますね。
Webサイトを作るとき、「クロスサイトスクリプティング（XSS）」という言葉を耳にしたことはありませんか？ 悪意ある第三者があなたのサイトにこっそり危険なスクリプト（プログラム）を忍び込ませて、ユーザーのデータを盗み出してしまう恐ろしい攻撃です。
このXSSからWebサイトを守るための強力なボディガードが、今回ご紹介する Content-Security-Policy (CSP) です。なんだか呪文のような名前ですが、要するに「うちのサイトでは、こういうプログラムしか動かしません！」とブラウザに約束させるための防犯ヘッダーなんですよ。
それでは、身近な例えを交えながら、一歩ずつ分かりやすく紐解いていきましょう！
—
1. 家の鍵に例えるCSPの仕組み
想像してみてください。あなたが大切なお家（Webサイト）を建てたとします。
玄関の鍵をしっかり閉めていても、もし泥棒が「勝手口の窓ガラスを破って、勝手に作った偽物の合鍵をリビングで堂々と使う」としたらどうでしょう？
従来のXSS対策は、主に「怪しい人が入ってこないようにする（入力値のサニタイジングやエスケープ）」という玄関の鍵の強化でした。しかし、もし隙を突かれて悪意あるコード（scriptタグなど）が侵入してしまったら、ブラウザは「おっ、ここにスクリプトがあるな！実行しちゃえ！」と素直にそれを動かしてしまいます。これがリビングで合鍵を使われてしまう状態です。
そこで登場するのが CSP（Content-Security-Policy） です。
CSPは、家の中に警備員を配置するようなもの。「リビングで動いていいのは、我が家の家族（信頼できるスクリプト）だけだ！ 見知らぬ他人が持ち込んだプログラムは、たとえ部屋に入り込んでも絶対に動かしてはならない！」と、ブラウザという警備員に厳しく命令する仕組みなのです。
—
2. 最も安全な防衛網：nonce（ナンス）を使った厳格な設定
では、実際にどうやって「信頼できるプログラム」をブラウザに教えればいいのでしょうか。
一番確実な方法は、ページを読み込むたびに「使い捨ての合言葉（nonce）」を発行する方法です。
nonce（Number Once）とは、その名の通り「1回限りの数字や文字列」のことです。サーバー側でページを表示するたびにランダムな文字列を作り、HTMLのタグとCSPヘッダーの両方に同じ文字列をこっそり仕込みます。
ブラウザは、「CSPヘッダーに書いてある合言葉」と「スクリプトタグに書いてある合言葉」が一致したときだけ、そのプログラムの実行を許可します。もし攻撃者が勝手に scriptタグを書き込んでも、合言葉を知らないのでブラウザに即座にブロックされるというわけです。
実際のHTTPヘッダーとHTMLの書き方を見てみましょう。
PHPでのCSPヘッダー設定例
<?php
// ページを表示するたびに推測されにくいランダムな合言葉（nonce）を生成する
$nonce_value = base64_encode(random_bytes(16));
// ブラウザへ「この合言葉を持つスクリプト以外は実行するな！」と命令する
header("Content-Security-Policy: default-src 'self'; script-src 'nonce-" . $nonce_value . "';");
?>
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<title>CSPテストページ</title>
</head>
<body>
<h1>ようこそ！</h1>
<!-- サーバーが発行した「合言葉」と一致しているため、このスクリプトは実行される -->
<script nonce="<?php echo $nonce_value; ?>">
console.log("この安全なスクリプトは正常に実行されます。");
</script>
<!-- 攻撃者が勝手に埋め込んだと仮定する怪しいスクリプト（合言葉がないのでブロックされる！） -->
<script>
// alert("悪意ある攻撃！");
</script>
</body>
</html>このように、script-src 'nonce-...' を設定しておけば、万が一Webサイトに脆弱性があったとしても、攻撃者は勝手なスクリプトを実行できなくなります。これが現代のWeb開発における強力なベストプラクティスです。
—
3. ちょっと待って！実はまだ穴がある？（JSONP等によるバイパスリスク）
「よし、nonceを使えば完璧だね！」と思ったそこのあなた、素晴らしい着眼点です。しかし、私たち攻撃側（レッドチーム）は、こういった鉄壁のルールをもらすための「抜け道」を探すのが仕事です。
例えば、もしあなたのWebサイト（または同じドメイン内）に、外部からの入力をそのまま画面に出力してしまうような「JSONPエンドポイント」や、古いJavaScriptライブラリが放置されていたらどうなるでしょうか？
攻撃者は、わざわざ新しいスクリプトタグを挿入しなくても、次のような手口を使います。
1. サイト内にある「信頼されたドメイン内の特定のプログラム（例: api.example.com/jsonp?callback=...）」を呼び出す。
2. そのプログラムが、攻撃者の意図したJavaScriptコードを結果として返してしまう。
3. CSPの script-src では「このドメイン（example.com）からのスクリプト読み込みは許可する」と緩く設定してしまっているため、ブラウザは「おっ、信頼されたドメインからの読み込みだからOKだな！」と勘違いして実行してしまう。
これが、CSPバイパス（回避） と呼ばれる脅威です。
緩すぎる設定の危険な例
# 「example.comからのスクリプトなら何でも読み込んでいいよ」という緩い設定
Content-Security-Policy: script-src 'self' https://example.com;もし example.com のどこかに、ユーザーの入力をそのままJavaScriptとして吐き出してしまう脆弱なファイルがあると、このCSPは簡単に突破されてしまいます。防犯カメラは置いてあるけれど、裏口の鍵が空いているような状態ですね。
—
4. 現場で役立つ安全な設定の鉄則
では、こうしたバイパスリスクを防ぎ、より堅牢なシステムを作るためにはどうすればよいのでしょうか。実務の現場で意識すべきポイントを整理しておきましょう。
1. unsafe-inline や unsafe-eval は絶対に避ける
HTMLの中に直接書くインラインスクリプト（<script>alert(1)</script>）や、文字列をプログラムに変換してしまう eval() 関数を許可する設定は、セキュリティの扉を自ら全開にするようなものです。これらは絶対に使わないようにしましょう。
2. 外部ドメインの信頼範囲を極限まで狭める
script-src で外部のCDNやAPIドメインを指定する際は、ワイルドカード（*）を使ったり、信頼できないドメインを安易に含めたりしないこと。「どうしても必要な特定のスクリプトファイルのみ」に絞り込み、可能な限り nonce やハッシュ（sha256-...）ベースの設定へ移行しましょう。
3. レポート機能（report-uri / report-to）を活用する
いきなり厳格なCSPを本番環境に適用すると、既存の正当な機能（アナリティクスツールや便利なウィジェットなど）まで動かなくなって焦ることがあります。まずは違反があったときにブロックせず「報告だけを飛ばすモード（Content-Security-Policy-Report-Only）」を活用し、エラーログを監視しながら徐々にルールを締めていくのがプロの現場の流儀です。
—
おわりに
セキュリティの対策は、一度やったら終わりではなく、日々のメンテナンスと「攻撃者だったらどうやってこの網をすり抜けるだろう？」という視点を持つことがとても大切です。
難しく感じるかもしれませんが、今日学んだ nonce の概念や、緩い設定の危険性を頭の片隅に置いておくだけで、あなたの書くコードの安全性は劇的に向上します。一歩ずつ、確実に安全なWebの世界を作っていきましょう！
コメント