クッキー（Cookie）とは？-セッション管理の仕組みから企業リスク・法規制対応まで徹底解説【2026年版】|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年05月01日更新日時: 2026年05月01日

クッキー（Cookie）は「ログイン状態を保持する便利な仕組み」として一般ユーザーには広く知られています。しかし情報システム部門の担当者にとってクッキーは、情報漏洩・なりすまし・不正アクセス・法規制対応が交差する要注意領域です。

しかもその多くは、サーバへの侵入やマルウェア感染といった分かりやすい脅威ではなく、「正しく実装されていなかった」「管理対象として意識されていなかった」ことから問題が表面化します。本記事では、クッキーの基本的な仕組みを整理した上で、なぜそれが企業リスクになり得るのか、実際にどのような事故が起きてきたのかを国内外の事例を交えて解説します。

1 この記事のサマリー
2 クッキーとは何か—小さなデータが持つ大きな役割
3 なぜクッキーは攻撃の対象になるのか—「本人性」を代替する仕組みの脆弱点
4 クッキーの種類—企業リスクの観点で押さえるべき4つの分類
5 クッキーが絡んだ実際の事故—国内外の事例
6 対策の進め方—技術設定の前にやるべきこと
7 情シス担当者が意識すべき主要なクッキー属性
8 よくある質問（FAQ）
9 まとめ
10 参考情報

この記事のサマリー

クッキーとは、HTTPの「通信ごとに状態を忘れる」という制約を補い、ログイン状態維持・カート情報・ユーザー設定を保持するためにWebサイトがブラウザに保存する小さなデータです。
クッキーの中でも「セッションID」は本人確認の鍵そのものです。パスワードを知らなくても、セッションIDを盗めばログイン状態を乗っ取れます。この性質が攻撃者にとっての狙い目になります。
Yahoo大規模侵害（2012〜2013年）ではパスワードではなくCookieの偽造によって、パスワード不要で個人情報へアクセスされていたことが司法省の起訴で明らかになっています。
クッキーの種類（セッション/永続、ファーストパーティ/サードパーティ）によってリスクの性質が異なります。Googleは段階的にサードパーティクッキーの廃止を進めており、企業の広告・分析設計の見直しが求められています。
企業がまず取り組むべきことは技術設定の前に「どの業務システムが何の目的でクッキーを使っているか」の棚卸しです。その上でHttpOnly・Secure属性の設定、GDPR・CCPA等の法規制への対応を進めます。

クッキーとは何か—小さなデータが持つ大きな役割

クッキーとは、WebサイトがユーザーのブラウザにHTTPレスポンスを通じて保存する小さなデータのことです。

HTTPというプロトコルは本来、通信のたびに状態を忘れる設計になっています。いわゆる「ステートレス」な設計です。そのため、ログイン状態の維持やショッピングカート情報の保持、ユーザー設定の保存といった機能を実現するために、クッキーが使われてきました。

例えば社内ポータルにログインした後、別のページに遷移しても再ログインを求められないのは、ブラウザがサーバから受け取ったクッキーを次の通信時に自動で送り返しているためです。この「状態を持たせる」仕組みがWebアプリケーションの利便性を支えてきたといえます。

一方でクッキーの中身は基本的にユーザー側（ブラウザ）に保存されます。この点が、セキュリティやガバナンスの観点では常に問題になってきました。

なぜクッキーは攻撃の対象になるのか—「本人性」を代替する仕組みの脆弱点

クッキーそのものはプログラムではありません。実行されるコードではなく、単なるデータです。それでも攻撃対象になる理由は、クッキーが「本人性」を担保する材料として使われているからです。

多くのWebサービスでは、ログイン後に「セッションID」と呼ばれる識別子をクッキーに格納します。サーバ側はそのIDを見て「この通信は、先ほど認証されたユーザーから来ている」と判断します。

つまり、クッキーを盗まれる＝ログイン状態を盗まれることを意味します。パスワードを知らなくても、セッションが有効な間は本人として振る舞えてしまうのです。この仕組みが問題化したのが、XSS（クロスサイトスクリプティング）や中間者攻撃と結びついたケースです。

攻撃者は脆弱なWebページにスクリプトを仕込み、閲覧したユーザーのクッキーを外部に送信させます。特別なマルウェアをインストールさせる必要はまったくありません。ブラウザが正しく動作した結果として情報が流出してしまうのです。

米国のセキュリティ研究者ブライアン・クレブスが自身のブログ「Krebs on Security」で繰り返し指摘してきたのも、「クッキーは境界防御の外側にある認証情報」という点でした。社内ネットワークをどれほど厳重に守っていても、ブラウザに残ったクッキーまでは直接コントロールできない。その歪みが攻撃の余地を生みます。

クッキーの種類—企業リスクの観点で押さえるべき4つの分類

一口にクッキーといっても、その性質や用途はさまざまです。企業リスクの観点で押さえておきたい主な分類は以下の通りです。

セッションクッキーと永続クッキーとして、セッションクッキーはブラウザを閉じると削除される一時的なものです。対して永続クッキーは指定した有効期限まで端末に残ります。利便性を優先して永続クッキーを増やすほど、端末紛失や共有端末利用時のリスクが高まります。

ファーストパーティクッキーとサードパーティクッキーとして、ファーストパーティクッキーはアクセスしているサイト自身が発行するもので、ログイン状態の維持など主要な機能に使われます。サードパーティクッキーは広告配信事業者など第三者が発行し、ユーザー行動の追跡や広告最適化に使われてきました。

