HTTPヘッダーフィールド完全ガイド：構造・代表例・セキュリティ対策

2025年12月12日 最終更新日時 : 2025年12月12日 エバープレイ編集部

はじめに

ネットワークやWeb開発に関わる人なら「ヘッダーフィールド（ヘッダー）」という言葉を一度は目にしたことがあるでしょう。ヘッダーフィールドは、HTTPリクエストやレスポンス、電子メール、その他多くのプロトコルにおいて、メタデータ（送信元・形式・キャッシュ制御・認証情報など）を伝達する重要な役割を担います。本コラムでは主にHTTPのヘッダーフィールドに焦点を当て、その構造、種類、代表的なフィールド、HTTP/2/3での取り扱い、セキュリティ上の注意点、運用上のベストプラクティスまで詳しく掘り下げます。

ヘッダーフィールドの基本構造とルール

HTTPヘッダーフィールドは基本的に「フィールド名: フィールド値」の形式を取ります。RFC 7230などの仕様により以下のようなルールがあります。

  • フィールド名は英字・数字・ハイフンで構成され、大文字小文字は区別されない（case-insensitive）。
  • フィールド値は通常テキストであり、特定のヘッダーではカンマ区切りで複数値を表現できる（ただしSet-Cookieのように結合できない例外もある）。
  • 廃止された折り返し（obsolete line folding）は避ける（RFC 7230で非推奨）。
  • ヘッダーはリクエストとレスポンスで種類が異なり、さらに汎用（general）、リクエスト専用、レスポンス専用、エンティティ（実体）ヘッダーなどに分類される。

代表的なリクエストヘッダー

Webアプリ開発でよく触れる主要なリクエストヘッダーとその役割を挙げます。

  • Host: リクエストの対象ホスト名（必須、仮想ホスティングで重要）。例: Host: example.com
  • User-Agent: クライアントの種類やバージョン情報（ブラウザやライブラリの識別に使用）。
  • Accept / Accept-Language / Accept-Encoding: クライアントが受け入れ可能なメディアタイプ、言語、圧縮方式を示す。
  • Authorization: ベーシックやBearerトークンなど認証情報を送る。
  • Cookie: クッキー値を送信する（注意：セキュリティに関わる）。
  • Content-Type / Content-Length: POSTやPUTなどで送る実体のメディアタイプと長さ。
  • Connection: 接続の持続（keep-alive）や切断を制御する（HTTP/1.1ではkeep-aliveがデフォルト）。

代表的なレスポンスヘッダー

レスポンス側で重要なヘッダーは以下の通りです。

  • Status-Line（ステータス行）とともに送られる基本情報。
  • Content-Type / Content-Length / Content-Encoding: レスポンスの実体タイプ、長さ、エンコーディング。
  • Cache-Control / Expires / ETag / Last-Modified: キャッシュの挙動を制御し、条件付きリクエストや検証に用いる。
  • Set-Cookie: サーバー側でクッキーを設定する。属性（Secure、HttpOnly、SameSite）を適切に設定することが重要。
  • Location: リダイレクト先のURL（3xxステータスとともに使用）。
  • WWW-Authenticate: 認証スキームを示す（401レスポンスで使用）。

HTTP/2・HTTP/3におけるヘッダの違い

HTTP/2ではヘッダーの転送効率向上のためにHPACKという圧縮方式を導入しています。ヘッダーフィールドは圧縮・エンコードされ、同一接続内での冗長なフィールドは効率的に扱われます。HTTP/2ではまた「pseudo-header」（:method, :path, :scheme, :authorityなど）という特殊なフィールド名が使われます。

HTTP/3ではQUICの上で動作し、ヘッダ圧縮にはHTTP/3向けのQPACKが使われます。これによりヘッダー圧縮のレイテンシやヘッダ破損時の影響を最小化する工夫がなされています。

CORS（クロスオリジン）と関連ヘッダー

