【入門編】HTTP/1.1のCookie管理(Set-Cookie, Cookieヘッダー) – HTTPプロトコル・通信規格実践ガイド

はい、承知いたしました。HTTP/1.1のCookie管理について、インフラやネットワークの初学者の方にも分かりやすく、身近な例えを交えながら解説するブログ記事を執筆します。パケットやヘッダーの専門用語は極力避け、実務で役立つ情報もしっかり盛り込みますね。

—

HTTPの「記憶力」を支える魔法の箱：Cookieの秘密を解き明かす！

こんにちは！ネットワークの世界を旅する皆さん、今回はHTTPプロトコルのちょっとした「秘密」に迫りたいと思います。HTTPって、実は「ステートレス」、つまり「記憶力がない」って知ってましたか？でも、私たちが普段Webサイトを見ていると、ログイン状態が維持されていたり、カートに入れた商品が消えなかったりしますよね。あれ、どうやって実現してるんだろう？って不思議に思ったことはありませんか？

その秘密を解き明かす鍵こそが、今日お話しする「Cookie」なんです！ Cookieって聞くと、ついあの美味しいお菓子を想像しちゃいますが、Webの世界では全然違う役割を担っているんですよ。

今回は、HTTP/1.1の時代からWebの「記憶力」を支えてきたCookieの基本から、ちょっと複雑だけどとっても重要な「属性」まで、皆さんと一緒に一歩ずつ、優しく紐解いていきましょう！

HTTPって、なんで記憶力がないの？郵便配達さんに例えてみよう！

まず、HTTPがなぜ「ステートレス」なのか、身近な例で考えてみましょう。

想像してみてください。あなたは、あるお店に何度も郵便を出すとします。そのお店は、あなたのことを毎回初めてのお客さんだと思って、毎回「お名前は？」「ご住所は？」と聞いてくるんです。ちょっと面倒くさいですよね？

HTTPもこれと似ています。Webサイトにアクセスするたびに、サーバーは「この人、誰だっけ？」と毎回ゼロから関係を築こうとします。前回のアクセス情報なんて、何も覚えていないんです。これが「ステートレス」な状態です。

でも、これではログイン状態の維持や、ショッピングカートの管理など、ユーザーごとの状態を管理するのがすごく難しくなってしまいます。そこで登場するのがCookieという「記憶を助ける仕組み」なのです！

Cookieって、一体何者？サーバーからの「お土産」

Cookieは、WebサーバーがWebブラウザ（皆さんが使っているChromeやSafariなどのことですね）に「ちょっとこれを覚えておいてね」と渡す、小さな情報のことです。まるで、お店に行った時に「次回来店時に使える割引券」や「会員証」をもらうようなイメージです。

この「お土産」は、ブラウザの中に大切に保管されます。そして、次に同じWebサイトにアクセスする時には、ブラウザはサーバーに「以前もらったこのお土産、持ってきたよ！」と、一緒に渡してくれるんです。

これにより、サーバーは「ああ、この人、以前も来たことがある人だ」「この人は会員だったな」ということを思い出せるようになり、ユーザーごとの状態を維持できるというわけです。

Cookieのやり取りは、こんな感じ！

1. ブラウザがサーバーにアクセス

「このサイト（例: `example.com`）を見せて！」とお願い。

2. サーバーがお客さん（ブラウザ）に「お土産」を渡す

「はい、これ会員証（Cookie）ね。次回来た時に見せてね。」
この「お土産」は、HTTPのレスポンス（サーバーからの返信）に乗ってブラウザに届きます。具体的には、`Set-Cookie` というヘッダー（通信の際の「付箋」のようなもの）で渡されることが多いです。

3. ブラウザがお土産を保管

ブラウザは、もらった会員証（Cookie）を、どこのお店（ドメイン）のものかを覚えて、大切に保管します。

4. ブラウザが再びサーバーにアクセス

「会員証（Cookie）持ってきたよ！」と、前回のアクセスで受け取ったお土産（Cookie）を、HTTPのリクエスト（ブラウザからサーバーへのお願い）に乗せて送ります。

5. サーバーがお土産を見て、お客さんを識別

「おお、会員証ね！よく来たね。ログイン状態を維持しよう。」

このように、Cookieはサーバーとブラウザの間で「お土産のやり取り」をすることで、HTTPのステートレスな性質を補っているのです。

Cookieの「お土産」には、どんな情報が入っているの？

