Partitioned Cookieの要件とは？Secure必須のルール・CHIPSの仕組み・診断基準

Partitioned Cookieの要件とは

Partitioned Cookieの要件とは、Set-Cookie に Partitioned 属性を付けたCookie（Partitioned Cookie）は、必ず Secure 属性と一緒に指定しなければならないというルールです。

Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;

Partitioned は、Cookieを「トップレベルサイトごとに別々の保存領域（パーティション）」へ格納させるための属性です。Googleが主導したCHIPS（Cookies Having Independent Partitioned State）提案で導入されました。SafariやFirefoxがサードパーティCookieを既定で制限する中で、地図・チャット・決済などの「埋め込みウィジェット」が、埋め込み先サイトごとに独立した状態を保持できるようにする仕組みです。Chromeは2025年4月にサードパーティCookieの廃止を見送りましたが、CHIPSの提供は継続しています。

MDNは「Partitioned cookies must be set with Secure」と明記し、Chrome向けのPrivacy Sandbox解説も同じ要件を示しています。Privacy CGのCHIPS解説文書（explainer）は、Partitioned を持ち Secure を持たないCookieについて「Cookieを丸ごと無視する（ignore the cookie entirely）」手順を定めており、Chromeでもそのような Cookie は保存されません。開発者が意図した動作にはなりません。

セキュリティAIチェッカーのこの項目は、診断で観測したすべての Set-Cookie のうち Partitioned を含むものについて、Secure 属性が付与されているかを確認します。自治体公式サイトの多くはPartitioned Cookieを使っていないため「対象外」になるのが普通です。一方、外部の予約システム・チャットボット・アンケートフォーム・地図などを iframe で埋め込み、その提供元が自サイト側の応答でCookieを発行している場合などに該当することがあります。

Partitioned Cookie（CHIPS）はどういう仕組みか

パーティション化の仕組み（double-keyed）

通常のCookieは「Cookieを設定したホスト（またはDomain属性で指定したドメイン）」だけをキーに保存されます。そのため、widget.example のCookieは、city-a.lg.jp に埋め込まれても city-b.lg.jp に埋め込まれても同一のCookieとして送信され、サイト横断の追跡に使えてしまいます。

Partitioned を付けたCookieは「設定したオリジン」と「その時のトップレベルサイト」の二つでキー付けされます（MDNは double-keyed と表現しています）。パーティションキーは、Cookieが設定された時点でブラウザが表示していたトップレベルURLの「サイト」（スキームと登録可能ドメイン）です。結果として、

• city-a.lg.jp に埋め込まれた widget.example のCookie
• city-b.lg.jp に埋め込まれた widget.example のCookie

は別物として保存され、互いに参照できません。利便性を保ちながら、サイト横断の追跡を防げます。

なぜSecureが必須なのか

Privacy Sandboxの解説は「Partitioned cookies must be set with Secure」とし、Privacy CGのCHIPS解説文書は Secure の無いPartitioned Cookieを丸ごと無視する手順を示しています。同文書は設計原則として「Partitioned Cookieは安全なプロトコルでのみ設定・送信されなければならない」とし、Cookieの機密性・完全性の弱さ（6265bisのWeak Confidentiality・Weak Integrity）への対策の一部と位置付けています。パーティション化は新しい保存モデルであり、仕様策定の段階から平文HTTP上の利用を想定していません。中間者がHTTP応答にCookieを注入したり、HTTP通信で送信されたCookieを盗聴したりする余地を最初から排除するための設計です。

ブラウザ対応と容量の制約

• Chromeは114でCHIPSを既定で有効化しました（Privacy Sandbox公式解説）。Firefoxは141、Safariは26.2で対応しました。
• MDNはPartitioned Cookieを「Baseline 2025（2025年12月から新たに利用可能）」として扱っています。
• Chromeでは1パーティションあたり最大180個、かつ埋め込みサイトごとに10KBまでという上限が示されています（Privacy Sandbox公式解説）。大きな値を入れると保存されないおそれがあります。1つのCookieの大きさは「Cookie名・値のサイズ上限」でも確認します。

__Host- 接頭辞との関係

Privacy Sandboxの解説は、Partitioned Cookieには __Host- 接頭辞の利用を推奨しています（必須ではありません）。__Host- は「Secure必須・Domain属性なし・Path=/」を強制するため、Cookieをホスト名に固定でき、サブドメインからの上書き（Cookie Tossing）も防げます。MDNの例も Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned; の形です。接頭辞そのものの要件は「Cookie接頭辞の要件」で確認します。

