# Cookie

クッキー(Cookie)は、HTTPプロトコルにおいて、サーバーがクライアント(通常はWebブラウザ)に送信し、クライアント側で保存される小さなデータのことを指します。クッキーは、ユーザーのセッション管理、個人設定の保存、トラッキングなど、さまざまな目的で使用されます。

```{note}
なぜに『クッキー』という名前?

クッキーの名前の由来は、コンピュータサイエンスの分野で使われる「magic cookie」という概念に由来しています。Magic cookieは、システム間で情報を交換するために使用される小さなデータの断片を指します。この用語は、1970年代に開発されたUNIXシステムで使われ始めました。
```

## クッキーの仕組み

クッキーは、HTTPレスポンスヘッダーの一部としてサーバーからクライアントに送信されます。クライアントはこのクッキーを保存し、後のリクエストで同じサーバーに対して送信します。これにより、サーバーはクライアントを識別し、状態を維持することができます。

クッキーは『サーバー側で生成されている』ことに注意してください(クライアント側では生成されません)。
これはクッキー自体はサーバー側で保存されており、クライアント側と共有する関係になります。
クッキーの内容は、HTTPのレスポンスヘッダーによりクライアントに送信されます。

```{mermaid}
sequenceDiagram
    participant Client as クライアント
    participant Server as サーバー
    Client->>Server: HTTPリクエスト
    Server->>Client: HTTPレスポンス(Set-Cookieヘッダー付き)
    Client-->>Client: クッキー保存
```

クッキーは、以下のような情報を含みます。

- 名前と値のペア: クッキーの基本的な情報
- 有効期限: クッキーが有効である期間
- ドメインとパス: クッキーが送信される対象のドメインとパス
- セキュリティ属性: クッキーのセキュリティに関する設定(例: Secure, HttpOnly)
- SameSite属性: クロスサイトリクエストフォージェリ(CSRF[^csrf])攻撃を防ぐための設定


[^csrf]: CSRF(Cross-Site Request Forgery)攻撃は、悪意のあるウェブサイトがユーザーのブラウザを利用して、ユーザーが認証されている別のウェブサイトに対して不正なリクエストを送信させる攻撃手法です。これにより、ユーザーの意図しない操作が行われる可能性があります。

## クッキーを受け取ったら

ブラウザ等のクライアントは、クッキーをサーバーから受け取ることがあります。
この時受け取ったクッキーについて **必ずしも保存する必要はありません** 。
保存するかどうかはクライアント側の実装次第です。

- 保存した場合、次回以降の同じドメインへのリクエストに対して、保存したクッキーを送信します。
- 保存しなかった場合、次回以降のリクエストに対してクッキーは送信されません(というか送るものが無い)。

また、クッキーには賞味期限(正しくは『有効期限』)が設定されている場合があります。これにより、クライアントはその期限が過ぎたクッキーを自動的に削除することがあります。

## セッションクッキー

セッションクッキー(Session Cookie)は、ブラウザのセッションが終了するまで(通常はブラウザを閉じるまで)有効なクッキーのことを指します。セッションクッキーは、ユーザーがウェブサイトを訪れている間に一時的に情報を保存するために使用されます。セッションクッキーは、ブラウザのメモリーに保存されるのみです。ストレージに永続記憶されることはありません(仮想記憶にスワップアウトされる可能性はあります)。

セッションクッキーは、ユーザーがウェブサイトを離れたり、ブラウザを閉じたりすると自動的に削除されます。これにより、ユーザーのプライバシーが保護され、不要なデータが長期間保存されることを防ぎます。

## セキュアクッキー

セキュアクッキー(Secure Cookie)は、HTTPS接続を通じてのみ送信されるクッキーのことを指します。セキュアクッキーは、インターネット上でのデータの盗聴や改ざんを防ぐために使用されます。セキュアクッキーは、クッキーの属性として「Secure」を設定することで実現されます。平文(HTTP)においては送信されませんし、生成するようなものでもありません。
クッキー自体の扱い(永続記憶に保存されるかされないか)は通常のクッキーと変わりません。

## クッキーの配信元と受容について

クッキーには、配信元がどこからかという観点で大きく2つに分類できます。

- ファーストパーティクッキー(First-Party Cookie)
- サードパーティクッキー(Third-Party Cookie)

### ファーストパーティクッキー

ファーストパーティークッキーは、ユーザーが直接訪れているウェブサイト(ドメイン)から発行されるクッキーのことを指します。例えば、ユーザーが`example.com`にアクセスした際に、そのドメインから発行されるクッキーはファーストパーティクッキーとなります。
一般的にファーストパーティクッキーは、ユーザーのセッション管理や個人設定の保存など、ウェブサイトの基本的な機能を提供するために使用されており、多くのブラウザは(設定にも依りますが)ファーストパーティクッキーを許可しています。必要に応じて保存され、次回以降の同じドメインへのリクエストに対して送信されます。

### サードパーティクッキー

サードパーティクッキーは、ユーザーが訪れているウェブサイトとは異なるドメインから発行されるクッキーのことを指します。例えば、ユーザーが`example.com`にアクセスした際に、そのページに埋め込まれた広告やトラッキングスクリプトが`adnetwork.com`などの別のドメインから発行するクッキーはサードパーティクッキーとなります。
サードパーティクッキーは、主に広告配信やユーザー行動のトラッキングなど、マーケティング目的で使用されることが多いです。しかし、プライバシーの観点からサードパーティクッキーの使用には批判も多く、近年では多くのブラウザがサードパーティクッキーの制限やブロックを強化しています。ユーザーの設定によっては、サードパーティクッキーが保存されない場合もあります。

### サードパーティクッキーとブラウザ

