Cookie / Set-Cookie 헤더 빌더
이름/값 + 보안 속성(SameSite·Secure·HttpOnly·Partitioned·Max-Age)으로 Set-Cookie 응답 헤더 작성, 안전 경고 포함.
Set-Cookie: session=abc123; Path=/; SameSite=Lax; Secure; HttpOnly
이 헤더를 응답에 실어 보내세요. 브라우저가 쿠키를 저장하고, 이후 도메인과 경로가 일치하는 요청에는 Cookie: name=value를 자동으로 붙여 보냅니다.
사용법
- 유스케이스에 가장 가까운 프리셋에서 시작해 조정.
- 새 CSRF 토큰엔 strict 프리셋 — SameSite=Strict가 크로스 오리진 요청에 실리는 거 방지.
- 서드파티 임베드는 오늘 Chromium에서 동작하려면 SameSite=None + Secure + Partitioned 필요.
자세한 설명
펼치기접기
브라우저가 실제로 받아들이는 Set-Cookie 헤더를 만들어 줍니다. 속성은 명세가 권하는 순서로, 파서가 기대하는 표기로, 끝에 불필요한 세미콜론 없이 나옵니다. 프리셋은 실제 쿠키 대부분을 차지하는 네 가지 형태를 다룹니다. 짧은 세션 쿠키, 조금 더 긴 "로그인 유지", SameSite=None·Secure·Partitioned를 달고 다니는 서드파티 임베드 쿠키, 그리고 엄격한 CSRF 토큰입니다. 진단하는 데 시간이 가장 많이 드는 실수들에 대해서는 경고가 켜집니다.
Domain은 사람들의 기대와 정반대로 동작하는 속성입니다. 이 속성을 빼면 호스트 전용 쿠키가 되어, 설정한 바로 그 호스트에서만 읽힙니다. Domain=example.com을 지정하면 범위가 모든 하위 도메인으로 넓어집니다. 그러므로 쿠키를 한 호스트로 제한하는 방법은 호스트 이름을 적는 것이 아니라 속성을 생략하는 것입니다. 앞에 붙는 점은 역사적 잔재입니다. RFC 6265는 브라우저에게 그것을 무시하라고 하므로 .example.com과 example.com은 같은 뜻이고, 어느 쪽도 더 좁지 않습니다.
SameSite는 다른 사이트가 시작한 요청에 이 쿠키가 함께 실려 갈지를 정합니다. Strict는 동일 사이트 내 이동에서만 보내고, Lax는 최상위 문서 이동까지 포함하며(속성이 없을 때 최신 브라우저가 가정하는 값이 이것입니다), None은 어디로든 보냅니다. 다만 Secure가 함께 있어야 하고, 없으면 쿠키 자체가 거부됩니다. Partitioned는 임베드 환경을 위해 한 걸음 더 나아가, 최상위 사이트마다 별도의 사본을 주어 한 호스트의 페이지 안에서 설정된 쿠키를 다른 호스트에서 읽을 수 없게 합니다.
염두에 둘 제한이 셋 있습니다. __Host- 이름 접두어는 권고가 아니라 브라우저가 강제하는 규칙입니다. 그렇게 이름 붙인 쿠키는 Secure이고 Path=/이며 Domain이 아예 없어야만 받아들여집니다. 하나의 출처에 묶는 가장 강한 수단이 이것입니다. Max-Age와 Expires가 둘 다 있으면 Max-Age가 이깁니다. 그리고 크롬은 무엇을 요청하든 쿠키 수명을 400일로 제한하므로, 10년짜리 쿠키는 어디에서도 10년짜리가 아닙니다.
자주 묻는 질문
왜 SameSite=None은 Secure 필요?
Chromium은 Secure 없는 SameSite=None 쿠키 거부 — 쿠키 스펙이 서드파티 쿠키를 HTTPS로만 강제하는 방식, 네트워크 공격자 스니핑 방지.
Partitioned 속성은?
Partitioned(CHIPS)는 브라우저에 서드파티 쿠키를 최상위 사이트별로 스코핑하라고 지시. 없으면 Chrome 서드파티 쿠키 폐지가 쿠키 완전 차단; 있으면 임베드 동작하되 각 부모 사이트가 자기 jar 봄.
쿠키를 실제로 지우려면?
같은 쿠키를 과거 만료 시각으로 다시 보내되, 설정할 때 쓴 이름과 경로와 도메인을 그대로 맞춰라. 이 셋이 쿠키의 정체다. 경로나 도메인이 어긋나면 첫 번째가 지워지는 대신 두 번째 쿠키가 생긴다. 로그아웃했는데 로그인이 유지되는 것처럼 보이는 이유가 이것이고, 그때 중복 쿠키가 조용히 원본을 가린다.
브라우저가 저장량을 제한하는 이유는?
쿠키는 조건에 맞는 모든 요청에 실려 가므로 그 크기가 요청마다 드는 비용이기 때문이다. 브라우저는 쿠키 하나당 대략 4KB, 도메인당 수십 개를 허용하고, 서버는 지나치게 큰 헤더 블록을 아예 거부한다. 프록시가 내는 진단하기 어려운 400이나 431은 잘못된 요청이 아니라 쿠키가 쌓인 결과인 경우가 많다. 쿠키에는 식별자만 두고 데이터는 서버에 두어라.
관련 도구
HTTP 쿠키 파서
Cookie: 요청 헤더 또는 Set-Cookie: 응답 헤더 붙여넣기 → 각 쿠키의 이름·값·속성·경고 표시.
개발
HTTP 헤더 참조
표준 HTTP 요청·응답·CORS·캐싱·보안·쿠키 헤더 약 50개의 검색 가능한 참조.
개발
Cache-Control 헤더 빌더
체크리스트로 HTTP Cache-Control 헤더 생성 — 프레시니스·재검증·immutable·자주 쓰는 프리셋.
네트워크
HSTS 헤더 빌더
Strict-Transport-Security 헤더 구성 — max-age·includeSubDomains·preload, preload 리스트 자격 실시간 체크.
네트워크
Permissions-Policy 헤더 빌더
Permissions-Policy 응답 헤더 빌드 — camera·microphone·geolocation·payment·fullscreen 등 20+ 브라우저 기능을 오리진 허용 리스트로 토글.
네트워크
Referrer-Policy 헤더 빌더
Referrer-Policy 값 선택 → 송출 요청이 보낼 Referer 헤더 정확히 확인 — 동일 오리진, 크로스 오리진 HTTPS, HTTPS→HTTP 다운그레이드.
네트워크