LASSIC Media らしくメディア
Cookieとセッションの違いと仕組み｜状態管理の基本
HTTPはステートレス、だから状態保持の仕組みが要る
Webの通信プロトコルであるHTTPは、本来ステートレス（状態を持たない）な設計になっています。1つのリクエストとレスポンスが完結すると、サーバーはそのやり取りの内容を覚えていません。次にブラウザがアクセスしてきても、サーバーからは「初めて訪れた相手」と区別がつかないのが原則です。
しかし実際のWebアプリケーションでは、ログイン状態の維持やカート内容の保持など、複数回のリクエストをまたいで「同じ利用者である」と識別し続ける必要があります。この矛盾を埋めるために使われる代表的な仕組みが、CookieとセッションによるWebの状態管理です。
本記事は、認証や認可の一般論ではなく、CookieとセッションというWeb上で状態を保持するための具体的な仕組みそのものを解説する内容です。ログイン状態の維持は、その状態管理の仕組みが使われる代表的な用途の一つという位置づけにとどめ、認証・認可の設計論には深入りしません。ログイン機能を提供している企業のIT担当者やプロジェクトマネージャーが、開発会社とのやり取りや仕様検討の場で判断材料にできるよう、基礎から整理します。
「なぜCookieだけでなくセッションという仕組みが別に必要なのか」「セッションIDの扱いを誤るとどのようなリスクがあるのか」といった疑問は、システムの新規開発時だけでなく、既存システムの保守やセキュリティ点検の場面でもよく出てくるものです。仕組みの全体像を押さえておくと、開発会社からの提案や設計書の内容を評価しやすくなります。
Cookieとは何か
Cookieとは、サーバーがブラウザに指示して保存させる小さなキーバリュー形式のデータです。サーバーはレスポンスにSet-Cookieヘッダを含めることで、ブラウザにデータの保存を指示します。ブラウザはそれを保存し、以降同じサーバーへのリクエストでCookieヘッダとして自動的に送り返します。
典型的なやり取りは次のような形です。
Set-Cookie: session_id=abc123; Domain=example.com; Path=/; Secure; HttpOnly; SameSite=Lax
Cookie: session_id=abc123
Cookieには主に次のような属性を指定でき、それぞれが挙動やセキュリティに影響します。
- 有効期限（Expires / Max-Age）: 指定がなければブラウザを閉じるまでの一時的なCookie（セッションCookie）になり、指定すればその日時・秒数まで保持される永続Cookieになります。
- Domain: Cookieを送信対象とするホストの範囲を指定するものです。
- Path: Cookieを送信するURLのパス範囲を絞り込むものです。
- Secure: HTTPS接続のときだけCookieを送信する属性で、平文の通信では送られません。
- HttpOnly: JavaScriptの
document.cookieからアクセスできなくする属性で、クロスサイトスクリプティング経由の盗み見を防ぐ効果があります。 - SameSite: 他サイトを起点としたリクエストにCookieを付けるかどうかを制御する属性で、Strict・Lax・Noneの3種類があります。
Cookie自体には容量の上限があり、1つのCookieはおおむね4KB程度までが目安です。また、ブラウザやサイトごとに保存できる個数にも制限があるため、大きなデータをそのまま持たせる用途には向きません。
なお、Cookieには発行元によって「ファーストパーティCookie」と「サードパーティCookie」という区分もあります。自社サイト自身が発行するCookieがファーストパーティCookieで、状態管理の中心的な役割を担うのはこちらです。他ドメインが発行するサードパーティCookieは広告のトラッキングなどに使われることが多く、近年はブラウザ側の制限が強まっている領域ですが、本記事で扱うログイン状態の維持といった用途は主にファーストパーティCookieの話になります。
セッションとは何か
セッションとは、利用者ごとの状態をサーバー側に保持する仕組みです。ログイン情報やカートの中身といった実データはサーバー内のセッションストア（メモリ、データベース、Redisなどのキャッシュサーバーが使われます）に置かれ、ブラウザにはその状態を指し示す「セッションID」だけがCookieとして渡されます。
ブラウザは次回以降のリクエストで、そのセッションIDをCookieヘッダに乗せて送信する仕組みです。サーバーは受け取ったセッションIDをキーにセッションストアを検索し、対応する状態を取り出して処理を続けます。つまりCookieは「鍵」であり、セッションは「鍵に対応する金庫の中身」に相当する仕組みです。
この方式のメリットは、機密性の高い情報をブラウザ側に置かずに済む点です。ブラウザに保存されるのはランダムな識別子のみなので、たとえCookieが盗まれても、セッションストア側で該当セッションを無効化すれば被害を止めやすくなります。
セッションストアの実装は、Webアプリケーションが動作するサーバーのプロセス内メモリに持たせる簡易な方式から、RedisやMemcachedといったインメモリキャッシュ、あるいはリレーショナルデータベースに保存する方式まで幅が広いものです。サーバーを複数台にスケールさせる構成では、各サーバーが同じセッション状態を参照できるよう、外部のセッションストアを共有する設計にするのが一般的です。1台のサーバーのメモリだけにセッションを保持していると、負荷分散でリクエストが別のサーバーに振り分けられた際にログイン状態が引き継がれない、という問題が起きやすくなります。
Cookieとセッションの違い
CookieとセッションはセットでWebの状態管理を実現しますが、役割は明確に異なります。主な違いを次の表に整理します。
| 観点 | Cookie | セッション |
|---|---|---|
| 保存場所 | ブラウザ（クライアント側） | サーバー側のセッションストア |
| 容量 | 1つあたり数KB程度が上限 | サーバーの設計次第で比較的大きなデータも保持可能 |
| セキュリティ | クライアントに残るため盗難・改ざんのリスクに配慮が必要 | 実データはサーバー内にとどまり、外部に漏れにくい |
| 用途 | セッションIDの保持、簡易な設定値の保存など | ログイン状態、カート内容など重要な状態の保持 |
| 失効 | Expires/Max-Ageやブラウザ操作で消える | サーバー側のタイムアウト設定や明示的な破棄で消える |
実務上は「Cookieか、セッションか」という二者択一ではなく、両者を組み合わせて使うのが一般的な構成です。開発を発注する側の視点で見ると、機密性の高いデータをブラウザ側のCookieに直接持たせていないか、セッションに保持している情報の量が適切か、といった観点は、仕様レビューの際にチェックしておきたいポイントになります。
状態管理の実際の流れ
ログイン処理を例に、CookieとセッションIDがどう連携して状態を保持するのかを見ていきます。
- 利用者がID・パスワードでログインを行います。
- サーバーは認証に成功すると、新しいセッションIDを発行しセッションストアに状態を記録するという流れです。
- サーバーはレスポンスの
Set-CookieヘッダでセッションIDをブラウザに渡します。 - ブラウザは以降の同じサイトへのリクエストで、そのセッションIDを
Cookieヘッダに自動で乗せて送信します。 - サーバーは届いたセッションIDをもとにセッションストアを照合し、ログイン済みの利用者として処理を続ける、という仕組みです。
この一連の流れを図に示します。
Cookie/セッション運用の注意点
CookieとセッションIDによる状態管理は便利な反面、セッションIDを第三者に奪われると本人になりすまされる「セッションハイジャック」のリスクがあります。設計・運用では次のような対策を組み合わせることが重要です。
- HttpOnly属性の付与: JavaScript経由でのセッションIDの読み取りを防ぎ、クロスサイトスクリプティングによる漏えいのリスクを下げられます。
- Secure属性の付与: HTTPS通信でのみCookieを送信させ、通信経路上での盗聴によるリスクを下げられます。
- SameSite属性の適切な設定: 他サイトを起点としたリクエストへのCookie送信を制限するもので、CSRF（クロスサイトリクエストフォージェリ）対策として有効です。
- ログイン成功時などのセッションID再生成: セッション固定化攻撃を防ぐため、権限が変わるタイミングでIDを発行し直すことが推奨されます。
- 有効期限の適切な設計: セッションの放置時間を短くするほど、盗まれたセッションIDが悪用できる期間を短くできます。
なお、近年のAPIやモバイル連携が中心のシステムでは、セッションストアを持たずにJWT（JSON Web Token）などの署名付きトークンをブラウザ側だけで検証する方式が採用されるケースもあるものです。サーバー側に状態を持たないぶんスケールしやすい一方、発行済みトークンを個別に無効化しにくいという性質があり、Cookie＋セッション方式とは向き不向きが異なります。どちらを採用するかは、システムの規模や失効管理の要件を踏まえて検討する必要があります。
また、これらの対策は個々に単独で機能するものではなく、組み合わせて初めて実効性を発揮するものです。たとえばHttpOnlyを付けていてもSecure属性がなければ、平文の通信経路上でセッションIDが盗み見られる可能性は残ります。逆にSecureだけを付けてHttpOnlyを付けていなければ、クロスサイトスクリプティングの脆弱性が存在した場合にJavaScript経由でセッションIDを読み取られるリスクは残ったままです。設計時にはこれらの属性を一式でチェックリスト化し、抜け漏れなく設定することが望まれます。
まとめ
HTTPはステートレスなプロトコルであるため、Webサービスで利用者ごとの状態を維持するにはCookieとセッションの組み合わせが基本の仕組みになります。Cookieはブラウザ側に保存される小さなデータで、セッションIDという鍵の役割を担うものです。一方セッションは、実際の状態をサーバー側で保持する仕組みであり、両者は保存場所・容量・セキュリティ・用途のいずれの観点でも役割が異なります。
HttpOnlyやSecure、SameSiteといった属性の設定、セッションIDの再生成、有効期限の設計は、いずれも運用時に見落とされやすいポイントです。仕様検討や既存システムの点検の際は、この記事の対比表と流れ図を参考に、Cookie・セッションそれぞれの設定が適切かどうかを確認してみてください。
特に、システムのリニューアルや外部の開発会社への発注を検討している場合は、提案書や設計書にCookie・セッションまわりの設定方針が明記されているかどうかを確認する視点を持っておくとよいでしょう。属性の設定漏れは画面上の動作からは気づきにくく、後から発覚すると手戻りが大きくなりやすい領域だからです。
相談するメリット
Cookie・セッションの設計は、機能要件だけでなくセキュリティ要件とも密接に関わるため、社内リソースだけで最適な設定判断を行うのは負担が大きい場合があります。LASSICでは、ニアショア開発体制を生かした受託開発により、Webシステムの認証基盤やセッション管理まわりの設計・実装を支援しています。既存システムのCookie/セッション設定の点検から、新規システムでの設計方針の策定まで、要件に応じて対応可能です。仕様の見直しや実装のご相談があれば、お気軽にお問い合わせください。
よくある質問
CookieとセッションIDは同じものですか。
異なります。Cookieはブラウザに保存される仕組み全般を指し、セッションIDはそのCookieの値として渡される、サーバー側のセッションを特定するための識別子です。セッションIDはCookieという入れ物を使って運ばれる、という関係になります。
Cookieを無効にするとログイン状態は維持できませんか。
Cookieが利用できない環境では、セッションIDをURLのパラメータに含めて引き回す方法も存在しますが、URLに識別子が露出するためセキュリティ上のリスクが高く、一般的には推奨されません。多くのWebサービスはCookieの利用を前提に設計されています。
セッションの有効期限はどのくらいに設定すべきですか。
一律の正解はなく、サービスの性質によって異なります。金融系など機密性の高いサービスでは短めの時間で自動的にログアウトさせる設計が一般的で、逆に利便性を重視するサービスでは比較的長めに設定されるケースもあるでしょう。取り扱う情報の重要度とのバランスで検討する必要があります。
SameSite属性を設定すればCSRF対策は不要になりますか。
SameSite属性はCSRF対策として有効な手段の一つですが、それだけで対策が完結するわけではありません。CSRFトークンの検証など、他の対策と組み合わせて多層的に防御することが望まれます。
著者：テレリモ総研編集部 鈴木 亮佑
Webシステムの認証基盤やセッション管理の設計・実装でお困りの際は、ニアショア開発によるコスト最適化と品質確保を両立するLASSICにご相談ください。要件のヒアリングから設計、実装まで伴走いたします。
