あなたのWebサイト、知らない誰かに「合鍵」を渡していませんか？〜CSPとstrict-dynamicで守るXSS対策〜
こんにちは！日々セキュリティの最前線で戦っているエンジニアの皆さん、そしてこれからWebの世界を守る一歩を踏み出す皆さん。
今日は、Webセキュリティの永遠のテーマ「XSS（クロスサイトスクリプティング）」と、それを根本から封じ込めるための魔法の盾「CSP（コンテンツ・セキュリティ・ポリシー）」についてお話しします。特に、最近のモダンな開発現場で欠かせない「strict-dynamic」というキーワードを、身近な例えで紐解いていきましょう。
—
1. XSSって、結局どんな「泥棒」なの？
XSSを一番わかりやすく例えると、「あなたの家のセキュリティをすり抜けて、勝手に合鍵を作ってしまう泥棒」です。
Webサイトにおいて、ブラウザは「このサイトから読み込まれたスクリプトなら、何をやってもいいよ」と信頼しています。もし攻撃者が、掲示板のコメント欄やURLパラメータに悪意あるコードを仕込み、あなたのサイトがそれを「信頼できるスクリプト」として実行してしまったら……。
攻撃者は、あなたのサイトの裏側で、ユーザーのCookieを盗んだり、勝手にパスワード変更画面を表示させたりと、やりたい放題です。これがXSSの恐ろしさです。
—
2. CSP：最強の「身元確認ゲート」
この泥棒を防ぐために登場するのがCSP（Content Security Policy）です。
これまで、多くのサイトでは「どのスクリプトを読み込めるか」を一つずつホワイトリスト形式で指定していました。でも、これがめちゃくちゃ大変なんです。「Google AnalyticsはOK、広告タグはOK、あ、その広告が読み込む別のタグは……？」とやっているうちに、リストが長すぎてメンテナンス不能になるのがオチです。
そこで登場したのが、'strict-dynamic' です。
「strict-dynamic」の魔法
strict-dynamicを一言でいうと、「信頼できる人が連れてきた友達なら、その人も信頼するよ」という仕組みです。
例えば、最初に読み込んだ「メインの信頼済みスクリプト（A）」が、動的に「別のスクリプト（B）」を呼び出したとします。strict-dynamicがあれば、「Aが読み込んだんだから、Bも安全だよね」とブラウザが自動的に判断して実行を許可してくれます。これにより、複雑なホワイトリスト地獄から解放されるわけです。
—
3. 実践！CSPの設定を書いてみよう
では、実際にどのようにHTTPヘッダーを設定すればいいのか見てみましょう。
Content-Security-Policy: script-src ‘nonce-rAnd0m123’ ‘strict-dynamic’; object-src ‘none’; base-uri ‘none’;
設定のポイント
'nonce-rAnd0m123': これが「信頼のパスポート」です。サーバー側でリクエストのたびに生成したランダムな文字列を、
コメント