Set-Cookie 파서

GeekFormat 정보

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 헤더를 붙여넣으면 브라우저가 쿠키를 수락하지 않는 이유를 즉시 확인할 수 있습니다.

사용 사례

브라우저가 쿠키 쓰기를 거부할 때 SameSite 정책 문제인지, Secure 플래그 누락인지, 아니면 Path/Domain 불일치인지 빠르게 식별
타사 로그인/SSO/iframe 삽입 시나리오에서 브라우저에 차단된 쿠키를 디버깅. SameSite=None이 Secure와 올바르게 페어링되었는지 확인
보안 감사 시 API가 반환하는 쿠키에 모두 XSS 도난 방지를 위한 HttpOnly가 설정되어 있는지, HTTP 평문 전송 방지를 위한 Secure가 설정되어 있는지 일괄 확인
__Host-/__Secure- 접두사 쿠키 사용 시 RFC 6265bis 필수 요구 사항을 충족하는지 확인하여 브라우저의 자동 삭제 방지
CHIPS(Partitioned Cookie) 타사 쿠키 파티셔닝 디버깅 시 Partitioned와 Secure가 함께 선언되었는지 확인
서버 측에서 Max-Age/Expires 설정 시 값이 유효한지 확인하여 클럭 스큐나 Max-Age=0으로 인한 즉시 만료 방지
환경 간(개발/스테이징/프로덕션) Set-Cookie 헤더 차이를 비교하여 개발 환경에서는 정상 작동하지만 프로덕션에서 쿠키가 사라지는 불가사의한 문제 디버깅
DevTools나 curl 응답에서 응답 헤더 전체를 직접 복사. Set-Cookie: 접두사를 수동으로 제거할 필요 없이 도구가 자동으로 제거
API 문서 작성이나 WASM/WebWorker 요청 관련 버그 디버깅 시 분석된 JSON 결과를 문서에 직접 붙여넣어 쿠키 구조 설명

주요 기능

다중 쿠키 독립 분석: 각 Set-Cookie 줄이 독립된 카드로 표시되며, 번호와 함께 이름, 값, URL 디코딩 값을 보여주어 문제가 있는 쿠키를 한눈에 파악
14가지 속성 보안 감지: SameSite=None에 Secure 누락, 잘못된 SameSite 값, Partitioned에 Secure 누락, HttpOnly 누락, Path 누락, SameSite 누락, __Host- 접두사 위반, __Secure-에 Secure 누락, 잘못된/0인 Max-Age, Domain 앞 점, Max-Age 없이 Expires만 설정 등 흔한 실수를 자동 식별
전체 속성 완전 분해: SameSite, Secure, HttpOnly, Path, Domain, Expires, Max-Age, Partitioned를 항목별로 나열하여 플래그형 속성과 값이 있는 속성을 한눈에 구분
Max-Age 자동 환산: 초 단위를 일/시간/분/초 단위의 읽기 쉬운 시간으로 자동 환산. 예: Max-Age=2592000은 30d로 표시
URL 디코딩 값 자동 표시: 쿠키 값에 %XX 인코딩이 포함된 경우 디코딩된 원문(예: sessionID%3Dabc→sessionID=abc)을 녹색 화살표로 자동 표시
RFC 6265bis 접두사 검증: Path=/, Domain 금지, Secure 필수 등 __Host- 및 __Secure- 접두사 쿠키의 규정 준수 요구 사항을 엄격히 검증
원본 헤더 원클릭 복사: 분석된 모든 쿠키 원본 줄을 한 번에 복사하여 이메일, 이슈, 문서에 붙여넣어 팀과 공유 가능
구조화된 JSON 미리보기: 분석 결과는 name/value/decodedValue/attributes/attributeMap/warnings 전체 필드를 포함한 JSON 형식으로 출력 가능하며 스크립트와 테스트 케이스에서 직접 사용 가능
완전 로컬 처리: Set-Cookie 내용은 브라우저 로컬에서 분석되며 어떤 서버에도 업로드되지 않아 민감한 세션, 토큰 등의 정보 유출 방지
스마트 경고 배지: 각 문제는 주황색 경고 배지로 구체적인 원인을 표시하여 RFC 문서를 일일이 대조할 필요 없음
여러 줄 일괄 입력: 응답 헤더 전체를 한 번에 붙여넣기 가능(예: Chrome DevTools Network 패널에서 복사). Set-Cookie: 접두사를 자동으로 제거하고 줄 단위로 분석
따옴표와 세미콜론이 포함된 값 지원: RFC 사양에 따라 큰따옴표로 묶인 쿠키 값과 Expires 날짜의 세미콜론을 올바르게 처리하여 잘못된 분할 방지