Cookieに具体的にどんな情報が入っているかは、Webサイトによって様々ですが、代表的なものとしては以下のようなものがあります。

セッションID: ログイン状態を維持するために使われる、一時的な識別子。
ユーザー設定: 表示言語、テーマ（ダークモードかライトモードかなど）の設定。
ショッピングカート情報: カートに入れた商品のリスト。

これらの情報は、サーバーが「このブラウザは、こういう状態なんだな」と判断するための手助けをしてくれます。

HTTP/1.1でのCookieのやり取り：ヘッダーを見てみよう！

HTTP/1.1では、Cookieのやり取りは主に以下の2つのヘッダーで行われます。

1. `Set-Cookie` ヘッダー：サーバーからブラウザへのお土産渡し

サーバーがブラウザにCookieを渡すときに使われるのが、`Set-Cookie` ヘッダーです。これは、HTTPのレスポンスに含まれます。

HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: session_id=abcdef1234567890; Path=/; Expires=Wed, 21 Oct 2025 07:28:00 GMT; HttpOnly; Secure
Set-Cookie: user_preference=dark_mode; Path=/; Max-Age=31536000

… (HTMLコンテンツ) …

ちょっと難しそうに見えますが、一つずつ見ていきましょう！

`session_id=abcdef1234567890`: これが「お土産」の本体です。「セッションID」という名前で、「abcdef1234567890」という値が設定されています。
`Path=/`: このCookieが、どのパス（URLの `/` より後の部分）で有効かを示します。`/` は、サイトのルートディレクトリ以下すべてで有効という意味です。
`Expires=Wed, 21 Oct 2025 07:28:00 GMT`: このCookieがいつまで有効か（有効期限）を示します。この例では、2025年10月21日まで有効です。
`Max-Age=31536000`: こちらも有効期限を示す方法の一つです。秒数で指定され、この例では31,536,000秒＝1年間有効という意味になります。`Expires` と `Max-Age` の両方が指定されている場合は、`Max-Age` が優先されることが多いです。
`HttpOnly`: これはCookieの「属性」の一つで、後ほど詳しく解説しますね！
`Secure`: これもCookieの「属性」で、これも後ほど詳しく解説します。

2. `Cookie` ヘッダー：ブラウザからサーバーへの「お土産」提示

ブラウザが、以前サーバーからもらったCookieをサーバーに送り返すときに使われるのが、`Cookie` ヘッダーです。これは、HTTPのリクエストに含まれます。

GET /mypage HTTP/1.1
Host: example.com
Cookie: session_id=abcdef1234567890; user_preference=dark_mode
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36

…

`session_id=abcdef1234567890`: サーバーから受け取った `session_id` をそのまま返しています。
`user_preference=dark_mode`: こちらも、受け取った `user_preference` を返しています。

このように、ブラウザはサーバーから受け取ったCookieを、次回以降のリクエストで自動的に送信してくれるんです。

Cookieに設定できる、ちょっと特別な「属性」たち

さて、先ほど `Set-Cookie` ヘッダーの例で出てきた `HttpOnly` や `Secure` ですね。これらは、Cookieをより安全に、そして効果的に使うための「属性」と呼ばれるものです。一つずつ見ていきましょう！

属性①：`HttpOnly` ～ JavaScriptからのいたずらを防ぐ！

`HttpOnly` 属性が付いているCookieは、JavaScriptからアクセスできなくなります。

なぜこれが重要かというと、悪意のあるJavaScriptコード（クロスサイトスクリプティング攻撃、XSSと呼ばれるものです）がブラウザに仕掛けられた場合、本来はブラウザのJavaScriptからCookieを盗み見ることができてしまうからです。

例えば、ログイン情報などが保存されているCookieに `HttpOnly` が付いていれば、たとえ悪意のあるJavaScriptが実行されてしまっても、そのJavaScriptはそのCookieを読み取ることができません。これにより、セッションハイジャック（他人のログイン状態を乗っ取る行為）のリスクを減らすことができるんです。

【実務でのポイント】
ログイン情報や重要なセッションIDを保存するCookieには、必ず `HttpOnly` 属性を付けるようにしましょう！

属性②：`Secure` ～通信の安全を守る！

`Secure` 属性が付いているCookieは、HTTPS（暗号化された通信）でしか送信されなくなります。

HTTP通信は、通信内容が暗号化されていないため、途中で第三者に傍受されてしまう可能性があります。もし、`Secure` 属性が付いていないCookieに機密情報が含まれていた場合、それを盗み見られてしまう危険性があります。

