Cookieとは何か？初心者でもわかりやすい公式ガイドでセキュリティや使い方を徹底解説

はじめに
Webページを閲覧した瞬間、あなたのブラウザは自動的に小さなファイル――Cookie―を受け取り、保存しています。Cookieは「何か」を記憶してくれる頼もしい相手ですが、同時に「誰がどこで何をしたか」の情報を追跡できてしまうため、プライバシーやセキュリティの観点からは注意が必要です。
本記事では、初心者でも理解できるように Cookie の基本から設定方法、そして安全に扱うためのベストプラクティスまでを公式スタイルで徹底解説します。

Cookie とは何か？

Cookie は HTTP ヘッダーの一種で、サーバーからクライアント（ユーザーのブラウザ）へ送られます。クライアントは受け取った Cookie をローカルに保存し、以降同じサイトへのリクエスト時に自動で同じ Cookie を送信します。

例：

Set-Cookie: user_id=12345; Expires=Wed, 09 Jun 2025 10:18:14 GMT; Path=/; Secure; HttpOnly

このヘッダーはサーバーからクライアントへ送られ、ブラウザは user_id という名前の Cookie を保存します。次回に同じ example.com にアクセスすると、ブラウザは自動で
Cookie: user_id=12345 を HTTP リクエストヘッダーに付与して送信します。

Cookie はファイルシステム上、ユーザーごとにディレクトリ構造で格納されるので、閲覧者は自分のブラウザを終了しても残り続けます（期限付きなら除く）。

Cookie の主な用途

Cookie の種類

1. セッションクッキー（Session Cookie）

   • ブラウザを閉じると自動で削除される。
   • 主に認証トークンや一時的な設定を保存。

2. 永続クッキー（Persistent Cookie）

   • Expires または Max-Age が設定され、指定期間保存。
   • ユーザー設定や長期ログイン(「自動ログイン」)などに利用。

3. セキュリティ Cookie

   • Secure（HTTPS でのみ送信）や HttpOnly（JavaScript からアクセス不可）属性付き。
   • CSRF への対策や XSS 攻撃を防ぐために必須。

Cookie の構造

Set-Cookie: <name>=<value>; Domain=example.com; Path=/; Expires=Mon, 21 Mar 2026 20:00:00 GMT; Secure; HttpOnly; SameSite=Lax

SameSite 属性

• Strict：完全に同じサイトからのリクエストしか Cookie を送らない。
• Lax：GET リクエスト時のトップレベルナビゲーションで Cookie を送る。
• None：どんなサイトからでも送れ、Secure が必須。

SameSite を正しく設定することで CSRF (Cross Site Request Forgery) を防ぐ大きな一手になります。

Cookie によるセキュリティリスク

Cookie の安全な取り扱いガイドライン

1. Secure・HttpOnly の併用

   Set-Cookie: session_id=ABC123; Secure; HttpOnly; SameSite=Strict
   

   これでクライアント側スクリプトからはアクセスできず、HTTPS かつ同一サイトからのみ利用できます。

2. 最小限のデータ格納

   • セッション ID は ハッシュ化 した文字列で十分です。
   • 個人情報（氏名、電話番号等）は Cookie に入れず、サーバー側で管理します。

3. 適切な有効期間設定

   • ログイン用 Cookie は 30 分〜1 時間程度にする。
   • 「覚えておく」機能は 7〜30 日程度に留める。

4. SameSite の設定

   • 主要操作（ログイン・購入）には SameSite=Strict、必要に応じて Lax。
   • サードパーティ（外部広告）Cookie は SameSite=None; Secure で明示。

5. CSP(コンテンツセキュリティポリシー)

   • <meta http-equiv="Content-Security-Policy" content="default-src 'self';">
   • 外部スクリプトを制限し、XSS 攻撃の実行環境をブロック。

6. HSTS (HTTP Strict Transport Security) の導入

   • Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
   • HTTPS 強制化により、中間者攻撃を防ぐ。

Cookie をクリア・管理する方法

ブラウザ内蔵機能

JavaScript で削除する（ブラウザサポート時）

// 期限を過去に設定して削除
document.cookie = "session_id=; expires=Thu, 01 Jan 1970 00:00:01 GMT; path=/; domain=example.com; Secure; HttpOnly";

サーバーサイドでの Cookie を無効化

• Node.js (Express):

  app.use((req, res, next) => {
    res.clearCookie('session_id', { path: '/', httpOnly: true, secure: true });
    next();
  });
  

• PHP:

  setcookie('session_id', '', time() - 3600, '/', '', true, true);
  

Cookie を利用した「自動ログイン」の仕組み

1. ログイン時

   • サーバーは ランダムなトークン を生成し、ユーザー ID と紐付けて DB に保存。
   • Set-Cookie: auth_token=RANDOM_STRING; HttpOnly; Secure; SameSite=Strict; Max-Age=604800（1 週）を送信。

2. 次回アクセス時

   • ブラウザは Cookie を自動送信。
   • サーバーはトークンを検証し、ユーザーを認証。

3. ログアウト時

   • Cookie を失効させ、サーバー側のトークンを削除。

注意点

• トークンは 一意 かつ 予測困難 である必要。
• 「自動ログイン」でも「ログアウト時に強制クリア」を実装。

GDPR・個人情報保護法と Cookie

• 同意取得：クッキーを使用する前に ユーザーに明示的な同意 を得る。
• 目的の範囲：収集した情報は同意した目的にのみ利用。
• 第三者共有：共有する場合は 別途同意 を取得。
• 削除権：ユーザーが Cookie の削除・停止を求められた場合に対応。

実装例

// 同意を取得した状態でのみ Cookie 設定
if (userHasAgreed) { setCookie(...); }

代表的な Cookie 関連 API（JavaScript）

よくある質問 (FAQ)

1. Cookie だけでなく LocalStorage も使える？
   • ほかのウェブストレージは Cookie より長期保存が可能だが、HTTP リクエストに自動で付与されない。
2. Cookie のサイズ上限は？
   • 通常 4 KB（1 ドメインあたり）。
3. クッキーが読み取りにくいと感じるのはなぜ？
   • HttpOnly 属性が付いているため、JavaScript からはアクセス不可。
4. SameSite=None の場合に必要なのは？
   • Secure 属性を必ず併用しないとブラウザが拒否する。

まとめ

Cookie は「ユーザー情報を小さく、永続的に持ち歩く」ための手段として、Web 開発に欠かせない技術です。

• 「どのように保存・送信・削除されるか」を理解する
• セキュリティ属性（Secure, HttpOnly, SameSite）を必ず設定する
• ユーザーのプライバシーを尊重し、GDPR 等の規制に従う

これらを守ることで、ユーザビリティと安全性の両立が可能になります。
Cookie を賢く使いこなし、安心・快適な Web 体験を提供しましょう。