logo
GeekFormat

Set-Cookie パーサー

Set-Cookie パーサー

複数行の Set-Cookie レスポンスヘッダーを貼り付けて、属性を検査し、リスクのある SameSite / Secure の組み合わせをフラグします。

Cookie 属性カード

2 個の Set-Cookie
#1sessionabc123
path/
httponly(フラグ)
secure(フラグ)
samesiteLax
明らかな属性の問題は見つかりませんでした
#2preview1
max-age600 (10m 0s)

setCookieParser.attr.maxAgeHint

samesiteNone
secure(フラグ)
setCookieParser.warn.missingHttpOnlysetCookieParser.warn.missingPath

JSON プレビュー

[
  {
    "index": 0,
    "raw": "session=abc123; Path=/; HttpOnly; Secure; SameSite=Lax",
    "name": "session",
    "value": "abc123",
    "decodedValue": "abc123",
    "attributes": [
      {
        "key": "path",
        "value": "/"
      },
      {
        "key": "httponly",
        "value": null
      },
      {
        "key": "secure",
        "value": null
      },
      {
        "key": "samesite",
        "value": "Lax"
      }
    ],
    "attributeMap": {
      "path": "/",
      "httponly": true,
      "secure": true,
      "samesite": "Lax"
    },
    "warnings": []
  },
  {
    "index": 1,
    "raw": "preview=1; Max-Age=600; SameSite=None; Secure",
    "name": "preview",
    "value": "1",
    "decodedValue": "1",
    "attributes": [
      {
        "key": "max-age",
        "value": "600"
      },
      {
        "key": "samesite",
        "value": "None"
      },
      {
        "key": "secure",
        "value": null
      }
    ],
    "attributeMap": {
      "max-age": "600",
      "samesite": "None",
      "secure": true
    },
    "warnings": [
      "warn.missingHttpOnly",
      "warn.missingPath"
    ]
  }
]

Set-Cookieヘッダーを貼り付ければ、ブラウザがCookieを受け入れない理由がすぐにわかります。

関連おすすめ

ユースケース

  • ブラウザがCookieの書き込みを拒否したとき、SameSiteポリシーの問題か、Secureフラグの欠落か、Path/Domainの不一致かをすばやく特定
  • サードパーティログイン/SSO/埋め込みiframeシナリオでブラウザにブロックされたCookieをデバッグ。SameSite=NoneがSecureと正しく組み合わされているか確認
  • セキュリティ監査時、APIが返すCookieすべてにXSS窃取を防ぐHttpOnlyが設定されているか、HTTP平文送信を防ぐSecureが設定されているかを一括チェック
  • __Host-/__Secure-プレフィックスCookieを使用する際、RFC 6265bisの強制要件を満たしているか確認し、ブラウザによるサイレント破棄を回避
  • CHIPS(Partitioned Cookie)サードパーティCookieパーティショニングをデバッグする際、PartitionedとSecureが同時に宣言されているか確認
  • サーバーサイドでMax-Age/Expiresを設定するとき、値が有効であることを確認し、クロックスキューやMax-Age=0による即時期限切れを回避
  • 環境間(開発/ステージング/本番)のSet-Cookieヘッダーの違いを比較し、開発環境では正常に動作するのに本番環境でCookieが消えるという不可解な問題をデバッグ
  • DevToolsやcurlのレスポンスからレスポンスヘッダー全体を直接コピー。Set-Cookie:プレフィックスを手動で削除する必要はなく、ツールが自動的に除去
  • APIドキュメントの作成やWASM/WebWorkerリクエスト関連のバグをデバッグするとき、解析後のJSON結果をドキュメントに直接貼り付けてCookie構造を説明