ただしサードパーティクッキーはプライバシー侵害の懸念から、Google ChromeやApple Safariが段階的に制限を進めています。Googleはサードパーティクッキーの廃止計画を複数回延期しながらも段階的な移行を進めており、広告・マーケティング目的でクッキーを活用してきた企業には対応が求められています。これは利便性と監視の境界線が社会的に問い直されている動きといえます。

クッキーが絡んだ実際の事故—国内外の事例

**Yahoo大規模侵害（2012〜2013年）**では、攻撃者がユーザーのパスワードを盗んだのではなく、ログイン済みユーザーを識別するCookieを偽造していたことが米司法省の起訴内容で明らかになっています。Cookieを用いることで、メールや個人情報にパスワード不要でアクセスできる状態が成立していました。

この事例が示したのは、パスワードや二要素認証がどれほど堅牢でも、認証後に発行されるCookieが突破されれば実質的に認証は意味をなさなくなるという現実です。セッション管理は補助的な仕組みではなく認証そのものの一部であるという認識が、米国で広く共有される契機となりました。

Twitter（現X）のセッションCookie問題では、2020年前後からセッションCookieの管理不備に起因するアカウント乗っ取りの問題が複数報告されました。特に問題となったのは、パスワードを変更した後であっても既存のセッションCookieが有効なまま残るケースが存在した点です。本来Cookieは一時的な識別子として設計されるべきものですが、実質的に恒久的な認証トークンとして機能していたといえます。Twitterはその後、セッションの失効条件やCookieの再発行ロジックを見直しましたが、「認証後の状態管理」がリスクになり得ることを示した事例です。

これら2件の共通点は明確です。パスワードが破られたわけではなく、認証後の状態が信用されすぎており、Cookieが「透明な存在」になっていました。

また、クッキーが直接の原因ではないものの、認証情報の管理という観点でクッキーと共通する問題を示した国内事例として以下も参照価値があります。2021年のLINE個人情報管理問題では、主因はアクセス権管理でしたが関連するWeb管理画面でのセッション管理の整理不足も指摘されました。2014年のベネッセ大規模情報漏洩は内部不正が原因でしたが、この事件以降「ログイン後のセッション管理」「誰がどこまでアクセスできるか」という視点が日本企業に広がっていきました。クッキーはその入り口に位置する技術です。

対策の進め方—技術設定の前にやるべきこと

クッキー対策というと、技術的な設定項目（HttpOnly属性・Secure属性・SameSite属性など）に意識が向きがちです。もちろんそれらは重要ですが、最初にやるべきことは別にあります。

ステップ1：クッキーの棚卸しとして、「どの業務システムで、どのような目的でクッキーを利用しているか」を洗い出します。ログイン維持なのか、利用状況分析なのか、外部広告連携なのか。目的を言語化しなければ、設定の是非も判断できません。

ステップ2：「認証情報の一部」として扱っているかの確認として、そのクッキーが単なる利便性データなのか本人確認の鍵（セッションID）なのかで、要求される管理レベルは大きく異なります。セッションIDを持つクッキーには少なくともHttpOnly属性（JavaScriptからのアクセスを遮断）とSecure属性（HTTPS通信のみで送信）を設定することが最低限の対策です。

ステップ3：法務・コンプライアンス部門との連携として、GDPRやCCPAといった米国・欧州の規制は日本企業にも無関係ではありません。特に海外向けWebサイトを運営している場合、クッキーの取得・利用に関する説明責任は避けて通れません。

情シス担当者が意識すべき主要なクッキー属性

クッキーには、セキュリティを強化するための属性が設定できます。主要なものを整理します。

HttpOnly属性はJavaScriptからクッキーへのアクセスを禁止します。XSSによるクッキー窃取を防ぐ最も基本的な設定で、セッションIDには必須です。

Secure属性はHTTPS通信の場合のみクッキーを送信します。HTTP通信での盗聴（中間者攻撃）によるセッションID窃取を防ぎます。

SameSite属性はCSRF（クロスサイトリクエストフォージェリ）対策として機能します。Strict・Lax・Noneの3段階があり、外部サイトからのリクエスト時にクッキーを送信するかどうかを制御します。

**有効期限（Expires/Max-Age）**は、永続クッキーが必要な場合でも必要最小限の有効期限を設定することが重要です。長期間有効なクッキーは、端末紛失・共有時のリスクを高めます。

よくある質問（FAQ）

Q. クッキーとセッションはどう違いますか？ クッキーはデータを保存する「場所（ブラウザ側）」のことで、セッションはサーバ側でログイン状態などを管理する「仕組み」のことです。多くのWebサービスでは、セッションを管理するためにセッションIDをクッキーに格納します。

Q. サードパーティクッキーが廃止されると何が変わりますか？ 広告配信・アクセス解析・A/Bテストなど複数のサイトをまたぐトラッキングに依存していた機能が動作しなくなります。Google Analytics 4（GA4）への移行やファーストパーティデータ戦略への転換が、マーケティング・システム部門の両方に求められます。

Q. HttpOnly属性を設定すれば絶対に安全ですか？ HttpOnly属性はXSSによるJavaScript経由のクッキー窃取を防ぎますが、すべてのリスクをカバーするわけではありません。中間者攻撃（Secure属性未設定の場合）や、XSS以外の方法（フィッシング等）での窃取は別の対策が必要です。複数の属性とセキュリティ対策を組み合わせることが重要です。

Q. GDPRはクッキーにどう関係しますか？ GDPR（EU一般データ保護規則）の下では、分析・広告・パーソナライズ等の目的で使用されるクッキーはユーザーの事前同意が必要です。同意なく設置された場合、制裁金の対象となります。日本でも個人情報保護法の改正によりクッキー等の識別子が個人情報に該当するケースへの対応が求められるようになっています。