ヘッダーとCookie — リクエスト/レスポンスに含まれる情報
この章の目次開く
HTTPリクエストとレスポンスは、ボディ（本文）だけでなく ヘッダー という付加情報を持っています。認証トークン、コンテンツの形式、キャッシュの制御、Cookieなど、HTTP通信の重要な制御情報はすべてヘッダーでやりとりされます。
この章では、主要なHTTPヘッダーの役割と、Web開発で特に重要な Cookie の仕組みを整理します。
学習者ログイン状態ってどうやって覚えてるの？Cookie って聞くけど、仕組みがピンとこない…。
HTTPメッセージの構造
リクエストもレスポンスも、スタートライン + ヘッダー + 空行 + ボディ という共通の構造です。
POST /api/users HTTP/1.1 ← スタートライン（メソッド、パス、バージョン）
Host: api.example.com ← ヘッダー（複数行）
Content-Type: application/json
Authorization: Bearer eyJhbG...
← 空行（ヘッダーとボディの区切り）
{"name": "Alice"} ← ボディ
レスポンスも同様です。
HTTP/1.1 200 OK ← スタートライン（バージョン、ステータスコード）
Content-Type: application/json
Set-Cookie: session=abc123
{"id": 1, "name": "Alice"}
よく使うリクエストヘッダー
| ヘッダー | 役割 | 例 |
|---|---|---|
Host | リクエスト先のホスト名 | api.example.com |
Content-Type | ボディのデータ形式 | application/json |
Authorization | 認証情報 | Bearer eyJhbG... |
Accept | 受け取りたいレスポンスの形式 | application/json |
User-Agent | クライアントの情報 | ブラウザ名やバージョン |
Cookie | 保存済みCookieの送信 | session=abc123 |
Content-Typeの重要性
Content-Type はサーバーが「ボディをどう解釈するか」を決めるヘッダーです。これが間違っていると、サーバーがボディを正しくパースできません。
// JSON形式で送る場合
Content-Type: application/json
// フォームデータで送る場合
Content-Type: application/x-www-form-urlencoded
// ファイルアップロードの場合
Content-Type: multipart/form-data
よく使うレスポンスヘッダー
| ヘッダー | 役割 | 例 |
|---|---|---|
Content-Type | レスポンスのデータ形式 | application/json; charset=utf-8 |
Set-Cookie | Cookieの設定 | session=abc123; HttpOnly; Secure |
Cache-Control | キャッシュの制御 | max-age=3600 |
Location | リダイレクト先 | /api/users/42 |
Access-Control-Allow-Origin | CORS許可 | https://example.com |
キャッシュ制御
Cache-Control ヘッダーは、ブラウザや中間プロキシに「このレスポンスをどの程度キャッシュしていいか」を指示します。
// 1時間キャッシュしてよい
Cache-Control: max-age=3600
// キャッシュしてはいけない
Cache-Control: no-store
// キャッシュしてよいが、使う前に再検証すること
Cache-Control: no-cache
| ディレクティブ | 意味 |
|---|---|
max-age=N | N秒間キャッシュしてよい |
no-store | 一切キャッシュしない |
no-cache | キャッシュするが毎回再検証 |
private | ブラウザのみキャッシュ可（CDNは不可） |
public | CDNを含めキャッシュ可 |
Cookieの仕組み
Cookie は、サーバーがブラウザに「この値を覚えておいて、次のリクエストで送り返して」と依頼する仕組みです。HTTPは本来ステートレス（状態を持たない）ですが、Cookieによって「ログイン状態」のような状態管理が可能になります。
Cookieの流れ
- サーバーがレスポンスに
Set-Cookieヘッダーを含める - ブラウザがその値を保存する
- 以降、同じドメインへのリクエストに
Cookieヘッダーとして自動送信する
Cookieのセキュリティ属性
Cookieには付加属性があり、セキュリティ上の制御に使います。
Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=86400
| 属性 | 意味 | 設定しないリスク |
|---|---|---|
HttpOnly | JavaScriptからアクセスできない | XSSでCookieを盗まれる |
Secure | HTTPS接続でのみ送信 | 平文HTTP経由で盗聴される |
SameSite | クロスサイトリクエストでの送信を制御 | CSRF攻撃を受けやすい |
Path | 指定パス以下でのみ送信 | 不要な範囲にCookieが飛ぶ |
Max-Age | 有効期限（秒数） | ブラウザ終了時に消える |
SameSiteの3つの値
| 値 | 挙動 |
|---|---|
Strict | 他サイトからのリクエストにはCookieを送らない |
Lax | 他サイトからのGETリクエスト（リンククリック）には送る |
None | 常に送る（Secure 属性が必須） |
CookieとlocalStorageの使い分け
ブラウザでデータを保存する方法はCookieだけではありません。よく比較されるのが localStorage です。
| Cookie | localStorage | |
|---|---|---|
| サーバーへの送信 | 自動で送信される | 送信されない |
| 容量 | 約4KB | 約5MB |
| 有効期限 | 設定可能 | 永続（手動削除まで） |
| JavaScript | HttpOnlyで保護可 | 常にアクセス可能 |
| 用途 | セッション管理、認証 | UI設定、一時データ |
セッション管理にはCookie（HttpOnly）、UIの状態保持にはlocalStorage、というのが一般的な使い分けです。
DevToolsでヘッダーとCookieを確認する
リクエスト・レスポンスヘッダーの確認
NetworkタブでリクエストをクリックするとHeadersタブが開きます。ここで Request Headers（送信側）と Response Headers（受信側）の両方を確認できます。
実務で特にチェックする項目:
| 確認項目 | 見るべきヘッダー | よくある問題 |
|---|---|---|
| 認証トークンが送れているか | Authorization | トークンの付け忘れ、有効期限切れ |
| データ形式が正しいか | Content-Type | application/json の付け忘れ |
| CORSが通っているか | Access-Control-Allow-Origin | オリジンの不一致 |
| キャッシュが効いているか | Cache-Control, ETag | 古いデータが表示される |
Cookieの確認
Chrome DevToolsの Application タブ → Cookies で、現在のドメインに保存されているCookieの一覧と、各セキュリティ属性を確認できます。
確認すべきポイント:
HttpOnlyが付いているか（JavaScriptからアクセスできないようになっているか）Secureが付いているか（HTTPS限定で送信されるか）SameSiteの値が適切か（CSRF対策が有効か）Expires / Max-Ageが適切か（セッション切れのタイミング）
curlでヘッダーを確認する
ブラウザを介さずにヘッダーを確認したいときは、curl -v が便利です。
# -v でリクエスト/レスポンスヘッダーを表示
curl -v https://api.example.com/users
# 特定のヘッダーを付けてリクエスト
curl -H "Authorization: Bearer YOUR_TOKEN" \
-H "Content-Type: application/json" \
https://api.example.com/users
# レスポンスヘッダーだけ確認（ボディは不要）
curl -I https://api.example.com/userscurl -v の出力で > がリクエスト、< がレスポンスのヘッダーです。APIの動作確認やデバッグで頻繁に使います。
まとめ
- HTTPメッセージは スタートライン + ヘッダー + ボディ で構成される
Content-Typeはボディの解釈方法を伝える重要なヘッダーCache-Controlでキャッシュの有無と期間を制御する。no-cacheとno-storeの意味は違う- Cookie はサーバーがブラウザに状態を保持させる仕組み。セッション管理の基盤
- セッションCookieには HttpOnly + Secure + SameSite を必ず設定する
次の章では、Web APIの設計パターンとして最も普及している REST API の考え方と命名規則を見ていきます。