`Secure` 属性を付けておけば、たとえHTTPでアクセスされたとしても、そのCookieは送信されません。したがって、常に暗号化されたHTTPS通信でやり取りされることになり、通信の安全性が高まります。

【実務でのポイント】
機密情報を含むCookieや、ログイン状態を示すCookieには、必ず `Secure` 属性を付けるようにしましょう！最近のWebサイトでは、ほとんどのCookieに `Secure` 属性が付いているはずです。

属性③：`SameSite` ～他サイトからの「なりすまし」を防ぐ！

`SameSite` 属性は、比較的新しい属性ですが、Webサイトのセキュリティを向上させる上で非常に重要な役割を果たしています。これは、ブラウザがCookieをどのサイトからのリクエストに含めるかを制御するためのものです。

`SameSite` 属性には、主に以下の3つの値があります。

`Strict`:
最も厳格な設定です。
同じサイト（ドメイン）からのリクエストにしかCookieは送信されません。
例えば、`example.com` のCookieに `SameSite=Strict` が付いている場合、他のサイト（例: `evil.com`）から `example.com` のページにリンクされていても、そのリンクをクリックして `example.com` に遷移したとしても、Cookieは送信されません。
これにより、CSRF（クロスサイトリクエストフォージェリ）攻撃（悪意のあるサイトが、ユーザーを騙して意図しない操作をさせる攻撃）を防ぐ効果があります。
`Lax`:
`Strict` よりも少し緩やかな設定です。
トップレベルナビゲーション（ユーザーが直接クリックしたり、URLを打ち込んだりして遷移する場合）や、安全なHTTPメソッド（GETなど）のリクエストであれば、Cookieが送信されます。
例えば、`evil.com` から `example.com` へのリンク（GETリクエスト）をクリックして遷移した場合、`example.com` のCookieは送信されます。しかし、`evil.com` が `example.com` に対して `POST` リクエスト（フォーム送信など）を勝手に行うような場合には、Cookieは送信されません。
多くのブラウザで、`SameSite` 属性が指定されていない場合のデフォルト値となっています。
`None`:
どのサイトからのリクエストに対してもCookieが送信されるようになります。
ただし、`SameSite=None` を指定する場合は、必ず `Secure` 属性も同時に指定する必要があります。これは、`None` の設定は、クロスサイトでのCookie送信を許可する代わりに、通信の安全性を必須とするためです。
外部サイトに埋め込まれたコンテンツ（iframeなど）で、そのサイトのCookieが必要な場合などに使われます。

【実務でのポイント】
CSRF攻撃対策として、`SameSite` 属性は非常に有効です。

ログイン状態の維持など、サイト内でのみ利用するCookieや、CSRF攻撃のリスクが高い操作（POSTリクエストなど）に関わるCookieには、`Strict` または `Lax` を指定するのがおすすめです。
外部サイトとの連携で、どうしてもクロスサイトでのCookie送信が必要な場合にのみ `None` を指定し、その際は必ず `Secure` 属性も忘れないようにしましょう。

まとめ：CookieはWebの「記憶」を支える賢い仕組み

いかがでしたでしょうか？ Cookieが、HTTPのステートレスな性質を補い、私たちが快適にWebサイトを利用するために、いかに重要な役割を果たしているかがお分かりいただけたかと思います。

Cookie: Webサーバーがブラウザに渡す「お土産」のような情報。
`Set-Cookie` ヘッダー: サーバーからブラウザへCookieを渡すときに使われる。
`Cookie` ヘッダー: ブラウザからサーバーへ、持っているCookieを提示するときに使われる。
`HttpOnly` 属性: JavaScriptからのCookieへのアクセスを禁止し、XSS攻撃を防ぐ。
`Secure` 属性: HTTPS通信時のみCookieを送信し、通信の安全性を高める。
`SameSite` 属性: 他サイトからのリクエストでCookieを送信するかどうかを制御し、CSRF攻撃を防ぐ。

これらの仕組みを理解することで、Webサイトのセキュリティや、より安全な開発・運用に繋がるはずです。

今回お話しした内容は、Web開発やインフラの現場で日々使われている、とても基本的ながらも強力な技術です。ぜひ、皆さんの開発やデバッグの際に、これらの知識を役立ててみてくださいね！

また次回、ネットワークの面白い世界でお会いしましょう！