Cookie プレフィックス検証ツール｜__Host- / __Secure- の属性要件を行ごとに判定

Set-Cookie ヘッダを 1 行ずつ貼り付けると、__Host- と __Secure- プレフィックスが RFC 6265bis の属性要件を満たすかを行ごとに判定するツール。各行を PASS / FAIL バッジで示し、違反した行には理由と、Path・Domain・Secure・HttpOnly・SameSite といった属性の一覧を並べて開示する。サーバを立てず、手元の貼り付けだけで Cookie 設定ミスを洗い出せる。

💡 このツールについて

Cookie の名前に付ける __Host- と __Secure- は、ブラウザが属性要件を強制する「特権プレフィックス」だ。名前がこのプレフィックスで始まる Cookie は、要件を満たさない限りブラウザが Set-Cookie 自体を無視する。__Host- を付けたつもりが要件を 1 つ外しただけで Cookie が保存されず、ログインが通らない、という事故はここから生まれる。

要件は 2 つに分かれる。__Secure- は Secure 属性が付いていることだけを求める。__Host- はより厳しく、Secure に加えて Path=/（ちょうど /）であること、そして Domain 属性を一切付けないことを求める。Domain を付けないことで、その Cookie は発行した正確なホストにのみ送られ、サブドメイン経由の cookie tossing（別ホストから上位ドメインに Cookie を押し込む攻撃）を防ぐ。CDN やロードバランサを挟んで複数ホスト構成にすると、この差が見落とされやすい。

このツールは複数の Set-Cookie 行を一括で受け取り、各行のプレフィックスを検出して該当する要件だけを当てて判定する。違反した行には「__Host- は Domain 属性を付けてはいけない」のように具体的な理由を出すので、CI に投入する前のレビューや、本番ヘッダのコピーをそのまま貼っての確認に使える。

🧐 よくある質問

__Host- と __Secure- はどう違う? 要件の厳しさが違う。__Secure- は Secure 属性だけ。__Host- は Secure に加えて Path=/ ちょうどと Domain 属性なしを求める。__Host- の方が、特定ホストへ固定する保証が強い。

プレフィックスは大文字小文字を区別する? 区別しない。ブラウザは __Host- も __host-（小文字）も同じプレフィックスとして扱い、同じ要件を強制する。RFC 6265bis が大小無視の比較に統一したのは、Cookie 名を大小無視で比較するサーバを突いた回避（小文字版を Secure なしで送り込む攻撃）を防ぐためだ。本ツールも大小を無視して規則を当てる。

Path=/api の __Host- はなぜ FAIL になる? __Host- は Path=/（ルートちょうど）でなければならない。/api のような部分パスは要件を満たさず、ブラウザは Cookie を破棄する。サブパス固定が必要なら __Secure- を使う。

プレフィックスなしの行はどう扱われる? 特権プレフィックスを持たない行は、判定対象の要件がないため PASS として扱い、検出されたプレフィックスを「(プレフィックスなし)」と表示する。属性の確認用に属性表は表示する。

貼り付けた Cookie はどこかに送られる? すべてブラウザ内で解析され、入力した Set-Cookie ヘッダはサーバに送信されない。本番の Cookie 名や値をそのまま貼っても外部に出ない。

📚 プレフィックスが名前に埋め込まれている理由の豆知識

__Host- と __Secure- の巧妙さは、属性ではなく「名前そのもの」に要件を埋め込んだ点にある。Set-Cookie ヘッダはサーバからブラウザへ送られるが、ブラウザが後でその Cookie をサーバへ返すとき (Cookie ヘッダ) には名前と値しか乗らず、Secure や Path といった属性は付いてこない。だからサーバは「この Cookie は本当に Secure 付きで保存されたのか」を受信時に確認できない。プレフィックスはこの穴を塞ぐ発明だ。要件を名前の一部にしておけば、__Host-session という名前が届いた時点で、その Cookie が Secure かつホスト固定で保存されたことがブラウザの強制によって保証される。仕様上ブラウザは要件違反の Set-Cookie を黙って捨てるので、名前が届いた事実そのものが要件充足の証明になる。属性を追加するのではなく命名規約で安全性を担保するこの設計は、既存の Cookie ヘッダ書式を一切変えずに後方互換で展開できた理由でもある。