ブラウザを介したクロスオリジンリクエストはセキュリティ上の制約があり、サーバーは適切なCORSヘッダーで明示的に許可する必要があります。代表的なヘッダー：

  • Access-Control-Allow-Origin: 許可するオリジン（"*"は全許可）。
  • Access-Control-Allow-Credentials: Cookieを含めるかどうか（true/false）。
  • Access-Control-Allow-Headers / Access-Control-Expose-Headers: 許可するリクエスト/レスポンスヘッダーを指定。
  • Access-Control-Max-Age: プリフライトのキャッシュ時間を指定。

不適切な設定は情報漏洩やセッション乗っ取りのリスクを招くため、必要最小限・明示的なオリジン指定と組み合わせた運用が重要です。

セキュリティ関連のヘッダー

近年はヘッダーレベルでセキュリティポリシーを付加するのが一般的になりました。主なもの：

  • Strict-Transport-Security (HSTS): HTTPSのみを強制し、MITMリスクを低減する。例: Strict-Transport-Security: max-age=31536000; includeSubDomains
  • Content-Security-Policy (CSP): スクリプトやリソースの読み込み先を制限し、XSSを抑制する。
  • X-Frame-Options / frame-ancestors（CSP）: クリックジャッキング防止のためフレーム埋め込みを制御。
  • X-Content-Type-Options: "nosniff" を設定してMIMEスニッフィングを防止。
  • Referrer-Policy: リファラ送信の挙動を制御。

また、クッキーはSet-Cookieで発行する際に Secure、HttpOnly、SameSite 属性を付けることで盗聴やCSRFのリスクを低減できます。

ヘッダーに関する運用上の注意点

  • 不要なヘッダーを出力しない：内部情報（サーバーソフト名やバージョンなど）は攻撃者に有用な情報を与えるため、不要であれば隠蔽する。
  • ヘッダー注入（Header Injection）を防ぐ：ユーザー入力をヘッダーに組み込む際は改行や制御文字を除去・検証する。
  • プロキシやロードバランサの影響を把握する：X-Forwarded-ForやForwardedヘッダーは信頼できる境界でのみ利用する。クライアントのIPを信頼する場合は検証が必要。
  • 複数値の結合ルールを理解する：複数ヘッダーをカンマで結合できる場合とできない（Set-Cookie等）場合があるため、仕様に従う。

ヘッダーの最適化とパフォーマンス

ヘッダーのサイズや数はレイテンシや帯域に影響します。特にモバイル環境や低帯域では以下の点が重要です。

  • 冗長なカスタムヘッダーを減らす。
  • HTTP/2やHTTP/3の導入でヘッダー圧縮を活用する（HPACK/QPACK）。
  • クッキーのサイズ最小化：大きなCookieは毎リクエストに付与され帯域を消費する。
  • キャッシュ制御を適切に設定して不要なリクエストを減らす。

実務におけるチェックリスト（導入・監査時）

  • 必須ヘッダー（Hostなど）が正しく送信されているか。
  • CORSポリシーが最小権限で設定されているか。
  • セキュリティヘッダー（HSTS、CSP、X-Content-Type-Optionsなど）が存在し適切に構成されているか。
  • Set-CookieにSecure/HttpOnly/SameSiteが付与されているか。
  • サーバー情報や内部情報がヘッダーに漏れていないか。
  • プロキシやCDNが追加・削除するヘッダーの挙動を理解しているか。

まとめ

ヘッダーフィールドはHTTP通信の表現力を大きく高める重要な仕組みですが、その扱いを誤るとセキュリティリスクや性能劣化を招きます。本稿で挙げた基本構造、代表的なヘッダー、HTTP/2・3での取り扱い、CORSやセキュリティヘッダー、運用上の注意点とベストプラクティスを押さえることで、安全で効率的なHTTP通信の設計・運用が可能になります。

参考文献

カテゴリー
IT
前の記事
ラスター画像とは？特徴・仕組み・フォーマット・最適化の完全ガイドNew!!
2025年12月12日
次の記事
秒速5センチメートル──新海誠が描く「距離」と「時間」の詩学New!!
2025年12月12日