session は、ログイン状態など「ユーザーごとの状態」を管理するための仕組みで、
HTTP が本来「状態を持たない（ステートレス）」通信であることを補う役割を持つ。
セッション自体は「攻撃を防ぐ機能」ではないが、
ログイン状態・ユーザー識別・権限管理など、セキュリティ機能の土台として非常に重要な仕組みである。
セッションを使うことで、
フォームの「入力 → 確認 → 送信」や、
ECサイトの「カートに入れる → カート内容確認 → 注文画面へ」など、
ページ遷移をまたいでデータを保持する処理を実現できる。
サーバー側ではユーザーごとのデータをセッション保存領域に保持し、
それを識別するために セッションID を使う。
Cookie は、ブラウザ側に保存される小さなテキストデータで、
PHP のセッションでは「セッションIDをブラウザに覚えさせる」ために使われる。
流れとしては：
- サーバーがランダムな セッションID を生成する
- そのセッションIDを Cookie（例:
PHPSESSID=xxxx）としてブラウザに送る - ブラウザは以降のリクエストで、その Cookie を毎回サーバーに送信する
- サーバーは Cookie から受け取ったセッションIDを使って、
セッション保存領域から該当ユーザーの セッションデータ（配列） を取り出す
PHP の通常のセッションでは、
ブラウザ側の Cookie には「セッションIDだけ」が保存され、
実際のユーザーデータはすべてサーバー側に保存される。
この意味で、Cookie は「セッションデータそのもの」を持つのではなく、
サーバー側のセッションデータへアクセスするための鍵🔑の役割を果たす。
CSRFトークン は、フォーム送信時などに一緒に送られるランダムな文字列で、
「そのリクエストが本当に自分のサイトの正規のフォームから送られたものか」を確認するために使われる。
典型的な流れ：
- フォームを表示するタイミングで、サーバーがランダムな CSRFトークン を生成する
- そのトークンを セッションに保存 し、同じ値をフォーム内の hidden フィールドなどに埋め込む
- ユーザーがフォームを送信すると、CSRFトークンも一緒に送信される
- サーバー側で
- セッションに保存されているトークン
- フォームから送られてきたトークン
を比較し、一致すれば処理を実行し、不一致なら処理を中止する
この仕組みによって、
外部サイトからユーザーの Cookie（＝ログイン中のセッション）を悪用して送られたリクエストであっても、
正しいCSRFトークンが付いていないため拒否できる。