Content-Typeと文字コードを全テキスト応答へ明示とは？charset指定の重要性・設定方法・診断基準

Content-Typeと文字コードを全テキスト応答へ明示するとは

Content-Typeと文字コードを全テキスト応答へ明示するとは、サイトが返すHTTP応答すべてに Content-Type ヘッダーを付け、テキスト系（text/*）とXML系（application/xml、application/〜+xml）の応答には charset パラメータで文字コードを明示することです。

Content-Type: text/html; charset=UTF-8

トップページだけ正しく設定されていても、下層のCMS出力ページや別アプリ、静的HTMLの一部で文字コード宣言が漏れていることはよくあります。そのためセキュリティAIチェッカーのこの項目は、「全ページで揃っているか」を見る網羅性（coverage）の項目として設計されています。単一ページのHTML内 <meta charset> を見る「文字コードが明示されている」とは別の、レスポンスヘッダー側の確認です。

Content-Typeとcharsetの役割

Content-Type: text/html; charset=UTF-8 のように、Content-Typeはメディアタイプ（何のデータか）と、パラメータ（文字の符号化方式など）を伝えます（RFC 9110 §8.3、charsetは§8.3.2）。ブラウザはこの値をもとに、次のことを決めます。

• HTMLとして解釈するか、プレーンテキストとして表示するか
• どの文字コードでバイト列を文字に戻すか

charsetが伝わらないとき、ブラウザはどう文字コードを決めるか

charsetが伝わらない場合、ブラウザはおおむね次の順で文字コードを決めます。

1. BOM（バイト順マーク）
2. HTML内の <meta charset>（先頭1024バイト以内）
3. 親フレームの文字コード
4. 内容からの推測
5. ロケール既定値

推測の結果がサーバー側の想定と食い違うと、文字化けだけでなく、エスケープ処理の前提が崩れることがあります。

なぜContent-Typeと文字コードの明示がセキュリティ対策になるのか

文字コード誤認によるXSS（IPA 5-(viii)）

IPAの「安全なウェブサイトの作り方」は、XSSの根本的解決の一つとして「HTTPレスポンスヘッダのContent-Typeフィールドに文字コード（charset）を指定する」（5-(viii)）を挙げています。

典型例として、UTF-7で +ADw-script+AD4- のように書かれた文字列は、サーバーのHTMLエスケープでは < > を含まないため素通りし、ブラウザがUTF-7と判定すると <script> として解釈されるという問題が知られています。現在の主要ブラウザはUTF-7をHTMLの文字コードとして扱わないため、この攻撃そのものは過去のものになりつつあります。しかし、Shift_JISやEUC-JPなどマルチバイト文字コードの判定違いによりエスケープ済み文字列の境界がずれる問題など、「サーバーとブラウザで文字コードの認識を一致させる」という原則は今も有効です。

OWASP ASVS 5.0.0 V4.1.1の要件

ASVS 5.0.0 V4.1.1（Level 1）は、本文を持つすべてのHTTP応答に、実際の内容と一致するContent-Typeを付け、text/、/+xml、/xml のようなメディアタイプではcharsetパラメータで安全な文字コード（UTF-8、ISO-8859-1など）を指定することを求めています。あわせてV3.4.4（Level 2）は、全応答に X-Content-Type-Options: nosniff を付けることを求めています。

charsetが不要なメディアタイプ

Content-Typeと文字コードについてよくある誤解

• 「HTMLに <meta charset="UTF-8"> があるから十分」：HTML内の宣言はブラウザが先頭を読んで初めて効くもので、ヘッダーで先に宣言する方が確実です。ASVS・IPAともにヘッダーでの指定を求めています。両方を一致させるのが最善です。
• 「Content-Typeはサーバーが自動で付ける」：静的ファイルは拡張子から推定されますが、PHPやCGIの出力、CMSの独自出力、エラーページ、リバースプロキシ経由の応答では欠けることがあります。
• 「nosniffを付ければContent-Typeは不要」：nosniffはContent-Typeを前提に推測を止める仕組みです。Content-Typeが無い・誤っている応答は、nosniff下では正しく表示されない、またはブロックされる原因になります。nosniffの網羅性は「nosniffを全応答へ適用」で確認します。

Content-Typeと文字コードを全テキスト応答へ明示の診断基準（セキュリティAIチェッカー）

取得方法

1. V2診断で取得できた同一オリジンの巡回ページ（<a href>・GETフォームのaction等から抽出。ログアウト・削除系のURLや、css・js・画像・PDF等の拡張子は除外）のうち、トップページ以外の先頭2件を追加でGET取得します。
2. 対象はトップページと合わせて最大3ページです（取得失敗・本文上限超過・別オリジンへのリダイレクトは除外）。
3. リクエストは1件あたりタイムアウト5秒、本文上限180KB、リダイレクト最大2回で、追加診断全体のリクエスト上限（40件）の範囲で行います。
4. 各応答の Content-Type ヘッダー値を判定します。

判定条件

• charsetの判定は ;\s*charset= の有無で行い、値の種類（UTF-8、Shift_JIS等）は問いません。ただし実体と一致しない値は文字化けの原因になるため、修正時は必ず実際の符号化方式と合わせてください。
• 本文が空の応答（204等）はContent-Typeを要求しません（ASVSの要件も「本文を持つ応答」が対象です）。
• application/json や画像などはContent-Typeさえあればpassです。image/svg+xml のように application/ 以外の +xml 型も本診断ではcharsetを要求しませんが、ASVSの趣旨では付与が望まれます。
• 証拠欄には「該当ページ数/判定ページ数」を表示します。
• スコアは「pass=1.00、warn=0.45、fail=0」の係数に重みを掛けた加重平均で計算され、na項目は分母から除外されます。

自治体サイトでの判定例

Content-Typeや文字コードの明示が漏れているとどんなリスクがあるか

• 文字コード誤認によるXSS：charset不明の応答で、ブラウザが攻撃者の意図した文字コードで解釈すると、サーバー側のエスケープが無効化される可能性があります。現行ブラウザでの成立条件は限られますが、旧来の端末や組込みブラウザでは残る可能性があります。
• MIMEスニッフィングによる誤解釈：Content-Typeが無いと、ブラウザが内容からHTMLやスクリプトと推測することがあります。利用者がアップロードしたファイルや、エラーメッセージに入力値を含む応答がHTMLとして描画されると、XSSの足がかりになります。
• 表示崩れ・情報の誤伝達：文字化けにより、避難情報や手続き案内が読めなくなるという可用性上の被害もあります。自治体サイトではこちらの影響も無視できません。

Content-Typeと文字コードの設定方法（Apache・nginx・IIS・PHP・Next.js）

Apache（.htaccess / httpd.conf）

# text/plain と text/html に既定のcharsetを付与
AddDefaultCharset UTF-8

# その他のテキスト系拡張子にもcharsetを付与（mod_mime）
<IfModule mod_mime.c>
  AddCharset UTF-8 .html .htm .css .js .txt .xml .csv .rss .atom .svg
</IfModule>

AddDefaultCharset は既定でOffで、指定すると text/plain と text/html の応答にcharsetを追加します。Shift_JISで作られた古いページが残っている場合、全体をUTF-8と宣言すると文字化けするため、ディレクトリ単位で AddDefaultCharset Shift_JIS を指定するか、先に文字コードをUTF-8へ変換してください。

nginx

http {
    charset utf-8;
    # 既定の charset_types（text/html, text/xml, text/plain 等）に加えたいもの
    charset_types text/css text/plain text/xml application/javascript application/rss+xml application/atom+xml image/svg+xml;
}

charset はngx_http_charset_moduleのディレクティブで、既定値は off です。text/html は常に対象で、それ以外は charset_types（既定は text/html・text/xml・text/plain・text/vnd.wap.wml・application/javascript・application/rss+xml）に含まれるものだけにcharsetが付きます。

IIS（web.config）

<configuration>
  <system.webServer>
    <staticContent>
      <remove fileExtension=".html" />
      <mimeMap fileExtension=".html" mimeType="text/html; charset=UTF-8" />
      <remove fileExtension=".css" />
      <mimeMap fileExtension=".css" mimeType="text/css; charset=UTF-8" />
    </staticContent>
  </system.webServer>
  <system.web>
    <globalization requestEncoding="utf-8" responseEncoding="utf-8" />
  </system.web>
</configuration>

ASP.NETの動的ページは system.web 配下の globalization 設定で応答の文字コードが決まります。静的ファイルは mimeMap でcharset付きのMIMEタイプを指定します。

PHP

<?php
// 出力より前に送る
header('Content-Type: text/html; charset=UTF-8');
// php.ini 側でも default_charset = "UTF-8"（PHP 5.6以降の既定値）を確認

Next.js（Vercel）

Next.jsのページ応答は既定で text/html; charset=utf-8 になります。Route Handlerで独自に応答を返す場合は明示します。

export async function GET() {
  return new Response("本文", {
    headers: { "Content-Type": "text/plain; charset=utf-8" },
  });
}

段階的な導入手順

設定後の確認方法

# ヘッダーだけ確認
curl -sI https://www.example.lg.jp/ | grep -i '^content-type'
curl -sI https://www.example.lg.jp/kurashi/index.html | grep -i '^content-type'

# エラーページも確認（本項目の対象外でも整えておく）
curl -s -o /dev/null -D - https://www.example.lg.jp/no-such-page | grep -i '^content-type'

Content-Type: text/html; charset=UTF-8 のようにcharsetまで表示されれば対応済みです。設定を変えたら、セキュリティAIチェッカーで再診断し、証拠欄の該当ページ数が0になっていることを確認します。

サイトを壊さないための注意点

• 実体と違うcharsetを宣言しない：Shift_JISのファイルをUTF-8と宣言すると全面的に文字化けします。宣言の変更より先に実体を確認してください。
• CSV・ダウンロードファイル：Excelで開く前提のCSVをShift_JISで配布している場合、UTF-8を一律付与すると文字化けします。拡張子ごとに設定を分けてください。
• CDN・プロキシのキャッシュ：ヘッダー変更後はキャッシュを削除しないと古い応答が残ります。

よくある質問（FAQ）

参考資料

• OWASP ASVS 5.0.0 V4 API and Web Service（4.1.1）
• OWASP ASVS 5.0.0 V3 Web Frontend Security（3.4.4）
• IPA 安全なウェブサイトの作り方 1.5 クロスサイト・スクリプティング
• RFC 9110 HTTP Semantics
• RFC 8259 The JSON Data Interchange Format
• Apache HTTP Server core（AddDefaultCharset）
• nginx ngx_http_charset_module

「Content-Typeと文字コードを全テキスト応答へ明示」と関連する診断項目

• 文字コードが明示されているlow
• nosniffを全応答へ適用medium
• Content-Typeが明示されているmedium
• 過大な初期HTMLを配信していないlow
• ページタイトルが設定されているlow
• html要素に言語が設定されているlow
• canonicalが安全なURLを指しているmedium