特徴

  • 複数Cookieの独立解析:各行のSet-Cookieが独立したカードになり、番号付きで名前、値、URLデコード値を表示。問題のあるCookieが一目でわかります
  • 14項目のセキュリティ属性検出:SameSite=NoneにSecureがない、SameSite値が不正、PartitionedにSecureがない、HttpOnlyがない、Pathがない、SameSiteがない、__Host-プレフィックス違反、__Secure-にSecureがない、無効/ゼロのMax-Age、Domainの先頭ドット、Max-AgeなしのExpiresなどのよくあるミスを自動識別
  • 完全な属性分解:SameSite、Secure、HttpOnly、Path、Domain、Expires、Max-Age、Partitionedを項目ごとに一覧表示。フラグ型属性と値付き属性が一目瞭然
  • Max-Age自動換算:秒数を日/時間/分/秒の人間が読みやすい時間に自動換算。例えばMax-Age=2592000は30dと表示
  • URLデコード値の自動表示:Cookie値に%XXエンコーディングが含まれる場合、デコード後の原文(sessionID%3Dabc→sessionID=abcなど)を緑色の矢印で自動表示
  • RFC 6265bisプレフィックス検証:Path=/、Domain禁止、Secure必須など、__Host-および__Secure-プレフィックスCookieのコンプライアンス要件を厳密に検証
  • 元のヘッダーのワンクリックコピー:解析したすべてのCookieの元の行をまとめてコピーし、メール、Issue、ドキュメントに貼り付けてチームと共有可能
  • 構造化JSONプレビュー:解析結果はname/value/decodedValue/attributes/attributeMap/warningsの完全なフィールドを含むJSON形式で出力可能。スクリプトやテストケースで直接使用可能
  • 完全ローカル処理:Set-Cookieの内容はブラウザ内でローカル解析され、サーバーにアップロードされないため、機密性の高いSession、Tokenなどの情報漏洩を防止
  • スマート警告バッジ:各問題はオレンジ色の警告バッジで具体的な理由を表示。RFCを逐条的に調べる必要なし
  • 複数行一括入力:レスポンスヘッダー全体を一度に貼り付け可能(Chrome DevTools Networkパネルからコピーする場合など)。Set-Cookie:プレフィックスを自動的に除去して行ごとに解析
  • 引用符とセミコロンを含む値に対応:RFC仕様に準拠し、二重引用符で囲まれたCookie値やExpires日付のセミコロンを正しく処理。誤った分割を防止

使い方

  1. ブラウザのDevTools Networkパネルを開き、対象のリクエストを見つけ、Response HeadersセクションからSet-Cookieの内容をコピー(複数行対応。すべてのCookieを一度にコピー可能)
  2. コピーしたSet-Cookieレスポンスヘッダーを入力エリアに貼り付け。1行に1つのCookie(Set-Cookie:プレフィックスを手動で削除する必要はなく、ツールが自動的に除去します)
  3. ツールはリアルタイムで解析します。上部に検出されたSet-Cookieの数が表示され、下部に各Cookieが個別の属性カードとして表示されます
  4. カードヘッダーには番号、Cookie名、元の値が表示されます。値にURLエンコーディングが含まれる場合は、緑色の矢印の後にデコードされた値が表示されます
  5. カード本体にはSameSite、Secure、HttpOnly、Path、Domain、Max-Age、Expires、Partitionedなどの属性が項目ごとに表示されます。Max-Ageは自動的に括弧付きで人間が読みやすい時間に換算されます
  6. カードフッターには検査結果が表示されます。オレンジ色の警告バッジが具体的な問題を指摘し(各問題には明確な日本語の説明があります)、緑色のバッジは明らかな問題が見つからなかったことを示します
  7. サーバー設定と照合する必要がある場合は「元のヘッダーをコピー」をクリックして、すべての元のSet-Cookie行をコピーします。プログラムで処理する必要がある場合は「JSONプレビュー」を確認してください

よくある質問

Set-Cookieヘッダーの設定は成功したのに、ブラウザがCookieを保存してくれないのはなぜですか?

これは最も一般的な問題です。ブラウザは積極的にエラーを報告せず、準拠していないCookieを黙って破棄します。一般的な原因には、SameSite=NoneにSecureがない、HTTPページでSecure Cookieが設定された(localhost例外)、__Host-/__Secure-プレフィックスが制約を満たしていない、Domain/Pathが一致しない、4KBサイズ制限を超えている、Max-Ageが0または負であることが含まれます。まずSet-Cookieをこのツールに貼り付けて警告バッジで具体的な原因を特定し、次にChrome DevTools → Application → Cookiesを開いて、対応するドメインの下にある黄色い警告三角形を探し、ホバーすると具体的な拒否理由が表示されます。

SameSiteのStrict、Lax、Noneは具体的に何が違うのですか?いつどれを使えばよいですか?

Strictはクロスサイト送信を完全に許可せず、最も安全ですが、外部サイトのリンクからクリックしてくるとユーザーはログインしていないように見えます。支払い/パスワード変更などの機密操作のCookieに適しています。LaxはChrome 80以降のデフォルト値で、外部リンクからトップレベルGETナビゲーションでジャンプしてきたとき(外部サイトのリンクをクリックしてあなたのサイトに戻ってきたとき)にCookieの送信を許可しますが、iframe/img/script/XHR/POSTフォームなどのサブリソースでは送信されず、ほとんどのシナリオで推奨される値です。Noneはすべてのクロスサイトシナリオでの送信を許可します(SSOシングルサインオン、サードパーティ埋め込みiframe、クロスサイトAPI呼び出しに使用)が、Secureを同時に設定する必要があり、そうしないとブラウザは直接拒否します。