Partitioned Cookieについてよくある誤解

• 「Partitionedを付ければSameSite=Noneは不要」：PartitionedとSameSiteは別の仕組みです。クロスサイトのiframe内でCookieを送るには、通常 SameSite=None も必要です。ただし仕様上 SameSite=None はPartitionedの必須条件ではないため、本項目では判定条件にしていません。SameSite=NoneとSecureの関係は「SameSite=NoneとSecureの組み合わせ」で確認します。
• 「Partitionedはセキュリティ強化属性」：主目的は追跡防止です。HttpOnly・SameSiteの代わりにはなりません。
• 「Secureは後から付ければよい」：Secureが無い状態ではCookie自体が保存されず、エラー表示も無いため、埋め込み時の不具合の原因が分かりにくくなります。最初からSecure付きで発行します。

なお、Partitionedの有無にかかわらず、Cookie全般のSecure属性は「CookieのSecure属性」の項目で評価しています。このページはPartitioned属性を使うCookieに固有の要件だけを扱います。

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

取得対象

1. トップページ（入力URLからリダイレクトを最大4回追跡した最終URL）の応答。
2. トップページのHTMLから抽出した同一オリジンのリンク・GETフォーム送信先・/api/ 候補のうち、ログイン系パスを優先して最大4ページ（合計最大5ページ）をGETで取得した応答（リダイレクトは最大3回）。
3. 各応答の Set-Cookie ヘッダーを Headers.getSetCookie() で1件ずつ取得します（未対応環境では、カンマ区切りを name=value の直前で分割するフォールバック）。

リダイレクト途中の応答（301/302など）に含まれる Set-Cookie は観測対象外です。ログイン後にのみ発行されるCookieも観測できません。

判定条件

• 属性は ; で区切った各要素の属性名で判定します。Cookie仕様（6265bis §5.6）の解析手順と同じく、属性名の前後の空白と大文字小文字の違いは許容し、Secure=1 のように値が付いていても Secure 属性として扱います。
• 重大度はmedium、重みは2です。Cookieが観測されない場合、またはPartitioned Cookieが無い場合は採点から除外されます。
• 合格時の根拠欄には「N件すべてSecureです」と表示します。

自治体サイトでの判定例

施設予約の例では、仕様に従うブラウザはこのCookieを保存しないため、埋め込み時の動作不良の原因にもなります。

判定の限界

公開ページの観測のみで行うため、ログイン後やJavaScript（document.cookie）で設定されるCookieは対象外です。サードパーティのiframeが自身のドメインで発行するCookieは、自治体サイトの応答には現れないため、本項目では評価されません。

Partitioned CookieにSecureが無いとどんなリスクがあるか

• 意図した動作にならない：Secure の欠落したPartitioned Cookieは仕様上無視されるため、開発者が「パーティション化して保存できている」と考えていても、実際にはCookieが存在しない状態になります。
• 平文通信での漏えい：HTTPページやHTTP経由のリクエストが混在する環境で、Secure属性のないCookieは平文で送られ、公衆無線LAN等で盗聴されるおそれがあります（CWE-614）。セッションIDであれば、なりすましに直結します。
• 埋め込み機能の障害：サードパーティCookieが制限されるブラウザ環境では、正しく設定されていないCookieに依存した埋め込みウィジェット（チャット、予約、決済）がログイン状態を保持できず、住民サービスの利用不能として表面化します。

Partitioned属性の誤設定そのものを原因とする公表された被害事例は確認できていません。

Partitioned Cookieの設定方法・対策（Apache・nginx・IIS・PHP・Next.js）

基本方針

1. Partitioned を付けるCookieには必ず Secure を付ける。
2. サブドメイン間で共有する必要がなければ __Host- 接頭辞を付け、Path=/・Domain属性なしにする。
3. クロスサイトのiframe内で使う場合は SameSite=None を併用する。
4. セッションIDなどスクリプトから読む必要のない値には HttpOnly を付ける。
5. そもそもパーティション化が必要か（埋め込まれる側か）を確認し、不要なら属性を外す。

Apache（.htaccess / mod_headers）

アプリケーションの修正が第一ですが、緊急対応としてヘッダーを書き換える方法があります。

