CSPは「導入して終わり」ではない：Report-Onlyモードで防御の「誤爆」をゼロにする戦略
現場でセキュリティ設計の話をすると、決まって「CSP（Content Security Policy）を入れたらサイトの機能が壊れた」という悲鳴が聞こえてくる。無理もない。複雑なフロントエンドフレームワークやサードパーティのタグマネージャーが乱立する現代のWebにおいて、いきなり厳格なCSPを適用するのは、高速道路を走りながらタイヤを交換するようなものだ。
だが、諦めてはいけない。「Report-Onlyモード」こそが、運用を止めずに堅牢なセキュリティを手に入れる唯一の正攻法だ。 今日は、インジェクション攻撃を根本から封じ込めるための、泥臭くも確実なCSP導入術を伝授する。
—
1. なぜインジェクション攻撃にCSPが効くのか
SQLインジェクションやOSコマンドインジェクションの先にある「クロスサイトスクリプティング（XSS）」は、攻撃者にブラウザの制御権を明け渡す致命的な攻撃だ。攻撃者は悪意あるJSを注入し、セッションを盗む。
CSPの真骨頂は、「どこのスクリプトを信頼するか」をブラウザに強制する点にある。たとえ脆弱性が残っていても、攻撃者が仕込んだインラインスクリプトや外部ドメインからの怪しいコードをブラウザ側で「実行拒否」させることで、被害を未然に防ぐのだ。
—
2. 実践：Report-Onlyモードで「観測」から始める
いきなり Content-Security-Policy ヘッダーを有効にしてはいけない。まずは Content-Security-Policy-Report-Only を使い、既存の通信をすべて「観測」するモードから入るのが鉄則だ。
Nginxでの設定例
まずは、運用中のサイトに以下のヘッダーを追加してみよう。
Nginx設定ファイルに追加
report-uriには、レポートを受け取るエンドポイントを指定する
add_header Content-Security-Policy-Report-Only “default-src ‘self’; script-src ‘self’ https://trusted.cdn.com; report-uri /csp-report-endpoint;”;
この設定では、ポリシーに違反してもブラウザはブロックしない。その代わり、「もしこのポリシーが有効だったら、この通信はブロックされていた」という通知をサーバーに飛ばしてくれる。
—
3. レポート収集用のエンドポイントを作成する（PHP実装例）
ブラウザから送られてくるJSON形式のレポートを、ログとして保存するバックエンドが必要だ。これが「どこが壊れているか」を教えてくれる地図になる。
4. 盲点を突く：インラインスクリプトの罠
多くのエンジニアが躓くのが「インラインスクリプト（ 等）」の排除だ。これらはXSSの温床になるため、CSPでは本来禁止すべきもの。
もしレガシーなコードでインラインスクリプトが避けられないなら、「Nonce（ナンス）」を使え。リクエストごとに一意のランダム値を生成し、それをスクリプトタグに付与する手法だ。
セキュアな実装（PHP + CSP）
—
5. 現場のセキュリティ担当者へのアドバイス
最後に一つ、忘れないでほしい。CSPは「転んだときの膝当て」に過ぎない。インジェクションを防ぐ根本は、入力値のサニタイズとプレースホルダーを用いたクエリ構築にある。
1. Report-Onlyモードでログを徹底的に分析する。
2. サードパーティの信頼性を精査し、必要なものだけをポリシーに加える。
3. インラインスクリプトをNonceで厳格に管理する。
セキュリティに「魔法の銀の弾丸」は存在しない。だが、このように階段を一段ずつ登るような運用を続ければ、攻撃者がどれだけ技術を磨こうとも、あなたのシステムだけは決して牙を剥かせない堅牢な城になるはずだ。
さあ、まずは今日のデプロイに Report-Only ヘッダーを仕込むところから始めよう。何かが「ブロックされそうになっている」ことが可視化された瞬間、君のエンジニアとしての視座は一段階上がるはずだ。
コメント