【実務・中級編】HTTP/1.1におけるCookieとSet-Cookieヘッダー – HTTPプロトコル・通信規格実践ガイド

HTTPという「記憶喪失」との戦い：Cookieという名のバールのようなもの

Webの世界は、本来極めて冷淡だ。HTTPというプロトコルそのものが「ステートレス」――つまり、リクエストを投げたら投げっぱなし。サーバーは「さっきのリクエストを送ってきた奴と、今のアドレスは同一人物か？」なんてことは一切気にしない設計になっている。

しかし、ログイン状態を維持し、カートの中身を保持しなければならない我々のWebアプリケーションにとって、この「記憶喪失」は致命的だ。そこで登場するのがCookieである。今回は、Webインフラの現場で「なぜか認証が通らない」「XSSでセッションが抜かれた」といった泥沼に陥らないための、Cookieの深淵を紐解いていこう。

1. 舞台裏のシーケンス：Set-CookieとCookieの往復

Cookieの仕組みは驚くほどシンプルだが、そのシンプルさゆえに実装上の甘さが出やすい。

1. サーバーからの指示 (`Set-Cookie`): サーバーが認証成功時に、レスポンスヘッダーに `Set-Cookie` を付与する。
2. ブラウザの記憶: ブラウザはそれを受け取り、ドメイン単位でローカルストレージ（あるいはメモリ）に保存する。
3. クライアントからの提示 (`Cookie`): 次回以降、ブラウザは同一ドメインへのリクエストの際、自動的に `Cookie` ヘッダーとしてサーバーへ再送する。

このやり取りは、いわば「サーバーが発行した通行手形」だ。しかし、この通行手形が誰の手に渡ってもいいのか、あるいはどの範囲で通用するのかを定義しないと、セキュリティという名の城はあっという間に崩落する。

2. 現場で必須の「3つの盾」：Secure, HttpOnly, SameSite

RFC 6265を眺めるのも良いが、現場のインフラエンジニアとして、まずはこの3つの属性を叩き込んでほしい。これらはオプションではない。「必須」だ。

Secure: 「HTTPS以外では送信するな」。これを付け忘れると、平文のHTTP通信でセッションIDが漏洩し、パケットキャプチャ一発で乗っ取られる。
HttpOnly: 「JavaScriptから触らせるな」。これを設定しないと、クロスサイトスクリプティング（XSS）攻撃を受けた際、攻撃者が `document.cookie` でセッション情報を簡単に抜き出せてしまう。
SameSite: 「クロスサイトでの送信を制限しろ」。CSRF（クロスサイトリクエストフォージリ）対策の要だ。`Strict` または `Lax` が現代のデファクトスタンダードである。

3. 実践：curlとブラウザでのデバッグ手法

トラブルシューティングの際、ブラウザのデベロッパーツール（F12）に頼りすぎるのは危険だ。まずは `curl` で生のヘッダーを確認する癖をつけよう。

curlでヘッダーのみを確認するコマンド
-I: ヘッダーのみ取得
-v: 詳細な通信ログ（Verbose）を表示
curl -Iv https://example.com/login

もし、Cookieが正しく送られているか確認したいなら、以下のようにリクエストをエミュレートする。

特定のCookieを付与してリクエストを投げる
curl -v -H “Cookie: session_id=abc123xyz; secure_token=xyz789” https://api.example.com/profile

4. Web API設計における実装例（Python/Flask）

バックエンドで `Set-Cookie` を発行する際の、推奨される記述例だ。

from flask import Flask, make_response

app = Flask(__name__)

@app.route(‘/login’)
def login():
resp = make_response(“ログイン成功”)

# セキュリティ属性をフル装備したCookie設定
resp.set_cookie(
‘session_id’,
‘secret_value_12345′,
max_age=3600, # 有効期限: 1時間
secure=True, # HTTPS通信のみ許可
httponly=True, # JSからのアクセスを遮断
samesite=’Lax’ # CSRF対策: 同一サイト遷移時は許可、外部からの埋め込みは拒否
)
return resp

5. 運用上の「落とし穴」

最後に、ベテランが一度は踏み抜く落とし穴を共有しておく。

Cookieのサイズ制限: 4KBという制限がある。JSONをそのままCookieに詰め込むエンジニアを見かけるが、すぐに溢れる。あくまでセッションIDの「鍵」として使い、実データはRedis等のバックエンド側に持たせるのが鉄則だ。
パスの指定: `Path=/` を忘れると、特定のサブディレクトリでしかCookieが有効にならないケースがある。APIのドメイン設計と合わせる必要がある。
ドメインのスコープ: `Domain=.example.com` とすると、サブドメインにもCookieが漏れ出す。原則として指定せず、デフォルトの挙動に任せるのが安全だ。

まとめ：ネットワークは「疑う」ことから始まる

HTTP/1.1の時代から現代のHTTP/3に至るまで、Cookieという仕組みは形を変えずに生き残っている。しかし、その背後にある脅威のレベルは桁違いに上がっている。

「とりあえず動く」コードを書くのは簡単だ。だが、プロフェッショナルは「なぜこの属性が必要なのか？」「もしXSSが起きたら、この設定で守り切れるか？」と自問自答する。パケットは嘘をつかない。君が設定したCookieが、通信のたびにどう振る舞っているか――それを想像できるエンジニアこそが、真に信頼されるインフラ・アーキテクトだ。

現場で躓いたら、まずはパケットをキャプチャし、ヘッダーを眺めろ。答えは必ずそこにある。