【実務・中級編】X-Content-Type-Options: nosniffによるMIMEタイプスニッフィング防止 – アプリケーションセキュリティ & 安全な開発防御ガイド

現場でインシデント対応をしていると、「なぜこんな単純なことで？」と頭を抱えたくなるような攻撃に遭遇することがある。その代表例がMIMEタイプスニッフィングだ。

現代のブラウザは非常に親切だ。サーバーが「これはただの画像ファイルだよ」と言っていても、中身を見て「お、これJavaScriptっぽいから実行してやろう」と気を利かせてくれる。この「親切心」が、攻撃者にとっては最高のゲートウェイになる。

今日は、このブラウザのおせっかいを強制終了させる X-Content-Type-Options: nosniff について、実戦的な話をしよう。

—

想像してほしい。あなたのWebアプリには、ユーザーがアバター画像をアップロードできる機能がある。セキュリティ対策として、拡張子チェックやファイルサイズ制限は入れている。

しかし、攻撃者はこう考える。
「画像ファイルの中に、悪意あるJavaScriptコードを埋め込んでアップロードしたらどうなる？」

もし、アプリケーションのレスポンスに正しい Content-Type が設定されていなかったり、ブラウザがその判定を無視しようとしたりすると、ブラウザは画像ファイルを「スクリプト」として解釈し、実行してしまう。これがクロスサイトスクリプティング（XSS）の起点になるわけだ。

攻撃者は、アップロードした画像ファイルに細工を施し、ユーザーのセッション情報を盗む。このとき、X-Content-Type-Options: nosniff があれば、ブラウザは「サーバーが言ったこと以外は絶対に実行しない」という強固な態度を貫ける。

—

この設定は、コードを書くというより「レスポンスヘッダーを正しく送る」というインフラ・フレームワークレベルの作法だ。

Webサーバーの入り口で一括設定するのが最も確実だ。nginx.conf または各サイトの設定ファイルに以下を追記してほしい。

サーバー全体で nosniff を強制する
add_header X-Content-Type-Options nosniff always;

ついでに CSP も設定しておくと、より堅牢になる
add_header Content-Security-Policy “default-src ‘self’;” always;

※ always をつけるのがポイントだ。エラーページ（4xx/5xx）を含め、すべてのレスポンスに確実にこのヘッダーを付与するためだ。

もし共有サーバーなどでWebサーバーの設定をいじれない場合は、PHPの冒頭で送出する。

3. なぜ「Content-Type」の明示がセットなのか

勘違いしてはいけない。nosniff はあくまで「誤判定による誤実行」を防ぐためのガードレールだ。一番の基本は、サーバー側が正しい Content-Type を返すことだ。

例えば、JSONを返すAPIなのに text/html と偽って送信したり、アップロードされたファイルのMIMEタイプを application/octet-stream（バイナリ）のまま放置したりしていると、nosniff をつけていても、ブラウザ側の処理で不整合が起きる。

これらを正しく設定した上で、最後に nosniff で「ブラウザの勝手な推測を禁止する」のが、セキュリティの鉄則だ。

—

「とりあえず動けばいい」という実装は、数年後に必ずインシデントの火種になる。

X-Content-Type-Options: nosniff は、たった1行のヘッダーだが、ブラウザという「強力だが時に予測不能なクライアント」をコントロールするための重要なスイッチだ。

今日からあなたの管理するシステムすべてで、開発者コンソールの「ネットワーク」タブを開いて確認してほしい。レスポンスヘッダーに X-Content-Type-Options: nosniff が入っているか？もし入っていなければ、それはあなたのアプリに「脆弱性が一つ残っている」というサインだ。

コードを書くとき、インフラを組むとき、常に「ブラウザがどう解釈するか？」という視点を忘れないこと。それが、真にセキュアなアプリケーションを作るための最短ルートだ。