Cookie・セッション管理のセキュリティ診断12項目（Secure・HttpOnly・SameSite・no-store）

Cookie・セッション管理の診断項目一覧（12項目）

セッションCookieの属性や、セッションIDの扱いを確認します。各項目名から、意味・診断基準・リスク・具体的な対策を解説したページへ移動できます。

Cookie・セッション管理の診断とは

Cookie・セッション管理の診断は、Webサイトが発行するCookieと、ログイン状態を示すセッションIDが、盗まれたり悪用されたりしにくい形で扱われているかを確かめるものです。セキュリティ診断127項目のうち、Cookieの属性、セッションIDの受け渡し方、ログイン画面などのキャッシュ制御に関する12項目がこの分類に入ります。

Cookieは、サーバーが Set-Cookie ヘッダーでブラウザに保存させる小さなデータです。ログインセッションでは、ランダムなセッションIDをCookieに入れて「ログイン済みの本人」であることを示します。このIDは合い鍵のようなもので、第三者に知られると、その人になりすましてログイン状態を乗っ取られるおそれがあります。

そこでCookieには、送信先や読み取りを制限する属性を付けます。Secure属性はHTTPSのリクエストにだけ送らせ、HttpOnly属性はJavaScriptからの読み取りを禁じ、SameSite属性は別サイトから始まったリクエストに付けて送るかを決めます。加えて、Domain属性による送信範囲、有効期間、__Host- などの接頭辞、サイズの上限にも守るべき条件があります。

さらに、セッションIDのURLへの混入や、ログイン画面などの応答のキャッシュといったセッションの周辺も、この分類で確認します。

なお、Cookie属性の各項目が観測するのはサーバーの Set-Cookie ヘッダーだけで、JavaScriptの document.cookie で設定されるCookieは対象外です。また、Cookieを1件も発行しないサイトでは、Cookie属性の項目は「対象外」となり、得点計算から除外されます。

12項目の全体像（4つのグループ）

この分類の12項目は、大きく4つのグループに分けて考えると整理しやすくなります。

最後のグループの2項目は、どちらも no-store を確認しますが対象が異なります。「機密ページのキャッシュ制御」は入力したURLそのものがログイン・管理・アカウント系のパスのときに評価し、「認証関連ページのno-store」はトップページと巡回で見つかったページのうち /login・/admin・/mypage などのパスで2xxを返したページを評価します。

優先して確認すべき項目

この分類には最重要（critical）の項目はありませんが、重要（high）の7項目は、セッションIDの漏えいやなりすましに直結するため最初に確認します。

1. セッションIDをURLへ含めていない：URLに入ったIDは、HTTPSで通信していても履歴・アクセスログ・Referer・URLの共有から漏れ、セッション固定攻撃にも使われます。1件でも見つかれば×です。
2. CookieのSecure属性：付いていないCookieは、http:// のURLを開いたときやページにhttp://の画像が混じったときに平文で送られます。1件でもSecureなしなら×です。
3. CookieのHttpOnly属性：XSSが起きてもセッションIDを外部へ持ち出されないための保険です。JavaScriptが読む必要のあるCookieもあるため、HttpOnlyなしのCookieは△（要確認）と判定し、セッションIDかどうかの確認を促します。
4. SameSite=NoneとSecureの組み合わせ：Secureの無いSameSite=NoneのCookieは改訂版Cookie仕様（rfc6265bis）で無視され、主要ブラウザは保存しません。予約ウィジェットやSSOが動かない原因にもなります。
5. Cookie接頭辞の要件：__Host- はSecure・Path=/・Domain属性なし、__Secure- はSecureが保存の条件です。条件を満たさないCookieは捨てられ、ログインできない不具合を招きます。
6. 機密ページのキャッシュ制御と認証関連ページのno-store：no-cache や private では保存自体を防げないため、ログイン・管理系の応答には no-store が必要です。

