ブラウザクッキー徹底解説:仕組み・属性・種類・実装とセキュリティ・プライバシー対策

ブラウザクッキーとは

ブラウザクッキー(以下「クッキー」)は、ウェブサイトがユーザーのブラウザに小さなデータ(名前=値ペア)を保存し、次回以降のリクエストでそのデータを参照できる仕組みです。ユーザーのログイン状態の維持、言語・表示設定の保存、ショッピングカートの管理、アクセス解析や広告のための識別子などに広く使われています。技術的にはサーバーがHTTPレスポンスにSet-Cookieヘッダーを付けて発行し、ブラウザはその情報を保存して、該当するドメイン/パスへの次回リクエスト時にCookieヘッダーとして送信します。

クッキーの仕組み(HTTPとブラウザの観点)

基本的な流れ:

  • サーバーがレスポンスに Set-Cookie: name=value; 属性 を付けて送信。
  • ブラウザは属性(Expires/Max-Age、Domain、Path、Secure、HttpOnly、SameSite 等)に従って保存する。
  • 保存されたクッキーは、Domain/Path の条件に合致するリクエストに対して、自動的に Cookie ヘッダーとして送信される。

例(HTTPヘッダ):

Set-Cookie: sessionId=abc123; Path=/; Domain=example.com; Max-Age=3600; Secure; HttpOnly; SameSite=Lax

主要な属性の説明

  • Expires / Max-Age: 永続クッキーの存続期間を指定。Expires は日時指定、Max-Age は秒数。どちらかが使われ、なければセッションクッキー(ブラウザ終了で削除)になる。
  • Domain: クッキーを送る対象のドメイン範囲を指定。省略時はホストのみ(ホスト限定)。
  • Path: リクエストパスがこのパスの下にある場合のみクッキーを送信。
  • Secure: HTTPS 接続時のみクッキーを送信(平文HTTPでは送られない)。
  • HttpOnly: JavaScript(document.cookie)からのアクセスを禁止。XSS による盗難をある程度防ぐ。
  • SameSite: クロスサイト送信の制御(Strict, Lax, None)。CSRF 対策や第三者トラッキングの抑制に使われる。None を指定する場合は Secure が必須。
  • Prefix(__Host- や __Secure-): ブラウザ側が導入した命名ルールで、セキュリティ強化のための制約が付く。例えば __Host- は Domain を付けられず Path=/、Secure 必須、など。

クッキーの種類

  • セッションクッキー(Session cookie): ブラウザのセッション中のみ有効で、ブラウザを閉じると削除される(Expires/Max-Age が設定されていないもの)。
  • 永続クッキー(Persistent cookie): 有効期限が設定され、ブラウザを閉じても保持される(ログイン情報など)。
  • ファーストパーティクッキー: ページをホストするドメインが発行したクッキー。通常はサイト機能の維持に使われる。
  • サードパーティクッキー: ページ内の別ドメイン(広告やトラッキングサービスなど)が発行するクッキー。クロスサイト追跡に使われることが多く、近年ブラウザや規制で制限されつつある。

実装例(サーバーとクライアント)

Set-Cookie ヘッダーの例(永続セッション):

HTTP/1.1 200 OK
Set-Cookie: session=eyJ...; Path=/; Max-Age=604800; Secure; HttpOnly; SameSite=Lax

JavaScriptでの読み書き(HttpOnly でないクッキーのみ):

// 書き込み
document.cookie = "theme=dark; path=/; max-age=31536000";
// 読み込み
console.log(document.cookie); // "theme=dark; other=.."
// 削除(有効期限を過去にする)
document.cookie = "theme=; path=/; max-age=0";

サイズ・数の制限とパフォーマンス

RFC自体は明確な数を標準化していませんが、一般的なブラウザ実装ではクッキー1個あたり約4KB(4096バイト)程度、1ドメインあたりのクッキー数に上限(多くのブラウザでおよそ50個前後)が設定されています。クッキーは該当ドメインへの全てのHTTPリクエストに付与されるため、過度に大きなクッキーは帯域とレイテンシを悪化させます。サーバー側・クライアント側ともに、クッキーには不要なデータを入れないことが重要です。