なぜSameSite=NoneはSecureと組み合わせる必要があるのですか?

これはChromeがバージョン80(2020年2月)から強制しているルールで、Firefox、Edge、Safariもすべて追従しています。SameSite=NoneはクロスサイトでのCookie送信を明示的に許可するため、攻撃者がクロスサイトシナリオでCSRFを仕掛けたり盗聴したりしやすくなります。リスクを軽減するためにSecure(HTTPS暗号化送信)と組み合わせる必要があります。SameSite=None CookieをHTTPで設定すると、ブラウザは保存せずに直接破棄します。このツールはSameSite=NoneにSecureがない組み合わせを検出し、赤い警告で表示します。

Max-AgeとExpiresのどちらを使うべきですか?違いは何ですか?

Max-Ageの使用を優先してください。Max-Ageは相対時間(N秒後に期限切れ)で、クライアントクロックに依存せず、ブラウザは受信後にカウントダウンを開始します;Expiresは絶対時点で、ユーザーのコンピュータのローカル時間に依存します(ユーザーが時計を1970年に設定するとCookieは即座に期限切れになります)。両方が存在する場合、Max-Ageが優先されます(RFC 6265で明確に規定されています)。どちらも設定しない場合、Cookieは「セッションCookie」になり、ブラウザを閉じると失効します。このツールはExpiresが設定されていてMax-Ageが設定されていない場合に、Max-Ageの追加を推奨するプロンプトを表示します。注意:Max-Ageの単位はミリ秒ではなく秒です。

Path=/とPathを設定しない場合の違いは何ですか?

Pathは、ブラウザがどのURLパスのリクエストにこのCookieを含めるかを決定します。Pathを設定しない場合、ブラウザはデフォルトで「レスポンスURLから最後のセグメントを除いたパス」を使用します。例えば/api/user/loginからCookieを設定する場合、デフォルトのPathは/api/user/であるため、/パスや/order/の下のリクエストにはこのCookieは含まれません。明示的にPath=/を設定すると、Cookieはサイト全体で有効になります。Pathマッチングはプレフィックスマッチングであることに注意してください。Path=/apiは/api/、/api/user、/api/v2/abcなどにもマッチします。__Host-プレフィックスCookieはPath=/が必須です。

Domainの先頭にドットがある場合(.example.comなど)とない場合の違いは何ですか?

最近のブラウザ(Chrome、Firefox、Edge、Safariの最新バージョン)では、両者は同等で、どちらもexample.comとそのすべてのサブドメイン(a.example.com、b.c.example.com)にCookieを有効にします。先頭のドットはRFC 2109時代の古い書き方で、RFC 6265では先頭のドットを明示的に無視することになっています。ただし、可読性のためにドットのない形式を推奨します。このツールは、先頭にドットがあるDomainについて通知します(エラーではありませんが、歴史的な古い書き方です)。注意:Domainを設定しない場合、Cookieは現在のホストにのみ有効で(サブドメインには有効になりません)、Domainを設定するとサブドメインにも有効になります。

__Host-および__Secure-プレフィックスとは何ですか?プレフィックスを書かなくても大丈夫ですか?

これらはRFC 6265bisで導入されたCookie名セキュリティプレフィックスで、高セキュリティCookieにハードな制約を加えるためのものです:ブラウザはCookie名が__Host-で始まるのを見ると、Secureが設定されていること、Path=/であること、Domainが設定されていないことを強制し、いずれかの条件を満たさないと保存を直接拒否します;__Secure-プレフィックスはSecureが設定されていることを要求し、その他の属性は設定可能です。プレフィックスを書かなくても動作します(ほとんどのCookieはプレフィックスを使用しません)が、セッション識別子や認証Tokenなどの高セキュリティCookieには__Host-プレフィックスの使用が強く推奨されます。サブドメイン/パスレベルでのCookie注入攻撃を防止できるからです。このツールは両方のプレフィックスのコンプライアンスを自動的に検出します。

HttpOnly Cookieは本当に安全ですか?XSSやCSRFを防げますか?

