본문으로 건너뛰기
AZ Tools

HTTP 쿠키 파서

Cookie: 요청 헤더 또는 Set-Cookie: 응답 헤더 붙여넣기 → 각 쿠키의 이름·값·속성·경고 표시.

헤더:

이름

session_id

값

abc123def456

이름

theme

값

dark

이름

locale

값

ko-KR

실제로는 쿠키 이름·값이 URL 인코딩됨 — 도구는 있는 그대로 표시.

사용법

  1. 방향 선택: Cookie(요청) 또는 Set-Cookie(응답).
  2. 쿠키 하나 이상 붙여넣기. Set-Cookie는 줄 하나에 쿠키 하나.
  3. 쿠키별 카드 확인. 브라우저가 거부하거나 이상하게 처리할 쿠키에 경고 표시.

자세한 설명

펼치기

두 가지 모드가 있습니다. Cookie:는 브라우저가 보내는 것으로 name=value 쌍뿐이고, Set-Cookie:는 서버가 돌려주는 것으로 이름과 값에 더해 Path, Domain, Max-Age, Expires, SameSite, Secure, HttpOnly, Partitioned 같은 속성이 붙습니다. 파서는 흔한 설정 오류를 표시합니다. Secure 없는 SameSite=None, Secure가 빠진 __Secure- 쿠키, 엄격한 요건을 통과하지 못하는 __Host- 쿠키입니다.

두 방향이 담는 정보량이 다르고, 이 비대칭에 사람들이 걸려 넘어집니다. Set-Cookie: 한 줄은 모든 속성이 붙은 완전한 지시문이지만, 브라우저가 돌려보내는 Cookie: 헤더에는 이름과 값밖에 없습니다. 어느 쿠키가 HttpOnly였는지, 어느 것이 서브도메인 범위였는지, 언제 만료되는지는 그 안에 전혀 없습니다. 쿠키가 왜 사라졌는지 추적하는 중이라면 요청 헤더는 답을 주지 못합니다. 그것을 만든 Set-Cookie:를 봐야 합니다.

__Host- 접두사는 쓸 수 있는 가장 강한 보장이며 챙길 값어치가 있습니다. Secure를 요구하고 Domain을 아예 금지하며 Path=/를 강제하는데, 이 셋을 합치면 그 쿠키가 정확히 한 호스트의 것이고 어떤 서브도메인이나 형제 호스트도 그것을 쓸 수 없었다는 뜻이 됩니다. __Secure-는 Secure만 요구하므로 쿠키가 HTTPS로 왔다는 것만 말할 뿐 누가 설정했는지는 말해 주지 않습니다.

쿠키의 범위는 출처(origin)와 같지 않고, 보안상의 뜻밖의 일은 대개 이 틈으로 빠집니다. 쿠키는 포트를 무시하므로 같은 호스트의 :3000 서비스와 :8080 서비스가 쿠키를 공유합니다. 스킴도 대체로 무시해서, Secure가 없으면 평문 HTTP로 설정된 쿠키를 그 호스트의 HTTPS에서 읽을 수 있습니다. 그리고 Domain=example.com 쿠키는 모든 서브도메인에 보이므로, 그중 어느 하나가 그것을 덮어쓸 수 있습니다.

둘 다 있으면 Max-Age가 Expires를 이기고, Expires는 클라이언트 시계를 기준으로 해석되므로 기기 시계가 틀리면 쿠키가 일찍 만료되거나 날짜를 넘겨 남습니다.

자주 묻는 질문

SameSite=None; Secure 필수 이유?

Chrome 80 이후 모던 브라우저는 Secure 없는 사이트 간 쿠키 거부 — 서드파티 컨텍스트 쿠키 전송을 원하면 HTTPS로 전달되어야 함. 도구가 Secure 없는 SameSite=None을 표시해 배포 전 잡기.

__Host- 쿠키란?

이름이 __Host-로 시작하는 쿠키는 엄격 규칙 적용: Secure 필수, Domain 속성 없어야 함, Path=/ 필수. 이는 강한 호스트 스코프를 만들어 — 1자 인증에 편리.

Set-Cookie에 여러 줄 필요 이유?

HTTP 응답은 여러 Set-Cookie 헤더 운반 가능하지만 한 줄 통합 불가 — 각 쿠키 값이 합법적으로 쉼표 포함 가능(예: 날짜). 도구가 그 규약 따름: 줄 하나에 쿠키 하나.

요청 헤더가 응답에서 설정한 것보다 훨씬 적게 담고 있는 이유는?

브라우저는 이름과 값만 돌려보내기 때문이다. 만료, 경로, 도메인, SameSite, HttpOnly, Secure 같은 속성은 전부 쿠키를 언제 보낼지에 대한 브라우저용 지시이지 서버로 갈 데이터가 아니어서, Set-Cookie에는 있고 Cookie에는 결코 없다. 나중에 서버에서 어떤 속성 값이 필요하다면 쿠키 값 안에 넣거나 서버 쪽 저장소에 두어라.

이름이 같은 쿠키가 둘이다. 어느 게 내 것인가?

헤더만으로는 알 수 없고, 그게 곤란한 지점이다. 요청은 경로나 도메인 없이 이름-값 쌍만 나열하므로, 서브도메인이나 더 좁은 경로에서 설정된 쿠키가 내 것과 똑같아 보이는 채로 도착한다. 브라우저는 더 구체적인 경로를 먼저 보내지만 그건 보장이 아니라 관례다. 순서에 기대지 말고 이름에 접두사를 붙여 구분되게 하라.

관련 도구

Cookie / Set-Cookie 헤더 빌더

이름/값 + 보안 속성(SameSite·Secure·HttpOnly·Partitioned·Max-Age)으로 Set-Cookie 응답 헤더 작성, 안전 경고 포함.

네트워크

HTTP 헤더 참조

표준 HTTP 요청·응답·CORS·캐싱·보안·쿠키 헤더 약 50개의 검색 가능한 참조.

개발

HTTP Basic 인증 인코더/디코더

username:password를 Base64 Authorization: Basic 헤더로 인코딩 — 또는 기존 헤더 붙여넣어 누군지 확인.

네트워크

Cache-Control 헤더 빌더

체크리스트로 HTTP Cache-Control 헤더 생성 — 프레시니스·재검증·immutable·자주 쓰는 프리셋.

네트워크

.gitattributes 테스터

.gitattributes와 경로 목록을 붙여넣으면 각 경로에 최종 적용되는 모든 속성과, 그 값을 정한 줄 또는 매크로를 보여줍니다.

개발

JWT 디코더

JWT의 헤더·클레임·만료를 즉시 확인하세요.

개발