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"
    ]
  }
]

ブラウザがCookieを受け入れないのは、多くの場合、値が間違っているのではなく、Set-Cookie属性が間違っているからです。

関連おすすめ

HTTPクッキー解析ツール

Cookieパーサー

セキュリティヘッダー検査

CORS インスペクター

認証ヘッダー生成

cURL コードジェネレーター

Set-Cookieパーサーとは何ですか？

Set-Cookieパーサーは、HTTPレスポンスヘッダー内の`Set-Cookie`コンテンツ専用のデバッグツールです。単に1行のテキストをセミコロンで分割するのではなく、開発者が次のことを判断するのを支援します：サーバーのこのCookie設定は正しいか、ブラウザが受け入れなかったのはなぜか、どの属性の組み合わせにセキュリティまたは互換性のリスクがあるか、現在のSet-Cookieはクロスサイト、SSO、iframe、サードパーティCookie、セッションシナリオに適しているか。

リクエストヘッダー内のCookieとは異なり、Set-Cookieはサーバーが「ブラウザに送信する構成命令」です。これには`name=value`だけでなく、SameSite、Secure、HttpOnly、Path、Domain、Expires、Max-Age、Partitionedなどの属性も含まれます。これらのフィールドは、ブラウザが書き込むかどうか、いつ失効するか、どのパスとドメインで有効か、クロスサイトリクエストで送信できるかどうかを直接決定します。そのため、「ログイン状態が失われる」「ブラウザがCookieを送信しない」「クロスオリジンシナリオで無効」といった多くの問題の根本原因は、値自体ではなくSet-Cookieの属性設定にあります。

このページの価値は、これらの属性を元のレスポンスヘッダーから構造化して抽出し、ブラウザの実際のルールに基づいて静的チェックを行うことにあります。例えば、SameSite=NoneにSecureがないか、PartitionedがSecureと組み合わせられているか、__Host-プレフィックスにDomainが誤って設定されていないか、Max-Ageが無効または0でないか、ExpiresにMax-Ageがないかなどです。これらの問題はブラウザが構文エラーのように直接通知することは通常なく、黙って拒否するか「単に有効にならない」という形で現れるため、ツールによるチェックが非常に重要です。

リクエストに現在どのCookieが含まれているかだけを知りたい場合は、このページにとどまらず、リクエストヘッダーの分解により適した「HTTP Cookieパーサー」を参照してください。このページは「ブラウザがなぜ書き込まなかったのか」「サーバーのこのCookie設定に隠れたリスクはないか」「クロスサイトとセキュリティ属性の組み合わせは適切か」といったレスポンスヘッダーのトラブルシューティングシナリオにより適しています。

ユースケース

  • ブラウザがCookieを拒否するときに、SameSite、Secure、HttpOnly、Path/Domainのどの設定に問題があるかをすばやく特定
  • サードパーティログイン、SSO、iframe埋め込み、クロスサイトリクエストシナリオで、SameSite=NoneがSecureと正しく組み合わせられているかを確認
  • セキュリティ監査時に、インターフェースが返すCookieにHttpOnlyやSameSiteの欠落、または高リスクな属性の組み合わせがないかを一括チェック
  • __Host-/__Secure-プレフィックス付きCookieがブラウザの強い制約を満たし、黙って破棄されることを回避するための検証
  • Partitioned Cookie/CHIPSの3パーティパーティションソリューションをデバッグするときに、PartitionedとSecureが同時に宣言されているかを確認
  • 開発、テスト、本番環境のSet-Cookieレスポンスヘッダーの違いを比較し、環境切り替え後のログイン状態の異常をトラブルシューティング

使い方

  1. ブラウザのDevTools、パケットキャプチャツール、またはサーバーログからSet-Cookieレスポンスヘッダーの内容をコピーする（複数行対応）
  2. 入力エリアに貼り付けると、ツールが自動的に`Set-Cookie:`プレフィックスを除去し、行ごとに解析
  3. 各Cookieの名前、値、URLデコード値、属性カード、警告ラベルを確認
  4. 元のヘッダーをコピーするかJSONプレビューを表示して、結果をバックエンドに送信するか、Issueやテストスクリプトに貼り付ける