이용 방법

브라우저 DevTools Network 패널을 열고 대상 요청을 찾은 다음 Response Headers 영역에서 Set-Cookie 내용을 복사(여러 줄 지원. 모든 쿠키를 한 번에 복사 가능)
복사한 Set-Cookie 응답 헤더를 입력 영역에 붙여넣기. 한 줄에 하나의 쿠키(Set-Cookie: 접두사를 수동으로 삭제할 필요 없이 도구가 자동으로 제거합니다)
도구는 실시간으로 분석합니다. 상단에는 감지된 Set-Cookie 개수가 표시되고, 하단에는 각 쿠키가 개별 속성 카드로 표시됩니다
카드 헤더에는 번호, 쿠키 이름, 원래 값이 표시됩니다. 값에 URL 인코딩이 포함된 경우 녹색 화살표 뒤에 디코딩된 값이 표시됩니다
카드 본문에는 SameSite, Secure, HttpOnly, Path, Domain, Max-Age, Expires, Partitioned 등의 속성이 항목별로 표시됩니다. Max-Age는 자동으로 괄호 안에 읽기 쉬운 시간으로 환산되어 표시됩니다
카드 푸터에는 검사 결과가 표시됩니다. 주황색 경고 배지가 구체적인 문제를 지적하고(각 문제에는 명확한 한국어 설명이 있습니다), 녹색 배지는 뚜렷한 문제가 발견되지 않았음을 의미합니다
서버 구성과 비교해야 할 경우 '원본 헤더 복사'를 클릭하여 모든 원본 Set-Cookie 줄을 복사합니다. 프로그램에서 처리해야 할 경우 'JSON 미리보기'를 확인하세요

자주 묻는 질문

Set-Cookie 헤더 설정은 성공했는데 브라우저가 쿠키를 저장하지 않는 이유는 무엇인가요?

이것은 가장 흔한 문제입니다. 브라우저는 적극적으로 오류를 보고하지 않으며 규정을 준수하지 않는 쿠키를 조용히 삭제합니다. 일반적인 원인으로는 SameSite=None에 Secure 누락, HTTP 페이지에서 Secure 쿠키 설정(localhost 예외), __Host-/__Secure- 접두사 제약 조건 미충족, Domain/Path 불일치, 4KB 크기 제한 초과, Max-Age가 0 또는 음수인 경우가 포함됩니다. 먼저 Set-Cookie를 이 도구에 붙여넣어 경고 배지에서 구체적인 원인을 찾은 다음, Chrome DevTools → Application → Cookies를 열고 해당 도메인 아래에서 노란색 경고 삼각형을 찾아 마우스를 올리면 구체적인 거부 이유가 표시됩니다.

SameSite의 Strict, Lax, None은 정확히 무슨 차이인가요? 언제 어떤 것을 사용해야 하나요?

Strict는 교차 사이트 전송을 완전히 허용하지 않아 가장 안전하지만, 사용자가 외부 사이트 링크를 클릭하여 들어오면 로그인하지 않은 것처럼 보이며 결제/비밀번호 변경 등 민감한 작업 쿠키에 적합합니다. Lax는 Chrome 80 이상의 기본값으로, 사용자가 외부 링크에서 최상위 GET 탐색으로 사이트에 접속할 때(외부 사이트 링크를 클릭하여 사이트로 돌아올 때) 쿠키 전송을 허용하지만 iframe/img/script/XHR/POST 폼 등 하위 리소스에서는 전송하지 않아 대부분의 시나리오에서 권장되는 값입니다. None은 모든 교차 사이트 시나리오에서의 전송을 허용하지만(SSO 싱글 사인온, 타사 삽입 iframe, 교차 사이트 API 호출에 사용) Secure를 함께 설정해야 하며, 그렇지 않으면 브라우저에서 직접 거부합니다.