セキュリティとプライバシー上の懸念

  • XSS(クロスサイトスクリプティング): 悪意あるスクリプトにより document.cookie を取得されるリスク。HttpOnly を使うことで JavaScript からの読み取りを防げる。
  • CSRF(クロスサイトリクエストフォージェリ): ブラウザが自動的にクッキーを送る性質を悪用して偽のリクエストを送り、認証済み状態で操作させる攻撃。SameSite 属性や CSRF トークンの導入で対策。
  • トラッキング・プライバシー: サードパーティクッキーはユーザー行動の追跡に使われる。各ブラウザ(Safari の ITP、Firefox の ETP、Chrome の段階的制限)や規制(GDPR、ePrivacy)により制限の方向にある。
  • Cookie シンク(cookie syncing)やフィンガープリンティング: 複数の識別子を結びつけて追跡精度を高める手法があり、プライバシー上の懸念が強い。

ブラウザ側の対応と規制動向(概要)

近年、プライバシー保護の観点から主要ブラウザはサードパーティクッキーの扱いを厳しくしています。Apple Safari の Intelligent Tracking Prevention(ITP)や Mozilla Firefox の Enhanced Tracking Protection(ETP)はサードパーティトラッキングを抑制します。Google Chrome も段階的にサードパーティクッキーの扱いを見直し、Privacy Sandbox(代替のプライバシー保護機構)を展開しています(各ブラウザの対応は随時更新されるため、最新の公式情報を参照してください)。また、EU の GDPR や ePrivacy 規制により、利用目的や同意取得に関する法的要件がある点にも注意が必要です。

クッキーを使う/置き換える際の代替技術

  • localStorage / sessionStorage: クライアントサイドにキー・バリューを保存。帯域に影響しないが、HttpOnly が使えないため XSS に弱い。送信は明示的に行う必要がある。
  • IndexedDB: 大量データをクライアントに保存する用途に向く。セキュリティモデルは localStorage と同様。
  • トークンベース認証(JWT など): Authorization ヘッダーで送る方式はクッキーとは別の利点(API と親和性が高い)。ただし、XSS による露出リスクやトークンの安全な保管が課題。
  • Privacy Sandbox やファーストパーティベースのソリューション: ブラウザ提供のプライバシー保護機構で、サードパーティクッキーに代わる仕組みを目指す取り組み。

開発者向けベストプラクティス

  • 敏感情報(パスワード、クレジットカード等)はクッキーに平文で保存しない。
  • 認証セッションには Secure と HttpOnly を付与する。可能なら SameSite=Lax/Strict を利用して CSRF リスクを下げる。
  • __Host-、__Secure- プレフィクスの活用を検討する(要件に従う)。
  • クッキーサイズと数を最小限にし、帯域負荷を抑える。
  • CSRF 対策は SameSite だけに頼らず、トークンベースの検証も組み合わせる。
  • サードパーティクッキーに依存しない設計(ファーストパーティで完結する仕組み)を検討する。
  • プライバシー方針と同意取得(Cookie 同意)に関する法的要件を遵守する。

ユーザーとしての操作(確認・削除・設定)

主要ブラウザの開発者ツールでクッキーを確認・編集・削除できます(Chrome DevTools > Application > Cookies 等)。ユーザーはブラウザ設定からサイトごとのクッキー削除やサードパーティクッキーの拒否、シークレットモードでの利用などを選べます。注意点として、サイトの動作に必須なファーストパーティクッキーを削除するとログイン状態や設定が失われる可能性があります。

まとめ

クッキーはウェブの基本的機能として長く使われてきた仕組みで、利便性と同時にセキュリティ・プライバシー上の課題も抱えています。開発者は属性(Secure, HttpOnly, SameSite 等)を正しく設定し、不要な情報を保存しない、サードパーティへの過度な依存を避けるなどの配慮が必要です。さらに、ブラウザのプライバシー強化や法規制の変化を注視し、ユーザーの同意管理や代替技術の採用を検討することが重要です。

参考文献