特徴

  • 複数のSet-Cookieを独立して解析：各行を個別のカードとして表示し、名前、生の値、URLデコード値、属性を1つずつ確認可能
  • 14種類の一般的な問題を自動チェック：SameSite、Secure、HttpOnly、Path、Domain、Max-Age、Expires、__Host-/__Secure-プレフィックス、Partitionedなどの頻出リスクを網羅
  • 完全な属性分解：SameSite、Secure、HttpOnly、Path、Domain、Expires、Max-Age、Partitionedなどのフィールドごとに構造化して表示
  • Max-Ageを人間が読みやすく換算：秒数を自動的に分、時間、日に変換し、手動での換算コストを削減
  • 複数行の一括入力：DevToolsやパケットキャプチャツールからコピーしたSet-Cookieレスポンスヘッダー全体を直接貼り付け可能
  • 元のヘッダーのコピーとJSONプレビュー：バックエンドに送り返すのにも、ドキュメント、Issue、スクリプト、テストケースの作成にも便利
  • ローカルでアップロードなし：機密性の高いSession、Token、ログイン状態のCookieはブラウザ内で解析され、デバイスから外部に出ません

Set-Cookieパーサーを使うべき場合と他のページを使うべき場合は？

「サーバーが何を設定したか」を見ることと「リクエストに実際に何が含まれているか」を見ることは別のことであり、混同しないでください。

ツール適した入力最適な用途主な強み
Set-Cookieパーサー（このページ）Set-CookieレスポンスヘッダーブラウザがCookieを受け入れない、クロスサイトで有効にならない、セキュリティ属性設定にリスクがある場合のトラブルシューティング属性の分解が完全で、14種類の頻出する設定ミスを自動的にチェック
HTTP CookieパーサーCookieリクエストヘッダー、document.cookieリクエストに実際にどのCookieが含まれているか、値がURLエンコードされているか、名前の重複がないかを確認するリクエストヘッダーの名前と値のペアの分解と標準化された出力により特化HTTP Cookieパーサーを開く
CookieパーサーCookie文字列とSet-Cookieの混合トラブルシューティングシナリオ手元のデータのソースが不明な場合、または1つのページでCookie/Set-Cookieの2つのモードをすばやく切り替えたい場合Cookieデバッグの総合的なエントリーポイントのようなもので、Netscape Cookie File形式でのエクスポートもサポートCookieパーサーを開く

Best Practices

問題が「設定の失敗」か「リクエストに含まれない」かを最初に判断する

ブラウザがCookieをまったく書き込まない場合は、このページを優先的に参照してください；ブラウザはすでに書き込んでいるが後続のリクエストに含まれない場合は、HTTP Cookieパーサーも組み合わせて確認する必要があります。Set-CookieとCookieリクエストヘッダーは2つの異なるフェーズです。

クロスサイトシナリオでは最初にSameSite=NoneとSecureの組み合わせを確認する

SSO、サードパーティログイン、iframe埋め込み、クロスオリジンリクエストで最も一般的な落とし穴は、SameSite=NoneなのにSecureが設定されていないことです。この問題を最初に解消してから、サーバーロジックとブラウザポリシーを確認してください。

__Host-/__Secure-プレフィックスは名前だけでなく、制約が完全に満たされているかを確認する

多くのチームはCookie名に`__Host-`または`__Secure-`を付ければより安全になると考えていますが、Secure、Path=/、Domainなどの付随条件が満たされていなければ、ブラウザは依然として書き込みを拒否します。

ドキュメントの作成やIssueの再現時には元のヘッダーとJSONの両方を保存することを優先する