왜 SameSite=None은 Secure와 함께 사용해야 하나요?

이것은 Chrome이 버전 80(2020년 2월)부터 강제하고 있는 규칙이며 Firefox, Edge, Safari도 모두 따르고 있습니다. SameSite=None은 교차 사이트 쿠키 전송을 명시적으로 허용하기 때문에 공격자가 교차 사이트 시나리오에서 CSRF를 실행하거나 도청하기 더 쉬워지므로, 위험을 완화하기 위해 Secure(HTTPS 암호화 전송)와 함께 사용해야 합니다. SameSite=None 쿠키를 HTTP에서 설정하면 브라우저는 저장하지 않고 직접 삭제합니다. 이 도구는 SameSite=None에 Secure가 없는 조합을 감지하여 빨간색 경고로 표시합니다.

Max-Age와 Expires 중 어떤 것을 사용해야 하나요? 차이점은 무엇인가요?

Max-Age 사용을 우선하세요. Max-Age는 상대적 시간(N초 후 만료)으로 클라이언트 클럭에 의존하지 않으며 브라우저는 수신 후 카운트다운을 시작합니다; Expires는 절대적 시점으로 사용자 컴퓨터 로컬 시간에 의존합니다(사용자가 시계를 1970년으로 설정하면 쿠키는 즉시 만료됩니다). 둘 다 존재할 때 Max-Age가 우선 적용됩니다(RFC 6265에 명시적으로 규정됨). 둘 다 설정하지 않으면 쿠키는 '세션 쿠키'가 되어 브라우저를 닫으면 만료됩니다. 이 도구는 Expires가 설정되어 있고 Max-Age가 설정되지 않은 경우 Max-Age 추가를 권장하는 메시지를 표시합니다. 참고: Max-Age 단위는 밀리초가 아니라 초입니다.

Path=/와 Path를 설정하지 않는 것의 차이점은 무엇인가요?

Path는 브라우저가 어떤 URL 경로 요청에 이 쿠키를 포함할지 결정합니다. Path를 설정하지 않으면 브라우저는 기본적으로 '응답 URL에서 마지막 세그먼트를 제거한 경로'를 사용합니다. 예를 들어 /api/user/login에서 쿠키를 설정할 때 기본 Path는 /api/user/이므로, / 경로와 /order/ 아래의 요청에는 이 쿠키가 포함되지 않습니다. 명시적으로 Path=/를 설정하면 쿠키가 사이트 전체에서 적용됩니다. Path 매칭은 접두사 매칭이라는 점에 유의하세요. Path=/api는 /api/, /api/user, /api/v2/abc 등에도 매칭됩니다. __Host- 접두사 쿠키는 Path=/가 필수입니다.

Domain 앞에 점이 있는 경우(예: .example.com)와 없는 경우의 차이점은 무엇인가요?

최신 브라우저(Chrome, Firefox, Edge, Safari 최신 버전)에서는 둘이 동일하며, 모두 example.com과 모든 하위 도메인(a.example.com, b.c.example.com)에 쿠키를 적용합니다. 앞 점은 RFC 2109 시대의 오래된 작성 방식이며, RFC 6265에서는 앞 점을 명시적으로 무시하도록 되어 있습니다. 다만 가독성을 위해 점이 없는 형식을 권장합니다. 이 도구는 앞 점이 있는 Domain에 대해 알림을 표시합니다(오류는 아니지만 역사적 오래된 작성 방식입니다). 참고: Domain을 설정하지 않으면 쿠키는 현재 호스트에만 적용되며(하위 도메인에는 적용되지 않음), Domain을 설정하면 하위 도메인에도 적용됩니다.

Host- 및 Secure- 접두사는 무엇인가요? 접두사를 쓰지 않아도 괜찮나요?

