Set-Cookie 파서

Set-Cookie 파서

여러 줄의 Set-Cookie 응답 헤더를 붙여넣어 속성을 검사하고 위험한 SameSite / Secure 조합을 표시합니다.

Cookie 속성 카드

Set-Cookie 2개
#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 속성이 잘못된 경우가 많습니다.

관련 추천

HTTP 쿠키 파서

쿠키 파서

보안 헤더 검사기

CORS 검사기

인증 헤더 생성기

cURL 코드 생성기

Set-Cookie 파서란 무엇인가요?

Set-Cookie 파서는 HTTP 응답 헤더 내의 `Set-Cookie` 내용 전용 디버깅 도구입니다. 단순히 한 줄의 텍스트를 세미콜론으로 분할하는 것이 아니라 개발자가 다음을 판단하는 데 도움을 줍니다: 서버의 이 쿠키 구성이 올바른지, 브라우저가 받아들이지 않은 이유는 무엇인지, 어떤 속성 조합에 보안 또는 호환성 위험이 있는지, 현재 Set-Cookie가 크로스사이트, SSO, iframe, 타사 쿠키, 세션 시나리오에 적합한지.

요청 헤더 내의 Cookie와 달리 Set-Cookie는 서버가 "브라우저에 보내는 구성 명령"입니다. 이에는 `name=value`뿐만 아니라 SameSite, Secure, HttpOnly, Path, Domain, Expires, Max-Age, Partitioned 등의 속성도 포함됩니다. 이러한 필드는 브라우저가 쓸지 여부, 언제 만료될지, 어떤 경로와 도메인에서 유효할지, 크로스사이트 요청에서 보낼 수 있는지 여부를 직접 결정합니다. 그래서 "로그인 상태가 손실된다", "브라우저가 쿠키를 보내지 않는다", "크로스오리진 시나리오에서 유효하지 않다"와 같은 많은 문제의 근본 원인은 값 자체가 아니라 Set-Cookie 속성 구성에 있습니다.

이 페이지의 가치는 이러한 속성을 원본 응답 헤더에서 구조화하여 추출하고 브라우저의 실제 규칙에 따라 정적 검사를 수행하는 데 있습니다. 예를 들어 SameSite=None에 Secure가 없는지, Partitioned가 Secure와 함께 사용되는지, __Host- 접두사에 Domain이 잘못 설정되지 않았는지, Max-Age가 유효하지 않거나 0이 아닌지, Expires에 Max-Age가 없는지 등입니다. 이러한 문제는 브라우저가 구문 오류처럼 직접 알려주는 경우가 보통 없으며 조용히 거부하거나 "그냥 작동하지 않는다"는 형태로 나타나기 때문에 도구를 통한 검사가 매우 중요합니다.

요청에 현재 어떤 쿠키가 포함되어 있는지만 알고 싶다면 이 페이지에 머물지 말고 요청 헤더 분해에 더 적합한「HTTP Cookie 파서」를 참조하세요. 이 페이지는 "브라우저가 왜 쓰지 않았는가", "서버의 이 쿠키 구성에 숨겨진 위험은 없는가", "크로스사이트와 보안 속성 조합이 적절한가"와 같은 응답 헤더 디버깅 시나리오에 더 적합합니다.

사용 사례

  • 브라우저가 쿠키를 거부할 때 SameSite, Secure, HttpOnly, Path/Domain 중 어떤 구성에 문제가 있는지 빠르게 식별
  • 타사 로그인, SSO, iframe 삽입, 크로스사이트 요청 시나리오에서 SameSite=None이 Secure와 올바르게 조합되었는지 확인
  • 보안 감사 시 인터페이스가 반환하는 쿠키에 HttpOnly나 SameSite 누락, 또는 고위험 속성 조합이 없는지 일괄 검사
  • __Host-/__Secure- 접두사가 있는 쿠키가 브라우저의 강력한 제약을 충족하여 조용히 폐기되는 것을 피하기 위한 검증
  • Partitioned Cookie/CHIPS 3자 파티셔닝 솔루션을 디버깅할 때 Partitioned와 Secure가 동시에 선언되었는지 확인
  • 개발, 테스트, 프로덕션 환경의 Set-Cookie 응답 헤더 차이를 비교하여 환경 전환 후 로그인 상태 이상 트러블슈팅

