서버가 브라우저에 저장시키는 작은 이름-값 데이터. 브라우저는 조건이 맞는 요청마다 쿠키를 자동으로 실어 보내므로, 상태가 없는 HTTP 위에서 로그인 같은 상태를 이어 가는 데 쓴다.
→ Set-Cookie: sid=abc123; Path=/; HttpOnly; Secure; SameSite=Lax; Max-Age=86400
← Cookie: sid=abc123주로 서버가 Set-Cookie로 만들고, HttpOnly가 아닌 쿠키는 JS(JavaScript)의 document.cookie로도 만들고 읽을 수 있다.
어디로 보내나: Domain과 Path
- Domain 생략: 쿠키를 설정한 호스트에만 보낸다. 서브도메인과 공유하지 않는다
- Domain 지정(
Domain=example.com): 그 도메인과 모든 서브도메인에 보낸다. 앞에 점을 붙인.example.com은 옛 표기이고 지금 스펙에서는 점을 무시한다. 다른 도메인으로는 지정할 수 없다 - Path:
/로 구분되는 경로 접두사로 매칭한다.Path=/foo면/foo,/foo/bar에는 가지만/,/foobar에는 안 간다. 생략하면 쿠키를 설정한 요청 URL 경로의 디렉터리가 기본값이다(/docs/a.html→/docs/)
보안 속성
- Secure: HTTPS(HTTP Secure) 요청에만 보낸다
- HttpOnly: JS에서 읽을 수 없다. XSS(Cross-Site Scripting)로 스크립트가 주입돼도 세션 쿠키를 훔치지 못한다. 요청에는 정상적으로 실린다
- SameSite: 다른 사이트에서 시작된 요청에 쿠키를 실을지 정한다
Strict: 같은 사이트 요청에만. 다른 사이트의 링크를 타고 오면 로그인이 풀린 것처럼 보인다Lax: 다른 사이트에서 오는 최상위 이동(링크 클릭 GET)에는 싣고, POST 같은 교차 사이트 요청과fetch·img에는 안 싣는다. 속성을 생략하면 Chrome·Edge 같은 Chromium 계열은 이 값으로 취급한다(Firefox·Safari는 그렇지 않다, 2026 기준)None: 항상 싣는다.Secure가 필수다- 쿠키 자동 전송이 CSRF(Cross-Site Request Forgery)의 원인이고,
SameSite=Lax가 그 위험을 크게 줄였다
수명과 크기
Expires(날짜)나Max-Age(초)가 없으면 브라우저를 닫을 때 지워지는 세션 쿠키(Session Cookie)다. 둘 다 있으면Max-Age가 우선한다- 쿠키 하나는 약 4KB까지. 해당 도메인의 모든 요청에 실리므로 작게 유지한다. 큰 데이터는 localStorage와 sessionStorage에 둔다
함께 볼 것
- 쿠키로 세션 id를 들고 다니는 방식 → 세션 인증, 토큰을 쿠키에 담을 때 → JWT
- 다른 출처 API에 쿠키를 보내려면
credentials: 'include'와 서버의 CORS 설정이 필요하다 → CORS, 동일 출처 정책 - 서버 코드는 이런 규칙과 무관하게 아무 쿠키나 헤더에 넣을 수 있다 → 브라우저 요청과 서버 간 요청
- 로컬 개발에서 운영 도메인 쿠키를 쓰려면 → hosts 파일
출처: MDN — Using HTTP cookies · MDN — Using HTTP cookies: Define where cookies are sent