이것들은 RFC 6265bis에 도입된 쿠키 이름 보안 접두사로, 고보안 쿠키에 강력한 제약 조건을 추가하기 위한 것입니다: 브라우저는 쿠키 이름이 __Host-로 시작하는 것을 보면 Secure가 설정되어 있어야 하고, Path=/여야 하며, Domain이 설정되지 않아야 한다는 것을 강제하며, 어느 한 조건이라도 충족하지 않으면 저장을 직접 거부합니다; __Secure- 접두사는 Secure가 설정되어 있어야 하며 다른 속성은 구성 가능합니다. 접두사를 쓰지 않아도 작동합니다(대부분의 쿠키는 접두사를 사용하지 않습니다). 하지만 세션 식별자나 인증 토큰 등 고보안 쿠키에는 하위 도메인/경로 수준의 쿠키 주입 공격을 방지할 수 있으므로 __Host- 접두사 사용을 강력히 권장합니다. 이 도구는 두 가지 접두사의 규정 준수를 자동으로 감지합니다.

HttpOnly 쿠키는 정말 안전한가요? XSS와 CSRF를 방지하나요?

HttpOnly는 JavaScript가 document.cookie를 통해 쿠키 값을 읽는 것을 방지하여 <strong>XSS 세션 도난 완화</strong>의 중요한 방어선이지만, 만능은 아닙니다: XSS 공격자는 여전히 사용자 브라우저에서 요청을 시작할 수 있고(요청에는 자동으로 쿠키가 포함됨) 작업을 수행할 수 있습니다(이것은 CSRF 영역입니다); HttpOnly는 CSRF 공격도 방어하지 못합니다(SameSite 또는 CSRF 토큰과의 조합이 필요합니다). HttpOnly+Secure+SameSite=Lax/Strict 세 가지가 함께 사용되어야 기본적인 보안 수준에 도달합니다. 민감한 쿠키(session, JWT, access_token)는 HttpOnly 필수로 설정하고, 필요하지 않다면 프론트엔드 JS가 읽지 못하게 하세요. 이 도구는 HttpOnly가 없는 쿠키에 경고를 표시합니다.

Partitioned(CHIPS) 쿠키는 무엇인가요? 언제 사용해야 하나요?

Partitioned는 Chrome이 타사 쿠키 폐지에 대비하여 도입한 새로운 속성으로, Cookies Having Independent Partitioned State(CHIPS)의 약자입니다. 기존 타사 쿠키(광고/삽입 서비스가 여러 사이트에서 설정하는 쿠키 등)는 전역적으로 공유되어 사용자를 교차 사이트 추적하는 데 사용되었습니다. Partitioned를 추가하면 브라우저는 해당 타사 쿠키를 최상위 사이트별로 개별 저장합니다: 사용자가 A 사이트에서 보는 타사 쿠키와 B 사이트에서 보는 것은 완전히 독립적이며 교차 사이트에서 신원을 공유할 수 없습니다. 사용 사례: 삽입된 동영상/지도/결제 컴포넌트, 타사 채팅 플러그인, 교차 사이트 SSO 삽입 iframe. Partitioned를 사용하려면 Secure를 함께 설정해야 하며 __Host- 접두사와 함께 사용하는 것을 권장합니다.

쿠키 하나에 최대 얼마나 저장할 수 있나요? 도메인당 몇 개까지 놓을 수 있나요?

RFC 6265에 따르면 브라우저는 쿠키당 최소 4096바이트(이름, 값, 속성 포함)를 지원해야 합니다. 주요 브라우저(Chrome/Firefox/Safari/Edge)는 모두 이 제한을 적용하며, 초과분은 조용히 잘리거나 삭제됩니다. 개수 제한은 브라우저마다 다릅니다: Chrome은 도메인당 약 180개, Firefox 약 150개, Safari 약 600개(및 ITP 7일 정리 정책의 영향을 받음)이며, 초과하면 브라우저는 LRU 전략으로 가장 오래된 쿠키를 삭제합니다. 쿠키에는 세션 식별자만 저장하고 대량의 비즈니스 데이터를 쿠키에 넣지 않는 것을 권장합니다(비즈니스 데이터는 localStorage 또는 서버 측 세션에 저장하세요).

