PHP

PHPのセッションとCookieの違い・安全な使い分け

PHPのセッションとCookieについて、データの保存場所や有効期間、用途、セキュリティ上の注意点を比較し、ログイン状態や一時データに適した使い分けを解説する。

この記事でわかること

  • セッションとCookieは、データを保持する場所と送信方法が異なる。
  • ログイン状態の管理では、識別子だけをCookieに保存し、サーバー側で情報を管理する設計が基本になる。
  • Cookieの属性設定やセッションIDの再生成など、用途に応じた安全対策が必要になる。

セッションとCookieは何を保持する仕組みか

Cookieはブラウザー側に保存され、後続のリクエストでサーバーへ送信される情報です。一方、PHPのセッションは、リクエストで渡されたセッションIDを手がかりに、サーバー側でユーザーごとのデータを参照します。つまり、Cookieとセッションは別の仕組みですが、PHPのセッション管理では、セッションIDの受け渡しにCookieが使われることがあります。

セッションとCookieの違いを比較する

観点セッションCookie
保存場所主にサーバー側ブラウザー側
リクエスト時の扱いセッションIDなどを使ってサーバー側のデータを参照Cookieの値が条件に応じてサーバーへ送信される
保持期間PHP設定やアプリケーションの管理方法に依存有効期限を指定でき、指定しない場合はブラウザー終了までの扱いになることがある
閲覧・変更のしやすさ利用者が直接確認・変更しにくい利用者側で確認・変更される可能性がある
代表的な用途ログイン状態、入力途中の一時データ表示設定、同意状態などの小さな設定情報
セッションとCookieの比較

Cookieは利用者側で変更される可能性があるため、機密情報や改ざんされると困る情報をそのまま保存しないようにします。サーバー側で保護・管理したい情報には、セッションを使う設計が向いています。

PHPでセッションを使う基本手順

セッションを使う場合は、出力を始める前のリクエスト初期段階で session_start() を呼び出します。保存した値は $_SESSION から参照できます。session_start() は新しいセッションを開始するほか、リクエストで渡されたセッションIDを使って既存のセッションを再開します。

PHP
<?php
// 出力を始める前にセッションを開始
session_start();

// ログイン成功時などに保存する値
$_SESSION['user_id'] = 123;

// 別の処理やページで参照
$userId = $_SESSION['user_id'] ?? null;

// 不要になった値だけ削除
unset($_SESSION['user_id']);

// ログアウト処理では、セッション変数の削除や
// セッション自体の破棄をアプリケーション要件に応じて検討する
// 期待される挙動: $userId には保存したユーザー識別子が入る

実際のセッション保存先や有効期間は、PHPの設定、保存ハンドラー、アプリケーション構成によって異なります。対象環境の設定も確認してください。

PHPでCookieを使う基本手順

Cookieは setcookie() でレスポンスに設定し、後続のリクエストでは $_COOKIE から読み取ります。Cookieを設定する処理は、HTMLなどの出力より前に実行する必要があります。

PHP
<?php
// HTTPS環境を前提にした設定例
setcookie('display_mode', 'dark', [
    'expires' => time() + 86400 * 30,
    'path' => '/',
    'secure' => true,
    'httponly' => true,
    'samesite' => 'Lax',
]);

// 後続リクエストで読み取る
$displayMode = $_COOKIE['display_mode'] ?? 'light';

// 削除時は、設定時と同じpathなどを指定して期限を過去にする
setcookie('display_mode', '', [
    'expires' => time() - 3600,
    'path' => '/',
    'secure' => true,
    'httponly' => true,
    'samesite' => 'Lax',
]);

// 期待される挙動: Cookieの値は次回以降のリクエストで送信される

setcookie() では、有効期限、Path、Secure、HttpOnly、SameSiteなどを用途に応じて設定できます。SecureはHTTPS接続時だけCookieを送信する指定、HttpOnlyはJavaScriptなどからの読み取りを制限する指定です。SameSiteを None にする場合は Secure も必要です。Cookieの削除では、設定時と整合するPathなどを指定します。また、Cookieの値は利用者側で変更される可能性があるため、受け取った値をそのまま信頼せず、形式や許可値を検証してください。

用途別に安全な使い分けを考える

  • ログイン状態:Cookieにはセッションを参照するための識別情報を扱い、ユーザー情報や権限などはサーバー側で管理する。
  • 一時データ:入力途中の内容など、サーバー側で保護・管理したい情報はセッションに保存する。
  • 表示設定:テーマや言語など、利用者側に保持させてもよい小さな設定情報はCookieの候補にする。
  • 認証成功時:権限が未認証から認証済みに変わるため、session_regenerate_id() によるセッションID再生成を検討する。
  • 通信とCookie:HTTPSを利用できる環境では、Secure、HttpOnly、SameSiteを要件に合わせて設定する。
  • 追加対策:CSRF、XSS、入力値検証、セッションの有効期限、認証・認可の設計は、セッションやCookieの設定だけでは解決できない。

セッションIDの再生成は、セッション固定攻撃への対策の一つです。ただし、ネットワーク状況やアプリケーション構成によってはセッション消失などの影響もあり得るため、PHPの公式ドキュメントを確認し、実装とテストを行ってください。

参考