元のヘッダーはバックエンドや運用担当者が実際の戻り値を確認するのに適しています；JSONはIssue、テストケース、スクリプトに貼り付けるのに適しています。2つを一緒に保存する方が、DevToolsのスクリーンショットだけを撮るよりも再現とコラボレーションに役立ちます。

よくある質問

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

Set-Cookieパーサーはサーバーのレスポンスヘッダーを対象とし、ブラウザがこのCookieを受け入れるかどうか、属性に問題がないかを確認します。Cookieリクエストヘッダーパーサーはブラウザが送信するリクエストを解析し、実際にどのCookieが送信されているかを表示します。SameSite、HttpOnly、Secure、Path、Domain、Expires、Max-Ageなどの属性設定の問題をトラブルシューティングする場合は、このページを使用してください。

HTTP Cookieパーサー

ブラウザがレスポンスを受信したのにCookieを書き込まないのはなぜですか？

それがまさにこのツールが最も得意とする問題です。一般的な原因には、SameSite=NoneにSecureがない、HTTPページでSecure Cookieを設定しようとしている、__Host-プレフィックス違反、PartitionedにSecureがない、PathまたはDomainの設定が不適切、Max-Ageが無効または0である、ブラウザのサードパーティCookieポリシーによる制限などがあります。

ツールはどのような一般的なSet-Cookieリスクをチェックしますか？

このページは14種類の頻発する問題を自動的に検出します：SameSite=NoneにSecureがない、SameSite値が無効、PartitionedにSecureがない、HttpOnly/Path/SameSiteが欠落、__Host-プレフィックスにSecureがない/Pathが/でない/Domainが誤って設定されている、__Secure-プレフィックスにSecureがない、Max-Ageが無効、Max-Age=0、Domainの先頭がドット、ExpiresにMax-Ageがないなどです。

SameSite=Noneには必ずSecureが必要なのはなぜですか？

最新のブラウザでは、`SameSite=None`を宣言するクロスサイトで送信可能なCookieには`Secure`を同時に付けることが要求されます。そうしないと、通常ブラウザは書き込みを直接拒否します。この種の問題は、サードパーティログイン、SSO、iframe埋め込み、クロスオリジンリクエストのデバッグで非常によく見られます。

__Host-および__Secure-プレフィックス付きCookieがブラウザに拒否されるのはなぜですか？

`__Host-`と`__Secure-`は強い制約を持つセキュリティプレフィックスです。`__Host-`はSecure、Path=/、Domainを設定しないことが要求され；`__Secure-`は少なくともSecureが要求されます。これらのルールに違反すると、ブラウザはそのCookieを直接無視します。

Max-AgeとExpiresはどのように見るべきですか？

Max-Ageは相対的な秒数であり、通常Expiresより優先されます；Expiresは絶対的な時刻であり、クライアントの時計の影響を受けます。多くのサーバーはExpiresのみを記述しMax-Ageを記述しませんが、これは動作するものの、デバッグ時にタイムゾーンやシステム時刻のずれによる誤判定を引き起こしやすくなります。

このツールはクロスサイトCookieとサードパーティCookieの問題のトラブルシューティングに適していますか？

適しています。サードパーティログイン、SSO、iframe埋め込み、クロスオリジンAPI、CHIPS（Partitioned Cookie）シナリオのいずれであっても、このツールはSameSite、Secure、Partitionedの組み合わせが適切かどうかをすばやく確認するのに役立ちます。

解析結果はコピーまたはエクスポートできますか？

はい。元のSet-Cookieヘッダーをワンクリックでコピーすることも、構造化されたJSONプレビューを表示して、各Cookieの名前、値、属性、警告結果をIssue、ドキュメント、テストスクリプト、結合テスト記録に貼り付けることもできます。

コピーしたSessionやTokenをサーバーにアップロードしますか？

いいえ。Set-Cookieコンテンツの解析、URLデコード、属性の分解、警告チェックはすべてブラウザ内でローカルに完了し、機密性の高いレスポンスヘッダーをサーバーにアップロードすることはありません。

用語集