이용 방법

  1. 브라우저 DevTools, 패킷 캡처 도구 또는 서버 로그에서 Set-Cookie 응답 헤더 내용을 복사(여러 줄 지원)
  2. 입력 영역에 붙여넣으면 도구가 자동으로 `Set-Cookie:` 접두사를 제거하고 줄별로 분석
  3. 각 쿠키의 이름, 값, URL 디코딩 값, 속성 카드, 경고 레이블 확인
  4. 원본 헤더를 복사하거나 JSON 미리보기를 표시하여 결과를 백엔드에 보내거나 Issue/테스트 스크립트에 붙여넣기

주요 기능

  • 여러 Set-Cookie를 독립적으로 분석: 각 줄을 개별 카드로 표시하여 이름, 원본 값, URL 디코딩 값, 속성을 하나씩 확인 가능
  • 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, 로그인 상태 쿠키는 브라우저에서 분석되며 기기 외부로 나가지 않음

Set-Cookie 파서를 사용해야 할 때와 다른 페이지를 사용해야 할 때는?

「서버가 무엇을 설정했는지」를 보는 것과 「요청에 실제로 무엇이 포함되는지」를 보는 것은 별개의 일이므로 혼동하지 마세요.

도구적합한 입력가장 적합한 용도핵심 강점
Set-Cookie 파서(현재 페이지)Set-Cookie 응답 헤더브라우저가 쿠키를 받지 않거나, 크로스사이트에서 작동하지 않거나, 보안 속성 구성에 위험이 있는 경우 디버깅속성 분해가 완전하며 14가지 자주 발생하는 구성 오류를 자동으로 검사
HTTP Cookie 파서Cookie 요청 헤더, document.cookie요청에 실제로 어떤 쿠키가 포함되어 있는지, 값이 URL 인코딩되었는지, 이름이 중복되는지 확인요청 헤더의 이름-값 쌍 분해와 표준화된 출력에 더 특화HTTP Cookie 파서 열기
Cookie 파서Cookie 문자열과 Set-Cookie 혼합 디버깅 시나리오수신 중인 데이터의 출처가 불분명하거나 한 페이지에서 Cookie/Set-Cookie 두 가지 모드를 빠르게 전환하고 싶을 때쿠키 디버깅의 종합 진입점과 같은 역할을 하며 Netscape Cookie File 형식 내보내기도 지원Cookie 파서 열기

Best Practices

문제가 「설정 실패」인지 「요청에 포함되지 않음」인지 먼저 판단

브라우저가 쿠키를 전혀 쓰지 않는다면 이 페이지를 우선 참조하세요; 브라우저가 이미 썼지만 후속 요청에 포함되지 않는다면 HTTP Cookie 파서도 함께 사용하여 확인해야 합니다. Set-Cookie와 Cookie 요청 헤더는 두 가지 다른 단계입니다.

크로스사이트 시나리오에서는 먼저 SameSite=None과 Secure 조합을 확인

SSO, 타사 로그인, iframe 삽입, 크로스오리진 요청에서 가장 흔한 함정은 SameSite=None인데 Secure가 설정되지 않은 것입니다. 이 문제를 먼저 해결한 다음 서버 로직과 브라우저 정책을 확인하세요.

__Host-/__Secure- 접두사는 이름뿐만 아니라 제약이 완전히 충족되는지 확인

많은 팀이 쿠키 이름에 `__Host-` 또는 `__Secure-`를 붙이면 더 안전해진다고 생각하지만 Secure, Path=/, Domain 등 부수 조건이 충족되지 않으면 브라우저는 여전히 쓰기를 거부합니다.

문서 작성과 Issue 재현 시 원본 헤더와 JSON 두 가지를 모두 보존 우선

원본 헤더는 백엔드와 운영 담당자가 실제 반환값을 확인하는 데 적합하며; JSON은 Issue, 테스트 케이스, 스크립트에 붙여넣는 데 적합합니다. 둘을 함께 보존하는 것이 DevTools 스크린샷만 찍는 것보다 재현과 협업에 도움이 됩니다.