```{note}
2025年現在の情報となります。
```

主要なブラウザにおけるサードパーティクッキーの扱いは以下の通りです。

| ブラウザ       | サードパーティクッキーの扱い                           |
|----------------|------------------------------------------------------|
| Google Chrome  | 保存されています(ブロックも可能)。 |
| Mozilla Firefox| デフォルトでサードパーティクッキーをブロック。               |
| Apple Safari   | デフォルトでサードパーティクッキーをブロック。               |
| Microsoft Edge  | Google Chromeと同様。   |

Google Chromeは2024年にサードパーティクッキーのサポートを終了する計画を発表していましたが、2025年現在でも引き続きサポートしています。
これはサードパーティクッキーが依然として広告を中心に広く使われているためです(自身のサービスでも広告が収入源のひとつであり、それを失うことは否定的です)。
Microsoft Edgeは現在はGoogle Chromeと同様の扱いですが、将来的にはサードパーティクッキーのサポートを終了する可能性があります。

現状のサードパーティクッキーは主に広告配信のために使われていることも多く、利用者側からはあまり歓迎されていません。
そのため、今後はサードパーティクッキーの利用がさらに制限される可能性があります。

なおGoogleは一時期、FLoC(Federated Learning of Cohorts)というサードパーティクッキーに代わる技術を提案していましたが、プライバシーの観点から批判が多く、2023年にこの計画を中止しています。

## プログラム上で扱ってみる

プログラム上でクッキーを扱う場合、各種プログラミング言語でHTTPのサポートがあればおおむねクッキーも扱うことができます。
たとえばPythonであれば、`http.cookies`モジュールを使うことでクッキーの生成や解析が可能です。

たとえば、flaskを使った簡単なWebアプリケーションでクッキーを設定し、取得する例を示します。
これは以前のFlaskのサンプルにクッキーを用いたカウンターを追加したものとなっています[^app-file]。

```{literalinclude} src/api/app-with-cookie.py
:caption: Flaskを使った簡単なWebアプリケーションでクッキー
:diff: src/api/app.py
:language: python
:name: app.py
```

[^app-file]: [src/api/app-with-cookie.py](src/api/app-with-cookie.py) ※このファイルは`src/api/app.py`をベースにクッキーを追加したものです。

このコードを実行し、別端末で `curl` を使ってアクセスしてみると、クッキーが追加されていることがわかります。

```{code-block}
:language: shell
:emphasize-lines: 7

$ curl -I http://localhost:5000/counter
HTTP/1.1 200 OK
Server: Werkzeug/3.1.3 Python/3.13.7
Date: Wed, 17 Sep 2025 06:44:09 GMT
Content-Type: application/json
Content-Length: 19
Set-Cookie: counter=1; Expires=Thu, 18 Sep 2025 06:44:09 GMT; Max-Age=86400; Path=/
Connection: close
```

`Set-Cookie`ヘッダーにより、`counter`という名前のクッキーが設定されていることがわかります。
逆にクッキーの送信もしてみましょう。

```{code-block}
:language: shell
:emphasize-lines: 7

$ curl -I --cookie "counter=5" http://localhost:5000/counter
HTTP/1.1 200 OK
Server: Werkzeug/3.1.3 Python/3.13.7
Date: Wed, 17 Sep 2025 06:45:52 GMT
Content-Type: application/json
Content-Length: 19
Set-Cookie: counter=6; Expires=Thu, 18 Sep 2025 06:45:52 GMT; Max-Age=86400; Path=/
Connection: close
```

5を送ったことにより、その値を使って1増えた、6が返っています。

## クッキーのセキュリティ

クッキーは便利な機能ですが、セキュリティ上のリスクも伴います。以下に、クッキーに関連する主なセキュリティリスクとその対策を示します。

- **セッションハイジャック**: 攻撃者がユーザーのクッキーを盗み取り、そのユーザーになりすます攻撃です。対策として、クッキーに`HttpOnly`属性を設定し、JavaScriptからアクセスできないようにすることが有効です。
- **クロスサイトスクリプティング(XSS)**: 攻撃者が悪意のあるスクリプトをウェブページに挿入し、ユーザーのクッキーを盗む攻撃です。対策として、クッキーに`HttpOnly`属性を設定し、JavaScriptからアクセスできないようにすることが有効です。
- **クロスサイトリクエストフォージェリ(CSRF)**: 攻撃者がユーザーのクッキーを利用して、ユーザーが意図しないリクエストを送信させる攻撃です。対策として、クッキーに`SameSite`属性を設定し、クロスサイトリクエストでクッキーが送信されないようにすることが有効です。
- **盗聴**: クッキーが平文で送信される場合、攻撃者が通信を傍受してクッキーを盗む可能性があります。対策として、クッキーに`Secure`属性を設定し、HTTPS接続を通じてのみ送信されるようにすることが有効です。
- **クッキーの改ざん**: 攻撃者がクッキーの内容を変更し、不正な情報をサーバーに送信する可能性があります。対策として、クッキーの内容を暗号化したり、署名を付与したりすることが有効です。
- **不要なクッキーの削除**: クッキーが不要になった場合、適切に削除することが重要です。これにより、攻撃者が古いクッキーを利用して攻撃するリスクを減らすことができます。

## クッキーを確認するには?

ブラウザでは、開発者ツール({kbd}`F12`キー)を使うことで、クッキーの内容を確認できます。
たとえばGoogle Chromeの場合、`アプリケーション(Application)`タブを選択し、ストレージカテゴリの中にあるCookieで、発行元とクッキーの一覧が確認できます。
図は[X](https://x.com)の例です。

```{figure} images/browser-cookie.png
:width: 75%

クッキーの表示例(開発者ツール)
```