HTTP Headers Explained: Request, Response & Security Headers

March 31, 2026 · 12 min read

HTTP headers are the unsung heroes of web communication. Every time you

HTTPヘッダーは、Webコミュニケーションの縁の下の力持ちです。Webページを読み込んだり、動画をストリーミングしたり、フォームを送信したりするたびに、数十のヘッダーが裏で働いてそれを実現しています。ヘッダーは、リクエストとレスポンスに関する重要なメタデータを運び、キャッシュの動作を制御し、セキュリティポリシーを適用し、最新のWeb機能を可能にします。

HTTPヘッダーの理解は、もはやバックエンド開発者だけのものではありません。フロントエンドエンジニアはAPI統合のために、DevOpsチームはパフォーマンス最適化のために、セキュリティ専門家は攻撃からアプリケーションを保護するためにヘッダーを必要としています。このガイドでは、基本概念から高度なセキュリティ実装まで、HTTPヘッダーについて知っておくべきすべてを解説します。

目次

• HTTPヘッダーとは?
• リクエストヘッダー:ブラウザが送信するもの
• レスポンスヘッダー:サーバーが返すもの
• セキュリティヘッダー:アプリケーションの保護
• キャッシュヘッダー:パフォーマンスの最適化
• CORSヘッダー:クロスオリジンリソース共有
• カスタムヘッダー:使用するタイミングと方法
• HTTPヘッダーのデバッグ
• よくある間違いとその回避方法
• HTTPヘッダーのベストプラクティス
• よくある質問
• 関連記事

HTTPヘッダーとは?

HTTPヘッダーは、HTTP通信中にクライアントとサーバー間で送信されるキーと値のペアです。コンテンツタイプ、エンコーディング、認証資格情報、キャッシュディレクティブ、セキュリティポリシーなど、リクエストまたはレスポンスに関する重要なコンテキストを提供します。

ヘッダーはシンプルな形式に従います:Header-Name: value。各ヘッダーは独自の行に表示され、空白行がヘッダーとメッセージ本文を区切ります。HTTP/1.1はプレーンテキストヘッダーを使用しますが、HTTP/2とHTTP/3はそれぞれHPACKとQPACKアルゴリズムを使用してヘッダーを圧縮します。

ヘッダーは主に4つのカテゴリに分類されます:

• リクエストヘッダー - クライアントがリクエストまたはクライアント自体に関する情報を提供するために送信
• レスポンスヘッダー - サーバーがレスポンスに関する情報を提供するために送信
• 表現ヘッダー - メッセージ本文の形式とエンコーディングを記述
• ペイロードヘッダー - コンテンツ長などのペイロードデータに関する情報を含む

最新のWebアプリケーションは通常、リクエスト-レスポンスサイクルごとに20〜40のヘッダーをやり取りします。一部は必須(HTTP/1.1のHostなど)ですが、他のものはオプションでもセキュリティとパフォーマンスのために強く推奨されます。

リクエストヘッダー:ブラウザが送信するもの

リクエストヘッダーは、クライアントが何を望んでいるか、何を処理できるかをサーバーに伝えます。受け入れ可能なコンテンツタイプ、優先言語、認証資格情報、クライアントの機能に関する情報が含まれます。

遭遇する最も重要なリクエストヘッダーは次のとおりです:

ヘッダー	目的	例
Host	サーバーのドメイン名を指定	Host: example.com
User-Agent	クライアントソフトウェアを識別	User-Agent: Mozilla/5.0...
Accept	クライアントが処理できるメディアタイプ	Accept: application/json
Accept-Language	レスポンスの優先言語	Accept-Language: en-US,en;q=0.9
Accept-Encoding	サポートされる圧縮アルゴリズム	Accept-Encoding: gzip, br
Authorization	認証資格情報	Authorization: Bearer token123
Cookie	ドメインに保存されたクッキー	Cookie: session=abc123
Referer	前のページのURL	Referer: https://google.com

Acceptヘッダーの理解

Acceptヘッダーは、複数の形式が受け入れ可能な場合に優先度を示すために品質値(q値)を使用します。値は0から1の範囲で、1が最高優先度です:

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

