暗号化・安全な通信

HTTP ヘッダー (HTTP Header)

約 5 分で読めます

HTTP ヘッダーとは

HTTP ヘッダー (HTTP Header) とは、クライアント (ブラウザ) とサーバーが HTTP 通信を行う際に、本文 (ボディ) とは別にやり取りするメタ情報のことです。リクエストヘッダーはクライアントからサーバーへ、レスポンスヘッダーはサーバーからクライアントへ送信されます。

ヘッダーは「名前: 値」の形式で記述され、コンテンツの種類、キャッシュの制御、認証情報、セキュリティポリシーなど、通信に関するあらゆる付帯情報を伝達します。Web 開発者にとって HTTP ヘッダーの理解は必須であり、特にセキュリティ関連ヘッダーの適切な設定はサイト防御の基盤となります。

リクエストヘッダーとレスポンスヘッダー

HTTP ヘッダーは送信方向によって大きく 2 種類に分かれます。

リクエストヘッダー
クライアントがサーバーに送信するヘッダー。User-Agent (ブラウザの種類)、Accept (受け入れ可能なコンテンツタイプ)、Authorization (認証トークン)、Cookie (保存済みの Cookie 情報) などが含まれる。サーバーはこれらの情報をもとにレスポンスを最適化する。
レスポンスヘッダー
サーバーがクライアントに返すヘッダー。Content-Type (レスポンスの MIME タイプ)、Set-Cookie (Cookie の設定指示)、Cache-Control (キャッシュポリシー)、各種セキュリティヘッダーが含まれる。

加えて、リクエスト・レスポンスの両方で使用される汎用ヘッダー (DateConnection など) や、ボディの属性を示すエンティティヘッダー (Content-LengthContent-Encoding など) も存在します。

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

レスポンスヘッダーの中でも、ブラウザのセキュリティ機能を制御するセキュリティヘッダーは Web サイト防御の要です。

  • Content-Security-Policy (CSP): ページが読み込めるリソースの提供元を制御する。XSS 攻撃の被害を大幅に軽減する最も強力なセキュリティヘッダー。
  • Strict-Transport-Security (HSTS): ブラウザに対して、以降のアクセスを HTTPS のみに強制する。HTTP へのダウングレード攻撃を防止する。
  • X-Frame-Options: ページが <iframe> に埋め込まれることを制御する。クリックジャッキング対策として機能する。DENY (完全拒否) または SAMEORIGIN (同一オリジンのみ許可) を指定する。CSP の frame-ancestors ディレクティブが後継だが、古いブラウザとの互換性のため併用が推奨される。
  • X-Content-Type-Options: nosniff を指定することで、ブラウザの MIME タイプスニッフィングを無効化する。サーバーが指定した Content-Type と異なる解釈を防ぎ、スクリプトインジェクションのリスクを低減する。

これらのヘッダーは個別に機能するだけでなく、組み合わせることで多層防御を構築します。1 つのヘッダーが突破されても、他のヘッダーが攻撃を阻止する設計です。

キャッシュ制御ヘッダー

キャッシュ制御ヘッダーは、ブラウザや CDN がレスポンスをどの程度保持するかを指定します。適切な設定はパフォーマンスとセキュリティの両方に影響します。

  • Cache-Control: キャッシュの動作を細かく制御する最も重要なヘッダー。max-age=3600 (1 時間キャッシュ)、no-cache (毎回サーバーに検証を要求)、no-store (一切キャッシュしない) などのディレクティブを組み合わせる。認証情報を含むページには no-store, private を指定し、共有キャッシュへの保存を防ぐ。
  • ETag: リソースの特定バージョンを識別するハッシュ値。ブラウザは次回リクエスト時に If-None-Match ヘッダーで ETag を送信し、サーバーはリソースが変更されていなければ 304 Not Modified を返す。ボディの転送を省略できるため帯域を節約できる。
  • Last-Modified / If-Modified-Since: リソースの最終更新日時に基づく条件付きリクエスト。ETag と同様に 304 レスポンスによる帯域節約が可能だが、秒単位の精度しかないため ETag との併用が推奨される。

静的アセット (CSS、JS、画像) には長い max-age とファイル名にハッシュを含める戦略が一般的です。HTML ページには no-cache を指定し、常に最新版を取得させつつ ETag で効率化する手法が広く使われています。

プライバシー関連ヘッダー

近年のプライバシー意識の高まりに伴い、ユーザーの追跡やデータ収集を制御するヘッダーの重要性が増しています。

  • Referrer-Policy: ページ遷移時に送信される Referer ヘッダーの内容を制御する。strict-origin-when-cross-origin (クロスオリジンではオリジンのみ送信) が推奨設定。no-referrer を指定すると Referer を一切送信しない。ユーザーの閲覧履歴が外部サイトに漏洩するのを防ぐ。
  • Permissions-Policy: ブラウザの機能 (カメラ、マイク、位置情報、加速度センサーなど) へのアクセスを制御する。Permissions-Policy: camera=(), microphone=(), geolocation=() のように、不要な機能を明示的に無効化することで、悪意のあるスクリプトによるデバイス機能の悪用を防止する。旧名は Feature-Policy
  • Cross-Origin ヘッダー群: Cross-Origin-Opener-Policy (COOP)、Cross-Origin-Embedder-Policy (COEP)、Cross-Origin-Resource-Policy (CORP) は、クロスオリジンでのリソース共有やウィンドウ参照を制御する。Spectre 攻撃への対策として導入された。

セキュリティヘッダーとプライバシーヘッダーを適切に組み合わせることで、ユーザーのデータを保護しつつ、攻撃面を最小化できます。ヘッダーの設定状況は securityheaders.com などのツールで簡単にチェックできます。

よくある誤解

HTTP ヘッダーはサーバー管理者だけが気にすればよい
フロントエンド開発者にとっても HTTP ヘッダーの理解は不可欠です。CORS エラーの原因究明、キャッシュ戦略の設計、CSP の導入など、日常的な開発作業でヘッダーの知識が求められます。ブラウザの開発者ツールでヘッダーを確認する習慣をつけることが重要です。
セキュリティヘッダーを設定すれば脆弱性がなくなる
セキュリティヘッダーは多層防御の一層であり、アプリケーション自体の脆弱性 (入力検証の不備、認証の欠陥など) を修正する代わりにはなりません。ヘッダーはブラウザの挙動を制御して攻撃の影響を軽減するものであり、根本的な脆弱性対策と併用して初めて効果を発揮します。
共有する
B!

関連用語

関連記事