자주 묻는 질문

Set-Cookie 파서와 Cookie 요청 헤더 파서의 차이점은 무엇인가요?

Set-Cookie 파서는 서버 응답 헤더를 대상으로 하며 브라우저가 해당 쿠키를 수락할지 여부와 속성에 문제가 없는지 확인합니다. Cookie 요청 헤더 파서는 브라우저가 보내는 요청을 분석하여 실제로 어떤 쿠키가 전송되는지 보여줍니다. SameSite, HttpOnly, Secure, Path, Domain, Expires, Max-Age 등의 속성 구성 문제를 해결하려면 이 페이지를 사용하세요.

HTTP Cookie 파서

브라우저가 응답을 받았는데 쿠키를 쓰지 않는 이유는 무엇인가요?

이것이 바로 이 도구가 가장 잘 해결하는 문제입니다. 일반적인 원인으로는 SameSite=None에 Secure가 없거나, HTTP 페이지에서 Secure 쿠키를 설정하려고 하거나, __Host- 접두사 위반, Partitioned에 Secure 누락, Path 또는 Domain 구성이 잘못되었거나, Max-Age가 유효하지 않거나 0이며, 브라우저의 타사 쿠키 정책 제한이 있습니다.

도구는 어떤 일반적인 Set-Cookie 위험을 검사하나요?

이 페이지는 SameSite=None에 Secure 누락, SameSite 값이 유효하지 않음, Partitioned에 Secure 누락, HttpOnly/Path/SameSite 누락, __Host- 접두사에 Secure 없음/Path가 /가 아님/Domain이 잘못 설정됨, __Secure- 접두사에 Secure 없음, Max-Age가 유효하지 않음, Max-Age=0, Domain이 점으로 시작, Expires에 Max-Age 누락 등 14가지 자주 발생하는 문제를 자동으로 감지합니다.

SameSite=None에는 반드시 Secure가 함께 있어야 하는 이유는 무엇인가요?

최신 브라우저는 `SameSite=None`을 선언한 크로스사이트 전송 가능 쿠키에 `Secure`를 함께 요구합니다. 그렇지 않으면 일반적으로 브라우저가 쓰기를 직접 거부합니다. 이러한 종류의 문제는 타사 로그인, SSO, iframe 삽입, 크로스오리진 요청 디버깅에서 매우 흔하게 발생합니다.

__Host- 및 __Secure- 접두사가 있는 쿠키가 브라우저에 거부되는 이유는 무엇인가요?

`__Host-`와 `__Secure-`는 강력한 제약이 있는 보안 접두사입니다. `__Host-`는 Secure, Path=/, Domain을 설정하지 않아야 하며; `__Secure-`는 최소한 Secure가 요구됩니다. 이러한 규칙을 위반하면 브라우저는 해당 쿠키를 직접 무시합니다.

Max-Age와 Expires는 어떻게 봐야 하나요?

Max-Age는 상대적인 초 단위 수명이며 일반적으로 Expires보다 우선합니다; Expires는 절대적인 시점으로 클라이언트 시계의 영향을 받습니다. 많은 서버가 Expires만 쓰고 Max-Age를 쓰지 않는데, 이는 작동하지만 디버깅 시 시간대나 시스템 시계 편차로 인한 오판을 일으키기 쉽습니다.

이 도구는 크로스사이트 쿠키와 타사 쿠키 문제를 해결하는 데 적합한가요?

적합합니다. 타사 로그인, SSO, iframe 삽입, 크로스오리진 API, CHIPS(Partitioned Cookie) 시나리오 등 어떤 경우에도 이 도구는 SameSite, Secure, Partitioned 조합이 적절한지 빠르게 확인하는 데 도움이 됩니다.

분석 결과를 복사하거나 내보낼 수 있나요?

네. 원본 Set-Cookie 헤더를 원클릭으로 복사하거나 구조화된 JSON 미리보기를 표시하여 각 쿠키의 이름, 값, 속성, 경고 결과를 Issue, 문서, 테스트 스크립트, 연동 기록에 붙여넣을 수 있습니다.

