「CSPさえあればXSSは防げる」と過信していないか？――object-srcとbase-uriが防ぐ“見えない地雷”
現場でコードをレビューしていると、CSP（Content Security Policy）を「とりあえず設定しておけば安心」というお守りのように考えているエンジニアによく出会う。だが、セキュリティの世界で「とりあえず」ほど危険な言葉はない。
XSS（クロスサイトスクリプティング）と言えば、alert(1)を出すだけのスクリプト注入を想像するかもしれないが、実戦で狙われるのは「ブラウザの解釈をねじ曲げる」攻撃だ。特に、プラグインの悪用や、リンク先の完全な乗っ取りは、ログにも残りづらく、気づいた時にはユーザーのセッションがすべて抜かれているという最悪のシナリオを招く。
今日は、多くのエンジニアが設定を怠りがちなobject-srcとbase-uriに焦点を当て、なぜこれが「死活問題」なのかを深掘りする。
—
1. なぜobject-srcとbase-uriが重要なのか
object-src: レガシーな悪夢の再来を防ぐ
かつて猛威を振るったFlashやJavaアプレット。これらは現在では廃止されているが、ブラウザは依然としてやタグを通じて外部コンテンツを読み込むことができる。
攻撃者は、もしあなたのアプリにわずかなインジェクションの隙があれば、悪意あるプラグインを読み込ませる。これが実行されると、JavaScriptのサンドボックスを突き抜けて、OSレベルの操作やブラウザのメモリ領域へのアクセスが可能になる。object-src 'none' は、この「死んだはずの機能」を物理的に遮断するための防波堤だ。
base-uri: リンクの行き先を書き換える「ステルス改ざん」
これが意外と盲点だ。
もし攻撃者がという記述は、攻撃者のサーバにある悪意あるapp.jsを読み込みに行くことになる。これだけで、XSSフィルタをバイパスし、サイトの挙動を完全に制御下に置くことが可能だ。
—
2. 【コピペ用】堅牢なCSP設定の実装
Webサーバやフレームワークで、以下のCSPヘッダーを付与してほしい。これが現代のWeb開発における「最低限の正解」だ。
Nginxでの設定例 (nginx.conf)
最も確実なのは、アプリケーション層ではなくWebサーバ層で強制することだ。
CSPの定義
object-src ‘none’: プラグインの実行を一切禁止
base-uri ‘self’: ベースURLの改ざんを禁止し、自ドメインのみに限定
script-src ‘self’: 外部ドメインからのスクリプト読み込みを排除（インラインスクリプトも原則禁止）
add_header Content-Security-Policy “default-src ‘self’; object-src ‘none’; base-uri ‘self’; script-src ‘self’; style-src ‘self’ https://fonts.googleapis.com; img-src ‘self’ data:;”;
PHP（Laravel等）での実装例
PHPでヘッダーを動的に制御する場合の例だ。
セキュアなページへようこそ
“;
—
3. 現場で役立つ検証のTips
CSPを設定しただけで「完了」とするのはまだ早い。開発環境で以下の手順を踏んでほしい。
1. ブラウザのコンソールを見る: 開発者ツールを開き、設定したCSPが意図せずJSやCSSをブロックしていないか確認する。CSPは「厳しすぎて動かない」がデフォルトだ。
2. レポート送信先を設定する: report-uri または report-to を追加して、ブロックされた試行を自分の監視サーバに飛ばせ。
add_header Content-Security-Policy “…; report-uri /csp-violation-report-endpoint;”;
これにより、「誰が、どの脆弱性を突こうとしているか」という攻撃者の動向をリアルタイムで把握できる。
—
セキュリティチーフからの「一言」
セキュリティとは、完璧な製品を作ることではない。「攻撃者に、コストが見合わないと思わせること」だ。
object-src 'none' を設定しただけで、攻撃者が準備した何日ものエクスプロイト開発が無駄になる。base-uri 'self' を設定しただけで、巧妙に隠されたURL改ざん攻撃が無効化される。
こうした小さな設定の積み重ねが、インシデント発生時に「被害を最小限に食い止めた」という結果につながる。教科書をただ読むのではなく、自分の書いているコードが「ブラウザにどう解釈されるか」を常に想像してほしい。
もし、レガシーな理由でどうしてもプラグインが必要だという場所があれば、それは「セキュリティの穴」そのものだ。リファクタリングの優先順位を上げ、一刻も早く現代的な技術へ移行することをお勧めする。健闘を祈る。
コメント