こんにちは。セキュリティの世界へようこそ。
現場の最前線でインシデント対応をしていると、「完璧な防御なんて存在しない」という現実に突き当たります。でも、だからといって諦める必要はありません。大切なのは「泥棒が嫌がる家」にすることです。
今日は、Web開発の現場で頭を悩ませる「インジェクション攻撃」を防ぐための切り札、CSP（Content Security Policy）の『strict-dynamic』という少しテクニカルだけど非常に強力な武器について、身近な例えを交えて紐解いていきましょう。
—
1. なぜ「インジェクション攻撃」は怖いのか？
まず、インジェクション攻撃を「家の鍵」に例えてみましょう。
本来、あなたの家の鍵は「あなた（開発者）だけが持っているもの」ですよね。ところが、悪意ある攻撃者は、鍵を盗むのではなく、「鍵穴そのものを偽造して、泥棒を招き入れる」ような真似をします。
Webサイトにおいて、これが「クロスサイトスクリプティング（XSS）」です。ユーザーが入力した情報をそのまま画面に表示してしまうと、攻撃者が仕込んだ「悪意あるスクリプト（泥棒）」が、あたかもあなたのサイトの一部であるかのようにブラウザで実行されてしまいます。これによって、ユーザーのCookieが盗まれたり、勝手に操作されたりするわけです。
2. CSP：ブラウザに「誰を信用するか」を教える防犯カメラ
これを防ぐために登場するのがCSP（Content Security Policy）です。これはWebサーバーからブラウザに向けて送る「ルールブック」のようなもの。「このサイトでは、このドメインのスクリプトしか動かしちゃダメだよ！」と、ブラウザに指示を出す防犯カメラ兼ガードマンですね。
しかし、現代のWeb開発は複雑です。メインのスクリプトが読み込まれ、それがさらに別の便利なスクリプトを動的に呼び出す……といった「親子関係」がたくさんあります。ガチガチに制限しすぎるとサイトが動かなくなり、緩くしすぎると泥棒が入り放題。このバランスを取るのが本当に難しいんです。
3. 「strict-dynamic」が解決する、現代のジレンマ
そこで登場するのが、CSP Level 3で導入されたstrict-dynamicです。
これまでのCSPでは、動的に生成されるスクリプトを許可するために「あれもこれも許可リストに追加」する必要があり、運用が破綻しがちでした。これを例えるなら、「一度信頼した親分（メインスクリプト）が連れてきた子分（動的スクリプト）なら、中に入れてもいいよ」というルールを追加するイメージです。
これにより、複雑なフロントエンド構成でもセキュリティを維持しつつ、柔軟な開発が可能になります。
—
4. 実践：strict-dynamicの設定例
実際にサーバーから返すHTTPレスポンスヘッダーの設定を見てみましょう。
CSPヘッダーのサンプル
Content-Security-Policy: script-src ‘nonce-random123’ ‘strict-dynamic’; object-src ‘none’; base-uri ‘none’;
この設定が何をしているのか、噛み砕いて説明しますね。
'nonce-random123':
「このページを読み込むたびに変わるランダムな合言葉（nonce）」を知っているスクリプトだけ実行を許可します。これは、攻撃者が外部から適当なスクリプトを注入しても、この合言葉を知らないので実行できないことを意味します。
'strict-dynamic':
「nonceを持つ親スクリプトが、その後に読み込むスクリプトは信頼して実行していいよ」という強力な許可証です。これで、現代的なモジュール形式のJavaScriptも安全に動かせます。
object-src 'none':
古いプラグイン（Flashなど）の実行を禁止します。もはや不要なものは物理的に閉め出すのが鉄則です。
base-uri 'none':
悪意あるサイトへリンク先をすり替える攻撃を防ぎます。
—
5. 導入にあたっての「泥臭い」アドバイス
ここまで読んで「よし、今日から導入しよう！」と思ったあなた、少し待ってください。いきなりstrict-dynamicを適用すると、既存のスクリプトが動かなくなってユーザーからクレームが来るかもしれません。
まずは「報告モード（Report-Only）」から始めましょう。
実際の適用前に、違反がないかテストするモード
Content-Security-Policy-Report-Only: script-src ‘nonce-random123’ ‘strict-dynamic’; …
このヘッダーを使うと、ブラウザはブロックせずに「もしこのルールを適用したら、このスクリプトが動かなくなりますよ」というレポートをサーバーに送ってくれます。数日間このログを眺めて、「本当に必要なスクリプトだけが動いているか」を確認してから、本番適用（Content-Security-Policy）に切り替える。これが現場で最も失敗の少ない、泥臭くも賢いやり方です。
—
まとめ：セキュリティは「完璧」を目指さない
セキュリティの教訓として、「完璧な防御」を追い求めると開発効率が死にます。strict-dynamicのような技術をうまく使うことで、「堅牢性と柔軟性の両立」を目指すのが、私たちエンジニアの腕の見せ所です。
まずは自分のサイトのヘッダーを確認するところから始めてみませんか？一歩ずつ、確実に。あなたのWebサイトという家を、今日よりも少しだけ安全にしていきましょう！
コメント