HttpOnlyはJavaScriptがdocument.cookieを介してCookie値を読み取ることを防止し、<strong>XSSセッション窃取の緩和</strong>における重要な防衛線ですが、万能ではありません:XSS攻撃者は依然としてユーザーのブラウザでリクエストを開始し(リクエストには自動的にCookieが含まれます)操作を実行できます(これはCSRFの領域です);HttpOnlyはCSRF攻撃も防御できません(SameSiteまたはCSRF Tokenとの組み合わせが必要です)。HttpOnly+Secure+SameSite=Lax/Strictの3点セットを同時に使用して初めて基本的なセキュリティレベルに達します。機密性の高いCookie(session、JWT、access_token)はHttpOnly必須とし、フロントエンドJSに読ませる必要がなければ読ませないでください。このツールはHttpOnlyがないCookieに警告を表示します。

Partitioned(CHIPS)Cookieとは何ですか?いつ使用する必要がありますか?

Partitionedは、ChromeがサードパーティCookieの廃止に備えて導入した新しい属性で、Cookies Having Independent Partitioned State(CHIPS)の略です。従来のサードパーティCookie(広告/埋め込みサービスが複数のサイトで設定するCookieなど)はグローバルに共有され、ユーザーをクロスサイトで追跡するために使用されていました。Partitionedを追加すると、ブラウザはそのサードパーティCookieをトップレベルサイトごとに個別に保存します:ユーザーがAサイトで見るサードパーティCookieとBサイトで見るものは完全に独立しており、クロスサイトで身元を共有できません。使用シナリオ:埋め込み動画/地図/決済コンポーネント、サードパーティチャットプラグイン、クロスサイトSSO埋め込みiframe。Partitionedを使用するにはSecureを同時に設定する必要があり、__Host-プレフィックスとの併用が推奨されます。

1つのCookieには最大どれくらい保存できますか?ドメインごとにいくつ配置できますか?

RFC 6265によると、ブラウザはCookieあたり少なくとも4096バイト(名前、値、属性を含む)をサポートする必要があります。メジャーなブラウザ(Chrome/Firefox/Safari/Edge)はすべてこの上限を適用しており、超過分は黙って切り捨てられるか破棄されます。数の制限はブラウザによって異なります:Chromeはドメインあたり約180個、Firefoxは約150個、Safariは約600個(かつITPの7日クリーンアップポリシーの影響を受ける)で、超過するとブラウザはLRU戦略で最も古いCookieを削除します。Cookieにはセッション識別子のみを保存し、大量の業務データをCookieに入れないことを推奨します(業務データはlocalStorageまたはサーバーサイドセッションに保存してください)。

Chrome DevToolsから直接コピーしたSet-Cookieの解析に対応していますか?手動でプレフィックスを削除する必要がありますか?

完全に対応しており、手動処理は不要です。Chrome DevTools → Networkパネルで対象のリクエストをクリックし、Response HeadersセクションでSet-Cookieの値を右クリックして直接コピーできます(複数行の場合はCtrl/⌘+クリックで複数選択するか、全体をコピー)。そのままこのツールの入力エリアに貼り付けてください。ツールは各行の先頭にあるSet-Cookie:プレフィックスを自動的に(大文字小文字を区別せずに)除去し、行頭行末の空白を処理し、Expires日付に含まれるカンマ、セミコロンなどの特殊文字を正しく処理し、二重引用符で囲まれたCookie値も正しく処理します。

Cookie値の日本語や特殊文字がなぜ%XX形式になるのですか?

RFC 6265では、Cookie値はASCII文字セットの安全なサブセットのみを使用する必要があり、日本語、スペース、カンマ、セミコロンなどを直接含めることはできません。多くのサーバーサイドフレームワークは、Cookieを設定するときに非ASCII文字を自動的にURLエンコード(encodeURIComponent/パーセントエンコーディング)します。例えば「こんにちは」は%E3%81%93%E3%82%93%E3%81%AB%E3%81%A1%E3%81%AFにエンコードされます。ブラウザが送り返すときもエンコードされた形式のままです。このツールは値に%XXエンコーディングが含まれていることを検出すると、元の値の横に緑色の矢印でdecodeURIComponentでデコードされた原文を自動的に表示し、実際の内容を確認しやすくします。

Set-CookieとCookieリクエストヘッダーの違いは何ですか?

両者は完全に逆方向のヘッダーです:Set-Cookieはレスポンスヘッダー(サーバー→ブラウザ)で、レスポンスにのみ出現し、複数回出現でき、毎回1つのCookieを完全な属性(Secure/HttpOnly/Path/Domainなど)付きで設定します;Cookieはリクエストヘッダー(ブラウザ→サーバー)で、リクエストごとに1回だけ出現し、現在スコープに一致するすべてのCookieのフラットなname=valueペア(name1=v1; name2=v2)が含まれ、属性情報はまったく含まれません。つまり、サーバーはリクエストからCookieにHttpOnlyやSecureが設定されているかどうかを知ることはできず、属性情報はブラウザがローカルに保存するときにのみ保持されます。Cookieリクエストヘッダーを解析するには、付属の<a href='/network/http-cookie-parser/'>Cookieリクエストヘッダーパーサー</a>を使用してください。

