Parse raw Set-Cookie lines, expose effective attributes, and flag browser behaviors that commonly break auth and session flows.
`Path` を省略すると、ブラウザは Cookie を設定したリクエスト URL をもとに既定パスを推論します。この挙動は見落とされやすく、チームが想定したより狭いルートでしか Cookie が使えない原因になります。`Path=/` など明示的なスコープを付ける方が、意図もデバッグもはっきりします。
Set-Cookie ヘッダー検査ツールは、バックエンドが送ったつもりの設定ではなく、ブラウザが実際にどう解釈するかを考えるためのツールです。Cookie の不具合は、属性が 1 つ足りない、Path の既定値を誤解している、あるいはクロスサイトポリシーの組み合わせが本番だけで問題になる、といった形で起きることが多いです。
各 `Set-Cookie` 行を属性ごとに分解し、重要な警告を添えて見せることで、フロントエンドとバックエンドの受け渡し、障害対応、ローカル検証での Cookie デバッグをかなり短くできます。
ログやブラウザ開発者ツールに表示された `Set-Cookie` ヘッダーを、そのまま 1 行ずつ貼り付けます。ツールは Cookie 名と値を属性から分離し、実際のフラグを表示したうえで、`SameSite=None` なのに `Secure` がない、`Path` がない、セッション系に見えるのに `HttpOnly` がない、といった代表的な問題を警告します。
例:
入力: `refresh_token=def456; Path=/auth; HttpOnly; SameSite=None`
この場合、`SameSite=None` が付いているのに `Secure` がないことをツールが強調します。現代のブラウザではこの組み合わせが拒否されやすく、レスポンス自体は正常でも、クロスサイトのログインフローでは Cookie が保存されず、原因不明のログイン失敗に見えることがあります。1. ログイン Cookie がレスポンスにはあるのにブラウザ保存領域に出てこない理由を調べる。
2. 新しいセッション戦略を出荷する前に auth 用 Cookie の変更をレビューする。
3. クロスサイト redirect を含むフローで staging と production のレスポンスヘッダーを比較する。
4. `Path`、`SameSite`、`Secure`、`HttpOnly` の実務的な影響をチームに説明する。
現代のブラウザは、`SameSite=None` を宣言したクロスサイト Cookie に `Secure` が付いていない場合、その Cookie を拒否します。この 2 つは安全境界として扱われるため、`Secure` が欠けると実際の認証フローで Cookie が静かに失敗しやすくなります。
いいえ。これは生のヘッダー文字列だけを解析するローカルツールです。外部への送信がないため、staging の機密ヘッダーを貼ってもサーバーに送られません。
いいえ。HTTPS、第三者コンテキスト、iframe、redirect、ブラウザの保存ポリシーなど、実行環境も影響するため、ヘッダーだけで絶対判定はできません。ただし、このツールは実務で頻出する高インパクトな設定ミスをかなり早く見つけるのに向いています。