CookieとセッションをPHPで理解する
副題: JavaScript/PHPで、試験に出る知識を実務につなげる
はじめに: Cookieとセッションは「ログイン状態」を理解する入口
Webサイトにログインしたあと、別のページへ移動してもログイン状態が続いている。ネットショップで商品をカートに入れたあと、ページを移動してもカートの中身が残っている。
普段は当たり前のように使っているこうした仕組みですが、Webの基本を学ぶうえではとても重要です。特に基本情報処理技術者試験では、HTTP、Cookie、セッション、セキュリティといった知識がつながって問われます。
ポイントになるのは、HTTPは基本的に「前のアクセスを覚えていない」ということです。つまり、何もしなければサーバーは「この人はさっきログインした人だ」と自動では判断できません。そこで使われるのがCookieやセッションです。
この記事では、Cookieとセッションの役割の違いを整理しながら、PHPのサンプルコードで実際に動きを確認します。単なる用語暗記で終わらせず、「なぜログイン状態を保てるのか」「なぜCookieに何でも保存してはいけないのか」まで、実務につながる形で理解していきましょう。
HTTPは状態を持たない
Cookieやセッションを理解する前に、まずHTTPの特徴を押さえておきます。
HTTPは、ブラウザとサーバーがやり取りするための通信ルールです。ブラウザが「このページをください」とリクエストを送り、サーバーがHTMLなどのレスポンスを返します。この1回ごとのやり取りは、基本的には独立しています。
たとえば、あるユーザーがログインページでIDとパスワードを送信したとします。その直後にマイページへアクセスしても、HTTPだけでは「さっきログインしたユーザーからのアクセスだ」と自動で判断できません。
このように、前の通信の状態をそのまま覚えていない性質を「ステートレス」といいます。基本情報処理技術者試験でも、HTTPの特徴として出てきやすい考え方です。
ただし、実際のWebアプリケーションでは状態を扱う場面がたくさんあります。
- ログイン状態を保つ
- ショッピングカートの中身を保持する
- 入力途中のフォーム情報を一時的に扱う
- ユーザーごとに表示内容を変える
つまり、HTTPそのものは状態を持たないけれど、Webアプリケーションとしては状態を管理したい。このギャップを埋めるために使われる代表的な仕組みが、Cookieとセッションです。
Cookieとはブラウザに保存される小さな情報
Cookieは、ブラウザ側に保存される小さな情報です。
たとえばサーバーが「このユーザーには theme=dark というCookieを保存しておいてください」とブラウザに伝えると、ブラウザはその情報を保存します。そして次回以降、同じWebサイトへアクセスするときに、そのCookieをリクエストに付けて送ります。
つまりCookieは、サーバーがブラウザに情報を持たせ、次のアクセスでもその情報を受け取れるようにする仕組みです。
Cookieには、表示テーマ、言語設定、アクセス解析用の識別子などを保存できます。JavaScriptから document.cookie で確認・操作できるCookieもあります。ただし、すべてのCookieをJavaScriptから扱えるわけではありません。実務では、セキュリティのためにJavaScriptから読めないようにする HttpOnly という属性も使われます。
ここで大事なのは、Cookieはブラウザ側に保存されるという点です。ユーザーの環境に保存される情報なので、パスワードや個人情報などの重要な値をそのまま入れるべきではありません。
PHPでCookieを保存して読み取る
PHPでは、setcookie() を使ってCookieを保存できます。
<?php
setcookie('favorite_color', 'blue', time() + 3600);
?>
<!DOCTYPE html>
<html lang="ja">
<body>
<p>Cookieを保存しました。</p>
</body>
</html>この例では、favorite_color という名前で blue という値を保存しています。time() + 3600 は、有効期限を現在時刻から1時間後にする指定です。
保存されたCookieは、次回以降のリクエストで $_COOKIE から読み取れます。
<?php
$color = $_COOKIE['favorite_color'] ?? '未設定';
?>
<!DOCTYPE html>
<html lang="ja">
<body>
<p>好きな色: <?php echo htmlspecialchars($color, ENT_QUOTES, 'UTF-8'); ?></p>
</body>
</html>注意したいのは、setcookie() で設定したCookieは、その場ですぐ $_COOKIE に入るわけではないという点です。Cookieはレスポンスとしてブラウザに送られ、次のリクエストでサーバーに返ってきます。そのため、初めてCookieを保存した直後の画面では、まだ $_COOKIE で読めないことがあります。
また、setcookie() はHTTPヘッダーを送信する関数なので、HTMLを出力する前に呼び出す必要があります。PHPでCookieを扱うときにつまずきやすいポイントなので、コードを書くときはファイルの先頭付近で設定すると覚えておくとよいでしょう。
セッションとはサーバー側で状態を管理する仕組み
Cookieはブラウザ側に情報を保存する仕組みでした。一方、セッションは主にサーバー側で状態を管理する仕組みです。
ログイン状態を例にすると、ユーザー名やログイン済みかどうかの情報を、すべてCookieに入れてブラウザへ渡すのは危険です。Cookieはユーザー側に保存されるため、内容を見られたり、書き換えられたりする可能性を考える必要があります。
そこで、実際のデータはサーバー側に保存し、ブラウザには「どのデータを使うか」を示すためのIDだけを持たせます。このIDをセッションIDと呼びます。
イメージとしては、次のような流れです。
- サーバーがセッションIDを発行する
- ブラウザはセッションIDをCookieとして保存する
- 次回以降のリクエストで、ブラウザがセッションIDを送る
- サーバーはセッションIDを見て、対応するユーザー情報を取り出す
つまりセッションは、Cookieとまったく別の仕組みというより、Cookieを使ってサーバー側のデータを参照する仕組みとして理解すると分かりやすいです。
PHPでセッションに値を保存する
PHPでセッションを使うには、まず session_start() を呼び出します。そのうえで、$_SESSION に値を保存します。
<?php
session_start();
$_SESSION['user_name'] = 'Taro';
?>
<!DOCTYPE html>
<html lang="ja">
<body>
<p>セッションにユーザー名を保存しました。</p>
<p><a href="mypage.php">マイページへ</a></p>
</body>
</html>別のページでも session_start() を呼ぶことで、同じセッションに保存された値を読み取れます。
<?php
session_start();
$userName = $_SESSION['user_name'] ?? 'ゲスト';
?>
<!DOCTYPE html>
<html lang="ja">
<body>
<p>こんにちは、<?php echo htmlspecialchars($userName, ENT_QUOTES, 'UTF-8'); ?>さん</p>
</body>
</html>この例では、最初のページで保存した user_name を、別のページで読み取っています。HTTP自体は前のアクセスを覚えていませんが、セッションを使うことで「同じユーザーの続きのアクセス」として扱えるようになります。
実際のログイン処理では、IDとパスワードを確認したあとに、ユーザーIDなどを $_SESSION に保存します。パスワードそのものをセッションやCookieに保存する必要はありません。認証が済んだことをサーバー側で管理する、という考え方が大切です。
Cookieとセッションの違いを整理する
ここまでの内容を、Cookieとセッションの違いとして整理しておきましょう。
| 観点 | Cookie | セッション |
|---|---|---|
| 主な保存場所 | ブラウザ側 | サーバー側 |
| ブラウザに保存されるもの | 値そのもの | 主にセッションID |
| よく使う場面 | 表示設定、言語設定、識別子の保存 | ログイン状態、ユーザーごとの一時データ |
| PHPで使う主な機能 | setcookie()、$_COOKIE | session_start()、$_SESSION |
| 注意点 | 重要情報をそのまま入れない | セッションIDを盗まれないようにする |
Cookieは、ブラウザに保存され、リクエスト時にサーバーへ送られる情報です。セッションは、サーバー側にデータを保存し、ブラウザから送られてくるセッションIDによって対応するデータを取り出す仕組みです。
試験対策としては、「Cookieはブラウザ側」「セッションはサーバー側」「セッションIDはCookieでやり取りされることが多い」という3点を押さえると整理しやすくなります。
実務でも、この違いはとても重要です。たとえば、ユーザーが選んだ表示テーマならCookieに保存しても大きな問題になりにくいですが、ログイン中のユーザーIDや権限情報はサーバー側で管理するのが基本です。どこに何を保存するかを考えることが、Webアプリケーションの安全性につながります。
試験ではどう問われるか
基本情報処理技術者試験では、Cookieやセッションの細かいPHPコードそのものよりも、Webの仕組みとしての役割を理解しているかが問われます。
まず押さえたいのは、HTTPがステートレスなプロトコルであることです。前のリクエストの状態をHTTP自体が自動で覚えているわけではないため、ログイン状態などを扱うには別の仕組みが必要になります。
次に、Cookieはブラウザ側に保存され、リクエスト時にサーバーへ送られる情報だと理解しておきます。問題文で「利用者のブラウザに保存される」「次回アクセス時にサーバーへ送信される」といった説明が出てきたら、Cookieを指している可能性があります。
セッション管理では、セッションIDが重要です。サーバー側に保存されたセッション情報を取り出すために、ブラウザからセッションIDを送ります。セッションIDはCookieでやり取りされることが多いため、「セッションはサーバー側」「セッションIDはブラウザ側にも保存されることがある」と分けて考えると混乱しにくくなります。
また、セッションIDを第三者に知られると、本人になりすましてアクセスされる危険があります。これをセッションハイジャックと呼びます。Cookieやセッションは、HTTPやログインの仕組みだけでなく、Webセキュリティの理解にもつながるテーマです。
試験対策としては、次のように整理しておくとよいでしょう。
- HTTPはステートレスである
- Cookieはブラウザに保存され、リクエスト時に送られる
- セッションでは、サーバー側のデータをセッションIDで識別する
- セッションIDの漏えいは、なりすましのリスクにつながる
実務ではどう使われるか
実務のWebアプリケーションでは、Cookieとセッションはログイン機能の土台としてよく使われます。
たとえば、ユーザーがログインに成功したら、サーバー側のセッションにユーザーIDを保存します。次のアクセスでは、ブラウザから送られてきたセッションIDをもとに、サーバーが「このユーザーはログイン済みだ」と判断します。これにより、ページを移動してもログイン状態を保てます。
また、セッションはCSRF対策にも関係します。CSRFは、ログイン中のユーザーに意図しない操作をさせる攻撃です。対策として、フォームにトークンを埋め込み、サーバー側のセッションに保存した値と一致するかを確認する方法があります。
Cookieを安全に扱うための属性も重要です。代表的なものには、JavaScriptからCookieを読みにくくする HttpOnly、HTTPS通信のときだけCookieを送る Secure、別サイトからのリクエストでCookieを送る範囲を制御する SameSite があります。
Laravelなどのフレームワークを使うと、セッション管理やCSRF対策の多くは用意されています。そのため、普段の開発では細かい処理を直接書かないこともあります。それでも、裏側でCookieとセッションがどう使われているかを知っていると、ログインできない、セッションが切れる、フォーム送信が失敗するといったトラブルの原因を追いやすくなります。
まとめ: Cookieはブラウザ、セッションはサーバー側の状態管理
Cookieとセッションは、HTTPがステートレスであることを補うための代表的な仕組みです。
Cookieはブラウザ側に保存され、次回以降のリクエストでサーバーへ送られます。一方、セッションは主にサーバー側で状態を管理し、ブラウザから送られるセッションIDを使って対応するデータを取り出します。
基本情報処理技術者試験では、Cookieの保存場所、セッションIDの役割、HTTPのステートレス性をセットで理解しておくと整理しやすくなります。実務でも、ログイン状態の維持、CSRF対策、Cookie属性の設定などにつながる大切な基礎です。
次に学ぶなら、PHPで簡単なログイン処理を作ってみると、Cookieとセッションの関係をさらに具体的に理解できます。
コメント