Cookie接頭辞の要件とは？__Host-・__Secure-プレフィックスの条件と診断基準

Cookie接頭辞の要件とは

Cookie接頭辞の要件とは、Cookie名の先頭に __Secure- または __Host- を付けたときに、ブラウザがそのCookieを保存するために満たさなければならない属性の条件です（RFC 6265bis 第4.1.3節 Cookie Name Prefixes）。

サーバーはCookieを受け取ったとき、そのCookieがどの属性で作られたかを知ることができません。しかし接頭辞があれば、「この名前のCookieは条件を満たして作られたはず」と判断できます。

セキュリティAIチェッカーはこの項目で、接頭辞付きのCookieが実際にこれらの条件を満たして発行されているかを確認します。条件を満たさない接頭辞付きCookieは、対応ブラウザでは保存されずに捨てられます。そのため、ログインできない・セッションが維持されないといった不具合や、意図した保護が効いていない状態を示します。

推奨形

Set-Cookie: __Host-session=<ランダム値>; Path=/; Secure; HttpOnly; SameSite=Lax

サブドメイン間で共有する必要があるCookieだけ __Secure- にし、Domainを必要最小限に指定します。

__Host-と__Secure-は何を防ぐのか

接頭辞ごとの防御効果

• __Secure-：HTTP（非暗号化）のページや、中間者が差し込んだHTTP応答から、同名のCookieを上書きされることを防ぎます。
• __Host-：上記に加え、Domain属性を禁止することでサブドメインからの上書き（セッション固定、Cookieトス）を防ぎ、Path=/ に固定することで特定パスだけ別の値に差し替えられることを防ぎます。RFC 6265bis は __Host- を「Cookieを origin（ポートを除く）に可能な限り近い単位で扱うための組み合わせ」と説明しています。

OWASP ASVS 5.0.0 は、V3.3.1（Level 1）で「CookieにSecure属性を設定し、__Host- 接頭辞を使わない場合は __Secure- 接頭辞を使うこと」、V3.3.3（Level 2）で「他ホストと共有する設計でない限り __Host- 接頭辞を使うこと」を求めています。

大文字小文字の扱い（RFC 6265bis 第5.4節）

RFC 6265bis 第5.4節は、ブラウザ（UA）は接頭辞を大文字小文字を区別せずに照合しなければならない（MUST）と定めています。サーバー側がCookie名を大文字小文字を区別せずに扱う場合、__SeCuRe-SID のような名前で正規の __Secure-SID を偽装される攻撃があり得るためです。逆に言えば、__HOST-SID のような綴りで発行されたCookieにも __Host- の要件が適用されます。

新しい接頭辞について

HttpOnly を保証する __Http- などの追加の接頭辞も IETF で議論されていますが、RFC 6265bis-22 本文には含まれていません。本項目では __Secure- と __Host- のみを評価します。

Cookie接頭辞についてよくある誤解

• 「接頭辞を付ければSecure属性は不要」：誤りです。属性を付けていなければ、ブラウザはそのCookieを保存しません。
• 「__Host- ならPathは自由」：誤りです。Path=/ が必須で、Path=/shinsei などでは保存されません。
• 「Domain=自ホスト なら __Host- でも可」：誤りです。Domain属性があるだけで拒否されます。

Domain属性による送信範囲の広がりは「CookieのDomain/Path範囲」、Secure属性そのものは「CookieのSecure属性」で確認します。

Cookie接頭辞の要件の診断基準（セキュリティAIチェッカー）

取得方法

• トップページと同一オリジンの追加ページ（最大4ページ、ログイン・管理系リンクを優先）を GET で取得し、各最終応答の Set-Cookie ヘッダーを集めます。
• Cookie名の先頭を大文字小文字を区別せずに調べ、__Host- または __Secure- で始まるものを「接頭辞付きCookie」とします。
• 属性の照合も大文字小文字を区別せず、; 前後の空白を許容します。
• Secure は ; Secure のように値を伴わない形だけを認識します（Secure=1 は Secure なしとして扱います。RFC 6265bis の解析手順ではブラウザは値を無視して Secure 属性とみなしますが、本診断では値なしの形での記述を求めます）。

接頭辞ごとの違反条件

判定条件

接頭辞を使っていないこと自体は、本項目では減点しません。ASVS 5.0.0 V3.3.1 は Level 1 から接頭辞の使用を求めていますが、Secure属性の有無は「CookieのSecure属性」、Domain属性の有無は「CookieのDomain/Path範囲」で別に評価しています。接頭辞の導入は改善提案として示します。

得点への影響

自治体サイトでの判定例

Cookie接頭辞の要件を満たさないとどんなリスクがあるか

