SameSite 쿠키란 무엇인가
웹 브라우저는 로그인 정보나 세션 값을 쿠키에 저장해 서버와 주고받습니다. 그런데 이 쿠키가 ‘내가 요청하지 않은 사이트’로도 자동 전송된다는 점이 문제입니다. 공격자가 만든 페이지에서 은행 사이트로 요청을 보내면, 브라우저는 별생각 없이 은행 쿠키를 함께 실어 보냅니다. 이것이 CSRF(Cross-Site Request Forgery) 공격의 핵심 원리입니다.
SameSite는 이런 상황을 막기 위해 쿠키에 붙이는 속성입니다. 쉽게 말해 ‘이 쿠키는 같은 사이트에서 온 요청에만 실어 보내라’고 브라우저에게 지시하는 규칙표라고 생각하면 됩니다. 마치 회사 출입증을 우리 회사 건물에서만 쓰도록 제한하고, 다른 건물에서는 인식조차 안 되게 만드는 것과 비슷합니다.
동작 원리와 세 가지 값
SameSite는 쿠키 발급 시 Set-Cookie 헤더에 함께 지정합니다. 예를 들면 다음과 같습니다.
Set-Cookie: sessionId=abc123; SameSite=Lax; Secure
SameSite에는 세 가지 값이 있습니다.
Strict: 오직 같은 사이트에서 시작된 요청에만 쿠키를 전송합니다. 다른 사이트 링크를 클릭해 들어와도 쿠키가 빠집니다. 보안은 가장 강하지만 외부 링크 클릭 시 로그인 상태가 풀리는 불편함이 있습니다.Lax: 기본값에 가까운 절충안입니다. 사용자가 직접 링크를 클릭해 이동하는 경우(GET 방식 최상위 이동)에는 쿠키를 보내지만, 이미지 태그나 폼 자동 제출 같은 숨겨진 요청에는 쿠키를 보내지 않습니다. 대부분의 서비스에서 무난하게 쓰입니다.None: 모든 요청에 쿠키를 전송합니다. 단, 이 값을 쓰려면 반드시Secure속성을 함께 붙여 HTTPS에서만 동작하도록 해야 합니다. 서로 다른 도메인 간 연동이 필요한 결제 위젯이나 SSO 서비스에서 사용합니다.
실무에서 왜 쓰는지
SameSite는 CSRF 토큰 검증과 함께 쓰이는 ‘추가 방어선’입니다. CSRF 토큰이 애플리케이션 레벨의 검증이라면, SameSite는 브라우저 레벨에서 애초에 위험한 요청을 차단해 버립니다. 최근 크롬, 파이어폭스 등 주요 브라우저는 SameSite를 지정하지 않으면 자동으로 Lax를 기본값으로 처리해 개발자가 실수로 노출시키는 상황을 줄여줍니다.
실무에서는 로그인 세션 쿠키에 SameSite=Lax 또는 Strict를 지정하고, 외부 도메인과 연동이 필요한 쿠키에만 예외적으로 SameSite=None; Secure를 적용하는 방식이 일반적입니다. CSRF 토큰만 믿기보다 SameSite 속성을 함께 설정해 이중, 삼중으로 방어하는 것이 안전한 서비스 운영의 기본입니다.