복사한 Session이나 Token을 서버에 업로드하나요?

아니요. Set-Cookie 내용 분석, URL 디코딩, 속성 분해, 경고 검사는 모두 브라우저에서 로컬로 완료되며 민감한 응답 헤더를 서버에 업로드하지 않습니다.

용어집

Set-Cookie
HTTP 응답 헤더로, 서버는 이를 통해 브라우저에 쿠키 저장을 지시합니다. 하나의 응답에 여러 Set-Cookie가 포함될 수 있으며, 일반적으로 각각 하나의 쿠키에 해당합니다.
SameSite
크로스사이트 요청에서 쿠키를 보낼지 여부를 제어하는 속성입니다. 일반적인 값은 Strict, Lax, None이며; None인 경우 대부분 Secure의 동시 설정이 요구됩니다.
HttpOnly
설정하면 프런트엔드 JavaScript가 document.cookie를 통해 이 쿠키를 읽을 수 없게 되며, 주로 XSS로 인한 세션 탈취 위험을 줄입니다.
Secure
설정하면 브라우저는 HTTPS 연결(localhost 예외 제외)에서만 이 쿠키를 보내며, 민감한 쿠키가 평문 HTTP에 노출되는 것을 방지합니다.
Max-Age
쿠키의 상대적인 수명으로 단위는 초입니다. 일반적으로 Expires보다 우선하며 서버 측에서 명시적으로 설정하는 것이 권장됩니다.
Expires
쿠키의 절대적인 만료 시점으로 클라이언트 로컬 시간에 의존합니다. 단독으로 사용하는 경우 일반적으로 Max-Age보다 디버깅 비용이 높습니다.
Path
쿠키가 유효한 URL 경로 접두사를 제한합니다. Path가 일치하지 않으면 쿠키가 쓰였더라도 후속 요청에 포함되지 않습니다.
Domain
쿠키가 유효한 도메인 범위를 제한합니다. 설정하지 않으면 일반적으로 현재 호스트로 제한되며; 설정하면 서브도메인에도 작용할 수 있습니다.
Partitioned(CHIPS)
타사 쿠키의 파티셔닝된 스토리지 솔루션으로, 브라우저가 타사 쿠키를 점진적으로 엄격화한 후의 대안으로 자주 사용됩니다. 현재 구현에서는 일반적으로 Secure와의 병용이 요구됩니다.
__Host- / __Secure- 접두사
브라우저가 지원하는 고보안 쿠키 명명 접두사로 강력한 제약 규칙이 있습니다. 규칙을 위반하면 브라우저는 해당 쿠키의 수신을 거부합니다.

SameSite 세 가지 전략 비교 빠른 참조표

크로스사이트 쿠키를 디버깅할 때는 먼저 SameSite의 동작 경계를 확인한 다음 Secure가 누락되었는지 확인하세요.

SameSite 값크로스사이트 최상위 탐색(GET)크로스사이트 하위 리소스(img/iframe/script)크로스사이트 POST 폼크로스사이트 XHR/fetchSecure 필수 여부
Strict보내지 않음보내지 않음보내지 않음보내지 않음아니요
Lax(기본값)보냄보내지 않음보내지 않음보내지 않음아니요
None보냄보냄보냄보냄Secure를 설정해야 함

Set-Cookie 디버깅 빈번 문제 대조표

브라우저가 쿠키를 조용히 거부할 때는 다음 방향으로 먼저 트러블슈팅하면 일반적으로 응답 본문을 바라보는 것보다 빠르게 해결됩니다.

증상확률이 높은 원인우선 확인 사항
브라우저가 쿠키를 전혀 쓰지 않음SameSite=None에 Secure 누락, 접두사 위반, 속성 조합이 유효하지 않음먼저 이 페이지의 경고 레이블과 속성 카드 확인
크로스사이트/iframe 시나리오에서 작동하지 않음SameSite가 너무 엄격함, Secure 누락, 타사 정책 제한SameSite, Secure, Partitioned를 중점적으로 확인
쿠키를 쓰자마자 만료됨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, 로그인 상태 쿠키는 어떤 서버에도 업로드되지 않습니다.