Set-Cookie
HTTPレスポンスヘッダーであり、サーバーはこれを介してブラウザにCookieの保存を指示します。1つのレスポンスに複数のSet-Cookieが含まれることがあり、通常はそれぞれが1つのCookieに対応します。
SameSite
クロスサイトリクエストでCookieを送信するかどうかを制御する属性です。一般的な値はStrict、Lax、Noneであり、Noneの場合は多くの場合Secureの同時設定が要求されます。
HttpOnly
設定すると、フロントエンドのJavaScriptがdocument.cookieを介してこのCookieを読み取ることができなくなり、主にXSSによるセッション窃取のリスクを低減します。
Secure
設定すると、ブラウザはHTTPS接続（localhostの特例を除く）でのみこのCookieを送信し、機密性の高いCookieが平文のHTTPで露出するのを防ぎます。
Max-Age
Cookieの相対的な生存期間であり、単位は秒です。通常Expiresより優先され、サーバー側で明示的に設定することが推奨されます。
Expires
Cookieの絶対的な失効時刻であり、クライアントのローカル時刻に依存します。単独で使用する場合、通常Max-Ageよりデバッグコストが高くなります。
Path
Cookieが有効なURLパスプレフィックスを制限します。Pathが一致しない場合、Cookieが書き込まれていても後続のリクエストには含まれません。
Domain
Cookieが有効なドメイン範囲を制限します。設定しない場合は通常現在のホストに限定され；設定するとサブドメインにも作用する場合があります。
Partitioned（CHIPS）
サードパーティCookieのパーティション化ストレージソリューションであり、ブラウザがサードパーティCookieを段階的に厳格化した後の代替手段としてよく使用されます。現在の実装では通常Secureとの併用が要求されます。
__Host- / __Secure-プレフィックス
ブラウザがサポートする高セキュリティCookieの命名プレフィックスであり、強力な制約ルールがあります。ルールに違反すると、ブラウザは対応するCookieの受信を拒否します。

SameSiteの3つのポリシー比較早見表

クロスサイトCookieをトラブルシューティングするときは、最初にSameSiteの動作境界を確認し、次にSecureが欠落していないかを確認してください。

SameSite値クロスサイトトップレベルナビゲーション(GET)クロスサイトサブリソース(img/iframe/script)クロスサイトPOSTフォームクロスサイトXHR/fetchSecure必須か
Strict送信しない送信しない送信しない送信しないいいえ
Lax（デフォルト）送信する送信しない送信しない送信しないいいえ
None送信する送信する送信する送信するSecureの設定が必須

Set-Cookieデバッグ頻出問題対照表

ブラウザが黙ってCookieを拒否するときは、以下の方向で最初にトラブルシューティングすると、通常レスポンスボディを眺めるよりも早く解決します。

現象確率の高い原因優先的に確認すること
ブラウザがCookieをまったく書き込まないSameSite=NoneにSecureがない、プレフィックス違反、属性の組み合わせが不正最初にこのページの警告ラベルと属性カードを確認
クロスサイト/iframeシナリオで有効にならないSameSiteが厳しすぎる、Secureが欠落している、サードパーティポリシーによる制限SameSite、Secure、Partitionedを重点的に確認
Cookieを書き込んだとたんに失効するMax-Age=0、Max-Ageが不正、Expiresの時刻に問題がある最初にMax-Ageを確認し、次にExpiresを確認
__Host-/__Secure-Cookieが無効Secure、Path=/、Domainの制約が満たされていないプレフィックスの警告がヒットしているか確認
開発環境では正常だが本番環境では正常でないHTTPS、Domain、Path、SameSiteまたはプロキシ層のレスポンスの違い元のヘッダーをコピーし、環境間のSet-Cookieの戻り値を比較

Privacy & Security

Set-Cookieレスポンスヘッダーの解析、URLデコード、属性分解、14種類の警告チェックはすべてブラウザ内でローカルに完了します。貼り付けられたSession、Token、ログイン状態のCookieはいかなるサーバーにもアップロードされません。