次に「中（medium）」の項目として、SameSite属性の明示、Domain属性の扱い、有効期間、Partitioned Cookieの要件、サイズ上限を見直します。SameSiteの未指定や1年を超える有効期間、Domain属性の付与は、公開情報だけでは用途を判断できないため△（要確認）にとどまりますが、セッションCookieであれば必ず直すべき設定です。

直すときの進め方と注意点

Cookieの属性は、付け方を誤るとログインできない、外部連携から戻るとログインが切れる、といった不具合につながります。次の順で進めると安全です。

• 先にサイト全体をHTTPS化する：Secure付きCookieはHTTPSの接続でしか設定・送信できません。HTTPのページが残っていると、そこではログインできなくなるため、HTTP→HTTPSの恒久リダイレクトとHSTSを先に整えます。
• セッションCookieを基準の形にそろえる：推奨形は __Host- 接頭辞を使い、Path=/・Secure・HttpOnly・SameSite=Lax を付け、Domain属性を出さない形です。PHPでは session.cookie_secure を有効にし、session.cookie_domain を空にします。Cookie名を変えると既存のログイン中セッションは引き継がれないため、利用の少ない時間帯に切り替えて周知します。
• URLでのセッションIDの受け渡しを止める：PHPは session.use_only_cookies = 1・session.use_trans_sid = 0 とし、ログイン成功時に session_regenerate_id(true) でIDを再発行します。
• SameSiteの値は用途ごとに決める：外部の決済代行やSSOからPOSTで戻る画面では、Laxだとセッションが送られずログインが切れることがあります。必要なCookieだけ SameSite=None; Secure にするなど個別に設定し、テスト環境で必ず確認します。
• 有効期間とサイズを見直す：セッションIDは期限を付けないセッションCookieにして、サーバー側のタイムアウトで管理します。Cookieにはランダムな識別子だけを入れ、データ本体はサーバー側に置きます。
• no-store は認証系のパスに限定する：サイト全体に付けると表示速度の低下やCDNの効果の喪失を招きます。また、no-store だけでは「戻る」ボタンの表示を完全には防げないため、ログアウト時にセッションCookieを確実に削除します。

自治体・公共機関のサイトで特に注意すること

自治体の公式サイトは、静的なページが中心でCookieを発行しないことも多く、その場合Cookie属性の項目は対象外になります。一方で、電子申請、施設予約、マイページ、外部の予約システムやチャットボットなど、Cookieを使う仕組みは公式サイトの周辺に多くあります。よくある注意点として、次のようなものがあります。

• 図書館・公民館・窓口の共用パソコンや庁内プロキシなど、キャッシュが第三者に見える環境が多く、ログイン画面やマイページの no-store が欠かせません。
• 部署ごとにサブドメインを運用し、Cookieの Domain 属性でログイン状態を共有していると、ほかのサブドメインにもセッションCookieが送られます。共有の仕組みをサーバー間連携へ移してから Domain 属性を外します。
• 外部の予約ウィジェットやSSOを埋め込むと、SameSite=None や Partitioned 属性が必要になることがあります。その場合は Secure の併記が必須です。
• Cookieを無効にした端末ではCookie専用のセッションでログインできなくなるため、利用者向けにCookieを有効にする手順を案内します。

トップページの診断ではログイン後の画面までは評価できません。電子申請や予約システムは、委託先に Set-Cookie の内容とキャッシュ制御を確認し、ブラウザの開発者ツールでCookieの属性を目視確認すると、こうした不備を防ぎやすくなります。

よくある質問（FAQ）

ほかの分類の診断項目

• 通信の暗号化（HTTPS・TLS・HSTS）13項目
• コンテンツセキュリティポリシー（CSP）10項目
• セキュリティヘッダー13項目
• CORS（クロスオリジン設定）5項目
• HTML・JavaScript・外部資産14項目
• HTMLの基本衛生7項目
• フォーム・パスワード入力9項目
• 認証・アクセス制御7項目
• DNS・メールのなりすまし対策10項目
• 公開ファイル・情報露出19項目
• HTTP応答・エラー処理6項目
• 巡回範囲・サプライチェーン2項目