これはサーバーに次のように伝えます:「HTMLまたはXHTMLを優先しますが、XMLは90%の優先度で受け入れ、その他は80%の優先度で受け入れます。」サーバーはこれを使用してコンテンツネゴシエーションを実行し、最も適切な形式を返します。

User-Agentヘッダー

User-Agentヘッダーは、クライアントソフトウェア、オペレーティングシステム、デバイスタイプを識別します。分析やデバイス固有のコンテンツ提供には便利ですが、ユーザーエージェントのなりすましにより信頼性が低いことでも有名です。

最新のベストプラクティスは、ユーザーエージェントスニッフィングの代わりに機能検出を使用することです。ただし、ヘッダーはログ記録、デバッグ、ボット検出には依然として価値があります。

レスポンスヘッダー:サーバーが返すもの

レスポンスヘッダーは、コンテンツタイプ、キャッシュ指示、セキュリティポリシー、サーバー情報など、サーバーのレスポンスに関するメタデータを提供します。適切なコンテンツレンダリング、パフォーマンス最適化、セキュリティにとって重要です。

主要なレスポンスヘッダーには次のものがあります:

ヘッダー	目的	例
Content-Type	レスポンス本文のメディアタイプ	Content-Type: text/html; charset=utf-8
Content-Length	レスポンス本文のサイズ(バイト単位)	Content-Length: 1234
Content-Encoding	使用される圧縮アルゴリズム	Content-Encoding: gzip
Set-Cookie	クライアントにクッキーを送信	Set-Cookie: id=a3; Secure; HttpOnly
Location	リダイレクト用のURL	Location: https://example.com/new
Server	サーバーソフトウェアに関する情報	Server: nginx/1.18.0
Date	レスポンスが送信された日時	Date: Mon, 31 Mar 2026 12:00:00 GMT
ETag	リソースバージョンの一意の識別子	ETag: "33a64df551425fcc55e"

Content-Typeと文字エンコーディング

Content-Typeヘッダーは、適切なコンテンツレンダリングにとって重要です。レスポンス本文をどのように解釈するかをブラウザに伝えます。エンコーディングの問題を防ぐために、常に文字エンコーディング(通常はUTF-8)を含めてください:

Content-Type: application/json; charset=utf-8
Content-Type: text/html; charset=utf-8
Content-Type: image/png

Content-Typeヘッダーが欠落しているか不正確だと、ブラウザがコンテンツタイプを推測(MIMEスニッフィング)することになり、セキュリティの脆弱性やレンダリングの問題につながる可能性があります。

Set-Cookieヘッダー

Set-Cookieヘッダーは、クライアント側でクッキーを作成します。最新のクッキーには常にセキュリティ属性を含める必要があります:

• Secure - HTTPS接続でのみ送信
• HttpOnly - JavaScriptアクセスを防止してXSSリスクを軽減
• SameSite - クロスサイトクッキーの動作を制御(Strict、Lax、またはNone)
• Max-AgeまたはExpires - クッキーの有効期間を定義

Set-Cookie: sessionId=abc123; Secure; HttpOnly; SameSite=Strict; Max-Age=3600

セキュリティヘッダー:アプリケーションの保護

セキュリティヘッダーは、一般的なWeb脆弱性に対する最初の防御線です。XSS、クリックジャッキング、中間者攻撃などの攻撃からユーザーを保護するセキュリティポリシーを適用するようブラウザに指示します。

すべての本番アプリケーションは、これらの必須セキュリティヘッダーを実装する必要があります:

Content-Security-Policy (CSP)

CSPは、ブラウザが読み込めるリソースを制御することでXSS攻撃を防ぎます。最も強力なセキュリティヘッダーの1つですが、慎重な設定が必要です:

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com

制限的なポリシーから始めて、必要に応じて徐々に緩和します。Content-Security-Policy-Report-Onlyを使用して、サイトを壊すことなくポリシーをテストしましょう。

Strict-Transport-Security (HSTS)

HSTSは、ドメインへの今後のすべてのリクエストにHTTPSを使用するようブラウザに強制し、プロトコルダウングレード攻撃を防ぎます:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

preloadディレクティブを使用すると、ドメインをHSTSプリロードリストに送信できます。これはブラウザにハードコードされています。これによりh; Free Online Network Tools