なぜSafariでCookieが数日後に消えてしまうのですか?

これはSafariのインテリジェントトラッキング防止(ITP: Intelligent Tracking Prevention)メカニズムが動作しているためです。ITP 2.1以降、ユーザーが7日間そのドメインと直接インタラクションしていない(つまり、そのドメインのサイトに直接アクセスしていない)場合、SafariはMax-Age/Expiresの設定に関係なく、そのドメイン配下のすべてのCookieとWebサイトデータをクリーンアップします。これはサードパーティ埋め込みサービスに最も大きな影響を与えますが、メインサイトのCookieはユーザーがアクセスし続ける限り影響を受けません。さらに、SafariのサードパーティCookieに対する制限はChromeよりも厳格です。解決策には、Partitioned属性の使用、Storage Access APIを介した権限の要求、ユーザーがメインサイトにアクセスしたときにCookieを更新することなどが含まれます。このツールのトラブルシューティングセクションには、Safariデバッグに関するより詳細なガイドがあります。

ツールは複数のSet-Cookieの一括解析に対応していますか?Cookieの内容はサーバーにアップロードされますか?

一括解析に対応しています。入力エリアには任意の数の複数行Set-Cookieを貼り付けることができ(例えば、レスポンスヘッダー全体を一度に貼り付け)、各Set-Cookieは独立した番号で解析され、複数の属性カードにそれぞれの属性と警告が表示されます。すべての解析プロセスは完全にブラウザ内でローカルに完了し(純粋なフロントエンドJavaScript処理)、Cookieの内容はいかなるサーバーにもアップロードされず、ネットワークリクエストも送信されません。貼り付けたSession/Tokenなどの機密情報はお使いのコンピュータから外に出ることはないので、安心してご利用いただけます。

术语表

Set-Cookie
HTTPレスポンスヘッダー。サーバーがこれを介してブラウザにCookieの保存を指示し、1つのレスポンスに複数回出現できます。
Cookie(リクエストヘッダー)
HTTPリクエストヘッダー。ブラウザが自動的に添付するスコープ要件を満たすCookieの名前と値のペアのリストで、属性は含まれません。
HttpOnly
Cookie属性フラグ。設定すると、JavaScriptがdocument.cookieを介してCookieを読み取ることができなくなり、主にXSSセッション窃取を防御します。
Secure
Cookie属性フラグ。設定すると、ブラウザはHTTPS(またはlocalhost)暗号化接続でのみCookieを送信します。
SameSite
クロスサイトリクエストでCookieを送信するかどうかを制御するCookie属性。値はStrict/Lax/None。Chrome 80以降のデフォルトはLax。
Max-Age
Cookieの有効期間を秒単位で指定するCookie属性。Expiresより優先され、使用が推奨されます。=0は即座に削除することを意味します。
Expires
Cookieの有効期限の具体的な時点(HTTP-date)を指定するCookie属性。クライアントのクロックに依存します。
Path
Cookieが有効なURLパスプレフィックスを制限するCookie属性。デフォルトはレスポンスURLのディレクトリ部分です。
Domain
Cookieが有効なドメインを制限するCookie属性。設定しない場合は現在のホストのみ、設定するとサブドメインにも有効になります。
Partitioned(CHIPS)
サードパーティCookieのパーティション化された保存を有効にするCookie属性フラグ。ChromeがサードパーティCookieを廃止した後の代替方式で、Secureと組み合わせる必要があります。
__Host-プレフィックス
Cookie名プレフィックスのセキュリティ制約。Secure、Path=/、Domain属性なしが必須で、違反するとブラウザは保存を拒否します。
__Secure-プレフィックス
Cookie名プレフィックスのセキュリティ制約。Secureの設定が必須で、違反するとブラウザは保存を拒否します。
セッションCookie(Session Cookie)
Max-AgeとExpiresが設定されていないCookie。ブラウザを閉じると自動的に削除されます。
サードパーティCookie(Third-party Cookie)
現在アクセスしているページのドメイン以外のドメインで設定されたCookie。通常、広告、トラッキング、埋め込みiframeなどのサードパーティサービスによって設定され、各ブラウザで段階的に制限されています。

SameSite 3つの戦略の比較早見表

Set-Cookie属性完全リファレンス表(RFC 6265bis)

一般的なブラウザのSet-Cookieサイズと数の制限

Troubleshooting