Chrome DevTools에서 직접 복사한 Set-Cookie 분석을 지원하나요? 수동으로 접두사를 제거해야 하나요?

완전히 지원하며 수동 처리가 필요 없습니다. Chrome DevTools → Network 패널에서 대상 요청을 클릭하고 Response Headers 영역에서 Set-Cookie 값을 마우스 오른쪽 버튼으로 클릭하여 직접 복사할 수 있습니다(여러 줄인 경우 Ctrl/⌘+클릭으로 다중 선택하거나 전체를 복사). 그대로 이 도구 입력 영역에 붙여넣으세요. 도구는 각 줄 앞에 있는 Set-Cookie: 접두사를 자동으로(대소문자 구분 없이) 제거하고 줄 앞뒤 공백을 처리하며, Expires 날짜에 포함된 쉼표, 세미콜론 등 특수 문자를 올바르게 처리하고, 큰따옴표로 묶인 쿠키 값도 올바르게 처리합니다.

쿠키 값의 한국어나 특수 문자가 왜 %XX 형식이 되나요?

RFC 6265는 쿠키 값이 ASCII 문자 집합의 안전한 하위 집합만 사용해야 하며, 한국어, 공백, 쉼표, 세미콜론 등을 직접 포함할 수 없도록 요구합니다. 많은 서버 측 프레임워크는 쿠키를 설정할 때 비ASCII 문자를 자동으로 URL 인코딩(encodeURIComponent/퍼센트 인코딩)합니다. 예를 들어 '안녕하세요'는 %EC%95%88%EB%85%95%ED%95%98%EC%84%B8%EC%9A%94로 인코딩됩니다. 브라우저가 다시 전송할 때도 인코딩된 형식을 유지합니다. 이 도구는 값에 %XX 인코딩이 포함된 것을 감지하면 원래 값 옆에 녹색 화살표로 decodeURIComponent로 디코딩된 원문을 자동으로 표시하여 실제 내용을 쉽게 확인할 수 있도록 합니다.

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

둘은 완전히 반대 방향의 헤더입니다: Set-Cookie는 응답 헤더(서버→브라우저)로 응답에만 나타나며 여러 번 나타날 수 있고, 매번 하나의 쿠키를 전체 속성(Secure/HttpOnly/Path/Domain 등)과 함께 설정합니다; Cookie는 요청 헤더(브라우저→서버)로 요청당 한 번만 나타나며, 현재 범위에 일치하는 모든 쿠키의 플랫한 name=value 쌍(name1=v1; name2=v2)이 포함되고 속성 정보는 전혀 포함되지 않습니다. 즉, 서버는 요청에서 쿠키에 HttpOnly나 Secure가 설정되어 있는지 알 수 없으며, 속성 정보는 브라우저가 로컬에 저장할 때만 유지됩니다. Cookie 요청 헤더를 분석하려면 함께 제공되는 <a href='/network/http-cookie-parser/'>Cookie 요청 헤더 파서</a>를 사용하세요.

왜 Safari에서 쿠키가 며칠 후에 사라지나요?

이것은 Safari의 지능형 추적 방지(ITP: Intelligent Tracking Prevention) 메커니즘이 작동하고 있기 때문입니다. ITP 2.1부터 사용자가 7일간 해당 도메인과 직접 상호작용하지 않으면(즉, 해당 도메인 사이트를 직접 방문하지 않으면), Safari는 Max-Age/Expires 설정에 관계없이 해당 도메인 아래의 모든 쿠키와 웹 사이트 데이터를 정리합니다. 이것은 타사 삽입 서비스에 가장 큰 영향을 미치지만, 메인 사이트 쿠키는 사용자가 계속 방문하는 한 영향을 받지 않습니다. 또한 Safari의 타사 쿠키에 대한 제한은 Chrome보다 엄격합니다. 해결 방법에는 Partitioned 속성 사용, Storage Access API를 통한 권한 요청, 사용자가 메인 사이트 방문 시 쿠키 새로 고침 등이 포함됩니다. 이 도구의 문제 해결 섹션에 더 자세한 Safari 디버깅 가이드가 있습니다.

