MIMEスニッフィングとX-Content-Type-Optionsの防御

ブラウザは、サーバーが Content-Type で宣言した型を必ずしも鵜呑みにしません。宣言が欠けていたり曖昧だったりすると、本文の中身を覗いて「これは本当は HTML ではないか」と推測します。利便性のための機能ですが、これが攻撃者の用意したデータを実行可能なコンテンツへ昇格させる経路になります。ここでは、ブラウザが型を推測する条件と、X-Content-Type-Options: nosniff がどの判定を止めるのかを原理から整理します。

なぜブラウザは型を推測するのか

HTTP レスポンスの本文をどう扱うかは、本来 Content-Type ヘッダ（MIME タイプ）が決めます。text/html ならパースして DOM を構築し、image/png なら画像としてデコードし、text/plain ならテキストとして表示する、という対応です。問題は、この宣言が当てにならないサーバーが歴史的に多かったことです。設定ミスで Content-Type が付かない、すべて text/plain で返す、拡張子と中身が食い違う——こうしたサイトでも「とりあえず正しく表示される」ことをブラウザは競争上求められました。

そこでブラウザは、宣言が信用できないと判断したとき本文の**先頭バイト列（おおむね最初の512バイト程度）**を検査し、既知のシグネチャ（マジックバイト）と照合して型を推し量ります。これが MIME スニッフィング です。挙動は WHATWG の MIME Sniffing Standard で標準化されており、検査するバイトパターンと優先順位が定義されています。

スニッフィングが起きる典型条件は、(1) Content-Type ヘッダが無い、(2) application/octet-stream のような汎用型や text/plain で「不明」に近い、(3) 宣言は画像系なのに本文先頭が HTML シグネチャと一致する、といった宣言と中身の矛盾です。ブラウザは「ユーザーの意図に近い方」を選ぼうとして、中身を優先してしまうことがあります。

スニッフィングが攻撃になる構造

推測のどこが危険か。鍵は「型が変わると、どの実行エンジンへ本文が渡るかが変わる」点です。image/png として扱えば画像デコーダへ、text/html として扱えば HTML パーサと JavaScript エンジンへ本文が流れます。攻撃者がコンテンツの先頭バイトを制御できれば、宣言を画像にしておきながら中身を HTML にして、HTML としての解釈を引き出せます。

この攻撃が成立するのは、宣言型より推測型が優先される瞬間です。同種の問題は、text/plain で返したつもりの JSON API レスポンスが HTML と誤認される、application/octet-stream のダウンロード用ファイルがインライン表示で HTML 実行される、といった形でも起こります。被害は注入が成立したオリジンの信頼境界の中で発生するため、同一オリジンポリシーとサイト分離の信頼境界 でいう「同一オリジン＝同一の信頼単位」がそのまま被害範囲になります。

nosniff が止める判定

これを断つのが X-Content-Type-Options: nosniff レスポンスヘッダです。値は nosniff の一語のみで、意味は「宣言された Content-Type を最終決定とし、本文からの型推測を行うな」です。nosniff が付いた応答に対し、ブラウザは2種類の強制をかけます。

第一に、スクリプトとスタイルシートでは MIME タイプのミスマッチを致命的エラーにします。<script src> で読み込むリソースの Content-Type が JavaScript 系（text/javascript など）でなければ、nosniff 下のブラウザは実行を拒否しブロックします。<link rel=stylesheet> も text/css 以外なら適用しません。これにより、画像 URL やテキストエンドポイントを <script> で参照して中身を実行させる手口が塞がれます。

第二に、文書・画像などその他のリソースでは、宣言型からの昇格スニッフィングを禁止します。Content-Type: image/png と宣言されたものを、本文が HTML に見えるからといって text/html へ格上げすることをしません。先述の画像偽装 XSS が成立しなくなるのはこの効果です。

ダウンロードとスクリプト実行判定への波及

nosniff は単独でなく、関連するヘッダと噛み合って効きます。とくに重要なのがダウンロード時の挙動です。

ユーザー由来ファイルを「表示せずダウンロードさせる」意図なら、Content-Disposition: attachment を付けて保存ダイアログへ誘導します。ただしこれだけでは、ブラウザによってはインラインプレビューや型推測の余地が残ります。nosniff を併用すると、宣言型を尊重しつつ余計な推測を止められるため、両者の組み合わせが定石です。さらに、ユーザー投稿コンテンツは可能なら**本体とは別オリジン（サンドボックス用ドメイン）**で配信し、万一実行されても本体オリジンの信頼境界へ届かないようにします。

スクリプト実行判定への影響も実務上見落とされがちです。nosniff 環境では、Content-Type の付け間違いが「動かない」という形で顕在化します。たとえば JS ファイルを誤って text/plain や application/octet-stream で配信していると、nosniff 有効サイトではスクリプトが実行拒否されて壊れます。これは欠陥ではなく、推測に頼らず宣言を正とする設計の当然の帰結です。CDN やストレージから JS/CSS を配信する場合は、配信側の MIME 設定が正しいことを nosniff 導入の前提として確認します。

多層防御での位置づけ

nosniff は導入コストが極めて低く（ヘッダ一行）、副作用も「正しい Content-Type を要求する」だけなので、ほぼ全レスポンスへ付けてよい類のヘッダです。多くのセキュリティガイドラインが既定での付与を推奨しています。

ただし nosniff が塞ぐのはあくまで「型推測を悪用する経路」に限られます。Content-Type: text/html で正しく宣言された本文に攻撃者の HTML が混ざっていれば、nosniff があっても XSS は成立します。これは出力エスケープと安全な DOM API で防ぐ領域で、DOM-based XSSのsink/source分類と緩和原理 と Trusted TypesによるDOM-based XSSの構造的防止 の守備範囲です。