🐶

【Railsセキュリティガイドを読む前に】Cache,Cookie,Sessionについて知る

2024/07/08に公開

Rails

Ruby

http

tech

キャッシュ…クッキー…セッション…分かるようで分からない

分かるようで分からない用語の代表格とも言える、Session,Cookie,Cacheについて分かりやすくお伝えします！

Cache（キャッシュ）

ウェブページの要素（画像、CSSファイル、JSファイルなど）を一時的にブラウザに保存する仕組みのことを指します。
元々この言葉には「〔武器・貴重品などの〕隠し場所」「貯蔵所」などの意味があるので、英単語の意味と一緒に覚えると分かりやすいですね。
具体的に使用するメリット・デメリットを考えてみましょう。

メリット

高速化: 繰り返しアクセスされるリソースの読み込み時間を大幅に短縮できる。
データ通信量の節約: サーバーとクライアント間のデータ転送量を減らせる。
サーバー負荷の軽減: 頻繁にアクセスされるリソースの再計算や再取得を避けられる。

デメリット

古いコンテンツの表示: キャッシュが適切に更新されないと、古い情報が表示される可能性がある。
無効化するタイミングの設計: 適切なタイミングでキャッシュを無効化する仕組みが必要。
ストレージ消費: クライアントサイドでのキャッシュはユーザーのデバイスのストレージを消費する。

このように、Cache（キャッシュ）をブラウザに保存することで、何度も同じ画像を読み込んだりして通信が重くなってしまうことを避け、読み込み速度を向上させるには必要な技術です。一方で、ユーザ側のブラウザにキャッシュが溜まってしまうと古い情報が表示されてしまったり、ユーザ側のストレージを圧迫してしまう可能性があります。

Cache（キャッシュ）と似ていて、ブラウザに情報を保存しますが、こちらはユーザの情報などを保存します。また、キャッシュは通常ローカルのみの保存ですが、クッキーはサーバーに送信されるというところもポイントです。
何故Cookie（クッキー）と呼ばれるのかは諸説あるようですが、小さな１つのデータの塊をサーバとクライアントの間でやり取りすることを、お菓子に例えたとする説などあるようです。
具体的に使用するメリット・デメリットを考えてみましょう。

メリット

クライアントサイドでの保存: サーバーの負荷を軽減できる。
長期的なデータ保存: ユーザー設定や言語選択など、長期間保持したい情報に適している。
クロスサイトトラッキング: ユーザーの行動追跡や分析に利用できる。

デメリット

容量制限: ブラウザによって保存できるデータ量に制限がある（通常4KB程度で、キャッシュより遥かに小さい容量）。
セキュリティリスク: XSS攻撃などによってクッキーが盗まれたり、書き換えられたりする可能性がある。
プライバシー懸念: ユーザーのトラッキングに使用されることへの懸念から、ブロックされることがある。

ここでちょっと整理

似てるので混同してしまいがちなので、ここで違いを整理しましょう。

クッキーは主にユーザーデータの保存、キャッシュはウェブサイトのリソース保存に使用される。
クッキーはサーバーに送信されるが、キャッシュは通常ローカルに存在する。
クッキーが保存できるデータ量は通常4KB程度のみで、キャッシュはより多くのデータを保存できる。

違いについて整理できたら、最後のSession（セッション）について見ていきましょう！

Session（セッション）

Session（セッション）とは、通信の開始から終了までの一連の状態を指します。クライアントからサーバーへ接続するとSession（セッション）が始まり、サーバーから切断するとSession（セッション）が終了します。この一連の流れを管理することをSession（セッション）管理と言うわけですね。セッションを識別するためのセッションIDを生成し、その内容をCookieに保存しておくと、このSession（セッション）IDにユーザー情報や処理状況を紐付けることができ、通信時にCookieに保存したセッションIDを読み取ることで、その通信がどのユーザーからのもので、どういった処理状態にあるのかを把握できます。
微妙に分かりづらいかもしれないので、飲食店でのお客さんと店員さんとのやり取りで例えてみましょう。

1.セッションの開始

お客さん（ユーザー）が店に入り、席に座ります。店員さんがお客さんを認識し、テーブル番号を覚えます。
これが「セッションの開始」に相当します。

2.セッションID

店員さんがお客さんにテーブル札（例：5番テーブル）を渡します。これが「セッションID」に相当します。
店員さんはこの番号でお客さんを識別します。

3.セッションデータの保存

お客さんが注文するたびに、店員さんは伝票（サーバーのメモリ）に記録します。
※例えば「5番テーブル：ジュース2杯、パスタ1皿、サラダ1皿」のような感じで伝票に追加します。
これが「セッションデータの保存」に相当します。

4.セッションの維持

お客さんが席を離れてトイレに行っても、店員さんは注文を覚えています。
これが「セッションの維持」に相当します。ユーザーが一時的にページを離れても情報が保持されます。

5.セッションの終了

お客さんが会計を済ませて店を出ます。店員さんは伝票を会計済みのボックスに移します。
これが「セッションの終了」に相当します。

伝票（データ）はお店（サーバ）が管理し、テーブル番号（セッションID）で客を管理するというルールが適用されているわけですね。
では、具体的に使用するメリット・デメリットを考えてみましょう。

メリット

一時的なデータ保存: ユーザーのログイン状態や買い物かごの内容など、短期的な情報を効率的に保存できる。
サーバーサイドでの管理: クライアント側で情報を改ざんされるリスクが低い。
大量のデータ保存: クッキーと比較して、より多くのデータを保存できる。

デメリット

サーバーリソースの消費: アクティブなセッションが増えるとサーバーの負荷が高くなる。
スケーラビリティの課題: 分散システムにするとセッション管理が複雑になる。
セッションハイジャックのリスク: セッションIDが盗まれると、不正アクセスの危険性がある。