<IfModule mod_headers.c>
  # Partitionedを含みSecureを含まないSet-CookieにSecureを追加
  Header edit Set-Cookie "(?i)^(?!.*;\s*secure)(.*;\s*partitioned.*)$" "$1; Secure"
  Header always edit Set-Cookie "(?i)^(?!.*;\s*secure)(.*;\s*partitioned.*)$" "$1; Secure"
</IfModule>

アプリケーションが出力するCookieは通常の表、エラー応答等は always の表に入るため2行とも記述します。必ず検証環境で curl -I の結果を確認してから反映してください。

nginx

# nginx 1.19.3以降: proxy_cookie_flags で属性を付与
location /app/ {
    proxy_pass http://backend;
    proxy_cookie_flags ~ secure;
}

バックエンドが発行する全Cookieに Secure が付くため、サイト全体のHTTPS化を先に確認します。

IIS（web.config / URL Rewrite）

<rewrite>
  <outboundRules>
    <rule name="Partitioned cookies must be Secure">
      <match serverVariable="RESPONSE_Set_Cookie" pattern="^(?!.*;\s*secure)(.*;\s*partitioned.*)$" />
      <action type="Rewrite" value="{R:1}; Secure" />
    </rule>
  </outboundRules>
</rewrite>

PHP

PHP 8.5以降は setcookie() のオプション配列で 'partitioned' => true を指定できます（secure が無いとエラー）。8.4以前では header() で直接 Set-Cookie を書きます（第2引数 false で既存のSet-Cookieを上書きしない）。

<?php
header('Set-Cookie: __Host-widget=' . rawurlencode($id)
  . '; Path=/; Secure; HttpOnly; SameSite=None; Partitioned', false);

Next.js（App Router / Route Handler）

import { NextResponse } from "next/server";

export async function GET() {
  const res = NextResponse.json({ ok: true });
  res.cookies.set({
    name: "__Host-widget",
    value: crypto.randomUUID(),
    path: "/",
    secure: true,
    httpOnly: true,
    sameSite: "none",
    partitioned: true,
  });
  return res;
}

partitioned オプション未対応のバージョンでは res.headers.append("Set-Cookie", "...") で直接出力します。

CMS・外部サービス

CMSのプラグインや外部委託システムがCookieを発行している場合は、ベンダーへ「Partitionedを使うならSecure必須」「不要なら外す」ことを仕様として依頼します。

設定後の確認方法

# 応答のSet-Cookieを確認
curl -sI https://www.city.example.lg.jp/ | grep -i '^set-cookie'

# Partitionedを含むのにSecureが無い行を抽出
curl -sI https://www.city.example.lg.jp/app/ \
  | grep -i '^set-cookie' | grep -i 'partitioned' | grep -vi '; *secure'

ブラウザの開発者ツール（Application → Cookies）では、Partitioned Cookieにパーティションキーが表示されます。空欄ならパーティション化されていません。設定後はセキュリティAIチェッカーで再診断し、根拠欄が「すべてSecure」になっていることを確認します。

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

• サイト全体がHTTPSで配信されていることを先に確認します。HTTPページが残っていると、Secure CookieはそのページではCookieとして扱われず、ログインが切れる等の不具合が出ます。
• __Host- へ名前を変える場合、旧Cookie名を読んでいるコードをすべて改修してから切り替えます。
• Partitioned Cookieは容量上限が小さいため、識別子のみを保存し、データ本体はサーバー側に置きます。

よくある質問（FAQ）

参考資料

• MDN Web Docs「Cookies Having Independent Partitioned State (CHIPS)」
• Privacy Sandbox「Cookies Having Independent Partitioned State (CHIPS)」
• Privacy CG「CHIPS」解説文書（explainer）
• IETF HTTP WG「draft-ietf-httpbis-rfc6265bis」
• OWASP ASVS 5.0.0 V3 Web Frontend Security
• OWASP Web Security Testing Guide

「Partitioned Cookieの要件」と関連する診断項目

• Cookie名・値のサイズ上限medium
• Cookie接頭辞の要件high
• SameSite=NoneとSecureの組み合わせhigh
• CookieのSecure属性high
• 同一オリジンを限定巡回info
• 機密ページのキャッシュ制御high
• CookieのHttpOnly属性high
• CookieのSameSite属性medium