• 機能不全：要件違反の接頭辞付きCookieは対応ブラウザで保存されないため、ログインや申請の途中でセッションが切れる、CSRFトークンの照合が常に失敗するといった障害になります。ブラウザによって挙動が違うと、原因の特定に時間がかかります。
• 保護の誤認：開発者は「__Host- を付けたからサブドメインからの上書きは防げる」と考えていても、実際にはCookieが保存されていない、あるいは非対応環境向けに接頭辞なしの別Cookieへフォールバックしている場合、想定した防御が働きません。
• Cookieの上書き・セッション固定：接頭辞を正しく使えていないと、HTTP応答や別サブドメインから同名Cookieを植え付けられ、セッション固定やCSRF対策の回避につながります（RFC 6265bis 第8.6節）。

Cookie接頭辞の設定方法（PHP・Apache・nginx・ASP.NET Core・Next.js）

PHP

ini_set('session.name', '__Host-PHPSESSID');
session_set_cookie_params([
    'lifetime' => 0, 'path' => '/', 'domain' => '',
    'secure' => true, 'httponly' => true, 'samesite' => 'Lax',
]);
session_start();

Cookie名を変更すると、既存のログイン中セッションは引き継がれません。利用の少ない時間帯に切り替え、利用者に再ログインが必要になる旨を周知します。

Apache（アプリを直せない場合の確認・補正）

接頭辞付きCookieに属性が欠けている場合の暫定策として、mod_headers で属性を補えます。根本的にはアプリ側で修正してください。

<IfModule mod_headers.c>
  # __Host- / __Secure- Cookie に Secure が無ければ付与
  # mod_php・mod_proxy 経由の Set-Cookie は onsuccess 側、CGI・PHP-FPM（mod_proxy_fcgi）の
  # Set-Cookie は always 側の表に入るため、両方に書く（Secure があれば一致しないので二重付与しない）
  # (?i) で以降の照合を大文字小文字無視にする（Secure／secure どちらの表記でも二重付与しない）
  Header edit Set-Cookie "^((?i)__(?:Host|Secure)-(?:(?!;\s*secure\s*(?:;|$)).)*)$" "$1; Secure"
  Header always edit Set-Cookie "^((?i)__(?:Host|Secure)-(?:(?!;\s*secure\s*(?:;|$)).)*)$" "$1; Secure"
</IfModule>

正規表現での書き換えは誤爆しやすいため、適用前後で curl の出力を比較してください。

nginx

# nginx 1.19.3 以降：プロキシ先が発行した Cookie に属性を追加
proxy_cookie_flags ~^__(Host|Secure)- secure;
# Path や Domain の誤りはバックエンド側の設定で直す（nginx での一括書き換えは他の Cookie を巻き込みやすい）

IIS／ASP.NET Core

builder.Services.AddSession(o => {
    o.Cookie.Name = "__Host-session";
    o.Cookie.Path = "/";
    o.Cookie.SecurePolicy = CookieSecurePolicy.Always;
    o.Cookie.HttpOnly = true;
});

Cookie.Domain は設定しません。

Next.js

(await cookies()).set("__Host-session", token, {
  path: "/", secure: true, httpOnly: true, sameSite: "lax",
});

開発環境（http://localhost）ではSecure Cookieの扱いがブラウザにより異なるため、本番と同じHTTPSで動作確認します。

設定後の確認方法

curl -sI https://www.city.example.lg.jp/login | grep -i '^set-cookie: *__\(host\|secure\)-'

ブラウザの開発者ツールの Application → Cookies に該当Cookieが保存されているか、ネットワークタブで Set-Cookie に警告アイコン（ブロック理由）が出ていないかを確認します。

サイトを壊さないための注意点（ガードレール）

• __Host- へ移行すると Path=/ に固定され、同一ホスト上の複数アプリで同じCookie名を使っていると衝突します。アプリごとにCookie名を分けてください。
• ロードバランサーやWAFが Set-Cookie を書き換える（Domain付与など）構成では、__Host- Cookieが拒否されます。経路上の機器の設定も確認します。
• 段階導入として、まず新しい接頭辞付きCookieと旧Cookieを並行して発行し、接頭辞付きが保存されることを確認してから旧Cookieを廃止すると、障害を避けられます。

よくある質問（FAQ）

参考資料

• RFC 6265bis（draft-ietf-httpbis-rfc6265bis-22）
• IETF Datatracker draft-ietf-httpbis-rfc6265bis
• OWASP ASVS 5.0.0 V3 Web Frontend Security（V3.3.1・V3.3.3）
• OWASP WSTG-SESS-02 Testing for Cookies Attributes
• MDN Set-Cookie
• OWASP Session Management Cheat Sheet
• nginx proxy_cookie_flags ディレクティブ
• Apache HTTP Server mod_headers
• IPA「安全なウェブサイトの作り方」

「Cookie接頭辞の要件」と関連する診断項目

• CookieのDomain/Path範囲medium
• CookieのSecure属性high
• Partitioned Cookieの要件medium
• 同一オリジンを限定巡回info
• 機密ページのキャッシュ制御high
• CookieのHttpOnly属性high
• CookieのSameSite属性medium
• SameSite=NoneとSecureの組み合わせhigh