도구는 여러 Set-Cookie 일괄 분석을 지원하나요? 쿠키 내용이 서버에 업로드되나요?

일괄 분석을 지원합니다. 입력 영역에는 임의의 수의 여러 줄 Set-Cookie를 붙여넣을 수 있으며(예: 응답 헤더 전체를 한 번에 붙여넣기), 각 Set-Cookie는 독립된 번호로 분석되어 여러 속성 카드에 각자의 속성과 경고가 표시됩니다. 모든 분석 프로세스는 완전히 브라우저 내에서 로컬로 완료되며(순수 프론트엔드 JavaScript 처리), 쿠키 내용은 어떤 서버에도 업로드되지 않고 네트워크 요청도 전송되지 않습니다. 붙여넣은 Session/Token 등 민감한 정보는 여러분의 컴퓨터를 벗어나지 않으므로 안심하고 사용하실 수 있습니다.

术语表

Set-Cookie: 서버가 이를 통해 브라우저에 쿠키 저장을 지시하는 HTTP 응답 헤더. 하나의 응답에 여러 번 나타날 수 있습니다.
Cookie(요청 헤더): 브라우저가 자동으로 첨부하는 범위 요구 사항을 충족하는 쿠키 이름-값 쌍 목록으로, 속성이 포함되지 않은 HTTP 요청 헤더입니다.
HttpOnly: 쿠키 속성 플래그. 설정하면 JavaScript가 document.cookie를 통해 쿠키를 읽을 수 없게 되어 주로 XSS 세션 도난을 방어합니다.
Secure: 쿠키 속성 플래그. 설정하면 브라우저는 HTTPS(또는 localhost) 암호화 연결에서만 쿠키를 전송합니다.
SameSite: 교차 사이트 요청에 쿠키를 전송할지 여부를 제어하는 쿠키 속성. 값은 Strict/Lax/None. Chrome 80 이상 기본값은 Lax.
Max-Age: 쿠키 수명을 초 단위로 지정하는 쿠키 속성. Expires보다 우선 적용되며 사용을 권장합니다. =0은 즉시 삭제를 의미합니다.
Expires: 쿠키 만료의 구체적인 시점(HTTP-date)을 지정하는 쿠키 속성. 클라이언트 클럭에 의존합니다.
Path: 쿠키가 적용되는 URL 경로 접두사를 제한하는 쿠키 속성. 기본값은 응답 URL의 디렉터리 부분입니다.
Domain: 쿠키가 적용되는 도메인을 제한하는 쿠키 속성. 설정하지 않으면 현재 호스트만, 설정하면 하위 도메인에도 적용됩니다.
Partitioned(CHIPS): 타사 쿠키의 분할 저장을 활성화하는 쿠키 속성 플래그. Chrome이 타사 쿠키를 폐지한 후의 대안으로 Secure와 함께 사용해야 합니다.
__Host- 접두사: 쿠키 이름 접두사 보안 제약 조건. Secure, Path=/, Domain 속성 없음이 필수이며, 위반 시 브라우저가 저장을 거부합니다.
__Secure- 접두사: 쿠키 이름 접두사 보안 제약 조건. Secure 설정이 필수이며, 위반 시 브라우저가 저장을 거부합니다.
세션 쿠키(Session Cookie): Max-Age와 Expires가 설정되지 않은 쿠키. 브라우저를 닫으면 자동으로 삭제됩니다.
타사 쿠키(Third-party Cookie): 현재 방문 중인 페이지 도메인 외의 도메인에서 설정된 쿠키. 주로 광고, 분석, iframe 삽입 등 타사 서비스에서 설정되며 각 브라우저에서 점진적으로 제한되고 있습니다.

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

Set-Cookie 속성 완전 참조표(RFC 6265bis)

일반적인 브라우저 Set-Cookie 크기 및 개수 제한

Set-Cookie 파서