永続クッキーとは何か？基本定義・仕組み・属性・実装のベストプラクティスと法規制を徹底解説

2025年11月20日 最終更新日時 : 2025年11月20日 エバープレイ編集部

永続クッキーとは — 基本定義とセッションクッキーとの違い

永続クッキー（persistent cookie）は、Webブラウザがクライアント側（ユーザーの端末）に保存する小さなデータ断片で、その有効期限（ExpiresまたはMax-Age）を設定してブラウザを閉じた後も残るものを指します。対照的に、セッションクッキー（session cookie）はブラウザを閉じると消える一時的なクッキーです。永続クッキーは「再ログインを省く」「ユーザー設定の保存」「トラッキングや分析」などの目的で使われます。

技術的な仕組み

クッキーはHTTPレスポンスヘッダの Set-Cookie によりサーバがブラウザに指示して作成します。クライアント側では、ブラウザがキー＝値のペアと属性（Expires / Max-Age, Domain, Path, Secure, HttpOnly, SameSite など）を保存します。有効期限が設定されている場合、ブラウザはその期限までクッキーを保持し、該当するリクエスト（ドメイン・パス・プロトコル条件に合うもの）に対して Cookie ヘッダで自動送信します。

例：HTTPヘッダで永続クッキーを設定する例

Set-Cookie: remember_me=abcdef123456; Max-Age=2592000; Path=/; Domain=example.com; Secure; HttpOnly; SameSite=Lax

JavaScriptで設定する例（注意：HttpOnly属性はJSからは設定・参照できません）

document.cookie = "theme=dark; expires=Fri, 31 Dec 2026 23:59:59 GMT; path=/; SameSite=Lax";

主要な属性と意味

  • Expires / Max-Age：永続化するための期限。Max-Age（秒数）はExpires（日時）より優先されます。
  • Domain / Path：どのホスト名・URLパスに対してクッキーが送られるかを制御します。
  • Secure：HTTPS接続のみでクッキーを送信します（平文HTTPでは送られない）。
  • HttpOnly：JavaScriptの document.cookie からアクセスできなくし、XSSによる盗難リスクを低減します。
  • SameSite：クロスサイト送信を制限する属性。Strict / Lax / None があり、SameSite=None を使う場合は Secure が必要（ブラウザ要件）。

サイズ・数・スコープの制限（実務上の注意）

RFC 6265 では、実装は少なくとも各クッキーについて 4096 バイト、ドメインあたり 50 個のクッキーをサポートすることが推奨されています。ただし、実際の上限はブラウザごとに差があり、合計保存可能なクッキー数やドメインごとの上限は異なります。したがって、1つのクッキーに大量のデータを詰め込むのは避け、必要最小限の情報（もしくはサーバ側で解決するトークン）を格納するのが望ましいです。

利用ケースと実装上の注意点

  • 「ログイン状態を保持（Remember me）」：永続クッキーにユーザー名やパスワードを直接保存してはいけません。代わりに長くランダムなトークンを発行し、サーバ側でそのトークンとユーザーIDを照合・管理（期限・失効・ローテーション）します。
  • ユーザー設定の保存：テーマや言語設定など、非機密の設定保存に使う。
  • トラッキング / 分析：ユーザー識別のために長期IDを保存することがあるが、プライバシーと法令順守を考慮する必要があります。

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

永続クッキーは端末に残るため、共有端末や盗難・マルウェアのリスクがあります。主な懸念は次の通りです。

  • XSS（クロスサイトスクリプティング）：HttpOnly 属性がないクッキーは悪意のあるスクリプトから読み取られ、セッション乗っ取りに使われる可能性があります。
  • CSRF（クロスサイトリクエストフォージェリ）：認証済みクッキーが自動送信される性質を悪用される場合があるため、CSRFトークンや SameSite 属性で対策します。
  • トラッキングとプライバシー：第三者（サードパーティ）クッキーを使った長期追跡はプライバシー侵害につながり、規制やブラウザの制限対象となっています。

サードパーティクッキーとブラウザの動向

サードパーティクッキー（訪問先ドメインとは異なるドメインが設定・受信するクッキー）はクロスサイト追跡に多用されましたが、プライバシー規制やブラウザ側の仕様変更により制限が強まっています。AppleのSafariのITP（Intelligent Tracking Prevention）やMozilla FirefoxのETP（Enhanced Tracking Protection）はクロスサイト追跡の抑制を導入しています。GoogleもPrivacy Sandboxで第三者クッキーの代替を模索していますが、完全な代替はまだ進行中です。

法規制・同意（コンプライアンス）

EUのGDPRやePrivacy指令（クッキー法）では、非必須クッキー（特にトラッキング用途）についてはユーザーの明確な同意が必要です。日本でも個人情報保護法（APPI）やガイドラインに従い、個人を識別できる情報を扱う場合は適切な説明と管理が求められます。実務ではクッキーバナーや詳細なクッキーポリシーで、使用目的・保持期間・第三者共有の有無を明示し、ユーザーがオン／オフ選択できるようにすることが一般的です。

実装上のベストプラクティス

  • 機密情報（パスワード等）をクッキーに直接保存しない。代わりにサーバ側でトークン管理を行う。
  • HttpOnly と Secure を可能な限り設定する（特に認証トークン）。
  • SameSite を適切に設定して CSRF リスクを低減する（不要なクロスサイト送信を制限）。
  • クッキーの有効期限は最小限にする。長期保存が本当に必要かを再検討する。
  • サードパーティサービスを利用する際は、プライバシーポリシーと同意管理の連携を行う。
  • ブラウザの挙動差や上限に依存しないように設計する（大きなデータはクッキーではなくサーバ側や別ストレージに）。

代替手段とその比較

クライアント側保存の他の手段として localStorage、sessionStorage、IndexedDB などがあります。これらは大きなデータ保存に適する一方で、すべて JavaScript からアクセスできるため XSS に弱く、HTTPリクエストに自動付与されないという特性を持ちます。認証トークンなどはセキュリティ面を考慮してクッキー（HttpOnly）を使う方が安全な場合が多いです。

運用上のチェックリスト（短期・長期）

  • クッキーの用途を分類し、必須・非必須を明確にする。
  • 非必須クッキーに対しては事前同意を取得する仕組みを用意する。
  • 認証トークンは HttpOnly / Secure / SameSite を付与し、短めの有効期限とローテーションを行う。
  • 第三者クッキーを導入する場合はサービスのプライバシー影響を評価する。
  • 定期的にクッキー・ポリシーと実装（ヘッダ、JavaScript）をレビューする。

まとめ

永続クッキーはユーザー体験を向上させる便利な仕組みですが、端末に長期間残るという性質から、セキュリティとプライバシーの観点で慎重な設計と運用が必要です。HttpOnly・Secure・SameSite といった属性を正しく使い、不要に長い保存期間や機密情報の保存を避け、法令やユーザーの同意に配慮した実装を行うことが重要です。また、ブラウザや規制の動向を注視し、第三者トラッキングに依存しない設計も検討してください。

参考文献

カテゴリー
IT
前の記事
Ash Ra Tempel 入門ガイド：クラウトロックの宇宙を解く代表作と歴史解説New!!
2025年11月20日
次の記事
玄関ドアとは？種類・素材・防犯性能・断熱性まで徹底解説New!!
2025年11月20日