HTTP ヘッダー (HTTP Header)
約 5 分で読めます
最終更新: 2026-04-18
HTTP ヘッダーとは
HTTP ヘッダー (HTTP Header) とは、クライアント (ブラウザ) とサーバーが HTTP 通信を行う際に、本文 (ボディ) とは別にやり取りするメタ情報のことです。リクエストヘッダーはクライアントからサーバーへ、レスポンスヘッダーはサーバーからクライアントへ送信されます。
ヘッダーは「名前: 値」の形式で記述され、コンテンツの種類、キャッシュの制御、認証情報、セキュリティポリシーなど、通信に関するあらゆる付帯情報を伝達します。Web 開発者にとって HTTP ヘッダーの理解は必須であり、特にセキュリティ関連ヘッダーの適切な設定はサイト防御の基盤となります。
リクエストヘッダーとレスポンスヘッダー
HTTP ヘッダーは送信方向によって大きく 2 種類に分かれます。
User-Agent (ブラウザの種類)、Accept (受け入れ可能なコンテンツタイプ)、Authorization (認証トークン)、Cookie (保存済みの Cookie 情報) などが含まれる。サーバーはこれらの情報をもとにレスポンスを最適化する。Content-Type (レスポンスの MIME タイプ)、Set-Cookie (Cookie の設定指示)、Cache-Control (キャッシュポリシー)、各種セキュリティヘッダーが含まれる。加えて、リクエスト・レスポンスの両方で使用される汎用ヘッダー (Date、Connection など) や、ボディの属性を示すエンティティヘッダー (Content-Length、Content-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 の導入など、日常的な開発作業でヘッダーの知識が求められます。ブラウザの開発者ツールでヘッダーを確認する習慣をつけることが重要です。
- セキュリティヘッダーを設定すれば脆弱性がなくなる
- セキュリティヘッダーは多層防御の一層であり、アプリケーション自体の脆弱性 (入力検証の不備、認証の欠陥など) を修正する代わりにはなりません。ヘッダーはブラウザの挙動を制御して攻撃の影響を軽減するものであり、根本的な脆弱性対策と併用して初めて効果を発揮します。