【テクニカル・上級編】CSPのobject-srcとbase-uriによるプラグイン・ハイジャック防御 – アプリケーションセキュリティ & 安全な開発防御ガイド

2026.08.29

境界なきWebの牙城を崩す：CSPのobject-srcとbase-uriが防ぐ「静かなるハイジャック」

Webアプリケーションの防御において、我々が直面する脅威はもはや単純なSQLインジェクションだけではない。フロントエンドの複雑化とブラウザの機能拡張に伴い、攻撃者はブラウザという「クライアント側の実行環境」そのものをハックする術を洗練させている。

特に、プラグインの悪用とベースURLの改竄は、一見するとレガシーな攻撃手法のように思えるかもしれない。しかし、これらは今なお、モダンなSPA（Single Page Application）において、クロスサイトスクリプト（XSS）のペイロードを致命的なRCE（リモートコード実行）へと昇華させるための強力なトリガーとして機能している。

今回は、コンテンツセキュリティポリシー（CSP）の深淵、特にobject-srcとbase-uriがいかにしてブラウザの根幹を保護しているのか、その技術的背景と実装戦略を紐解いていく。

—

1. object-src: プラグインという「ブラックボックス」を封じ込める

かつてのWebを席巻したFlashやSilverlightといったブラウザプラグインは、ブラウザのサンドボックスを容易に突破し、OSレベルのメモリ空間へ直接アクセスを試みるゲートウェイだった。現在ではHTML5の隆盛によりその存在感は薄れたが、攻撃者は依然としてやタグを利用し、レガシーなブラウザ挙動や、特定のMIMEタイプに対するブラウザの解釈の脆弱性を突こうとする。

なぜobject-src 'none'が不可欠なのか

攻撃者がを注入できた場合、それは単なるJavaScriptの実行に留まらない。プラグインのレンダリングエンジン自体の脆弱性（バッファオーバーフローなど）を誘発し、ブラウザのメモリ保護機構をバイパスする足がかりとなる。

我々が取るべき戦略はシンプルだ。「プラグインの実行を物理的に拒絶する」ことである。

CSPヘッダーの推奨設定
Content-Security-Policy: default-src ‘self’; object-src ‘none’;

この'none'設定は、ブラウザに対し「いかなるプラグインの読み込みも許可しない」という強制的なガードレイルを敷く。もし、どうしても古いPDFビューアや特定のActiveXが必要なエンタープライズ環境であったとしても、それらを個別にホワイトリスト化するのではなく、コンテナ化や別ドメインへの切り出しを検討すべきだ。プラグインを許容することは、現代のセキュリティアーキテクチャにおいて「セキュリティの穴」を自ら開けているに等しい。

—

2. base-uri: 相対パスのハイジャックを根絶する

私がインシデントハンドリングの現場で最も「盲点」だと感じるのが、タグの悪用だ。多くの開発者はタグを「相対リンクを解決するための便利なツール」程度にしか考えていない。しかし、攻撃者の視点から見れば、これは「サイト全体の通信先を書き換えるマスターキー」である。

「相対パス」の罠

攻撃者がXSSを通じてページ内にを挿入できた場合、以降そのページ内で読み込まれるすべての相対パス（スクリプト、CSS、画像、フォームの送信先）は、攻撃者のサーバーを起点として解決されることになる。