쿠키 보안 속성, Secure·HttpOnly·SameSite 뜻 3가지

쿠키 보안 속성은 Secure로 HTTPS 전송만, HttpOnly로 스크립트 읽기 차단, SameSite로 외부 요청을 제한합니다. 이 글에서는 세 속성이 막는 위험, SameSite 값 고르는 기준, 개발자 도구로 로그인 쿠키를 점검하는 방법을 정리했습니다.

쿠키 보안 속성이 왜 중요한가

쿠키는 사이트가 방문자 브라우저에 저장해 두는 작은 정보입니다. 로그인한 뒤 페이지를 옮겨도 계속 로그인 상태가 유지되는 것은 세션 쿠키 덕분입니다. 이 세션 쿠키를 다른 사람이 손에 넣으면 비밀번호 없이도 그 사람인 척 사이트를 쓸 수 있습니다.

그래서 로그인 쿠키에는 어떻게 보내고 누가 읽을 수 있는지를 제한하는 속성을 붙입니다. 서버가 Set-Cookie 헤더로 쿠키를 보낼 때 함께 적는 값이며, 방문자가 따로 할 일은 없습니다. 쿠키를 쓴다는 사실을 방문자에게 알리는 방법은 다른 주제이므로 쿠키 사용 안내 글을 참고하세요.

Secure·HttpOnly·SameSite 세 가지 속성의 뜻

아래 표는 MDN의 Set-Cookie 헤더 문서를 바탕으로 세 속성이 하는 일과 막아 주는 위험을 비교한 것입니다.

속성	하는 일	줄여 주는 위험
Secure	HTTPS 연결에서만 쿠키를 서버로 보냅니다. http 사이트는 이 속성의 쿠키를 만들 수 없습니다.	암호화되지 않은 연결에서 쿠키를 가로채는 중간자 공격
HttpOnly	document.cookie 같은 자바스크립트로 쿠키를 읽지 못하게 합니다. 서버로는 그대로 전송됩니다.	XSS로 삽입된 스크립트가 로그인 쿠키를 빼 가는 피해
SameSite	다른 사이트에서 시작된 요청에 쿠키를 함께 보낼지 정합니다.	CSRF처럼 다른 사이트를 거쳐 로그인 상태를 악용하는 공격

그림처럼 세 속성은 막는 위험이 서로 달라 하나만 켜서는 부족합니다. MDN은 Secure를 붙여도 쿠키가 완전히 안전해지는 것은 아니라고 설명합니다. 쿠키에는 비밀번호나 개인정보 같은 민감한 값을 넣지 않는 것이 기본입니다. 스크립트 삽입과 다른 사이트를 거친 요청 위조의 원리는 XSS 크로스사이트 스크립팅과 CSRF 공격 글에서 다뤘습니다.

SameSite 값 고르는 기준

SameSite에는 세 가지 값이 있습니다. 무엇을 고르느냐에 따라 보안과 편의가 달라집니다.

• Strict: 같은 사이트에서 시작된 요청에만 쿠키를 보냅니다. 다른 사이트의 링크를 눌러 들어와도 처음에는 로그인되지 않은 상태로 보일 수 있습니다.
• Lax: 같은 사이트 요청에 더해, 다른 사이트에서 링크를 눌러 이동하는 것처럼 주소창이 바뀌는 GET 이동에만 쿠키를 보냅니다. 이미지, iframe, fetch 같은 하위 요청에는 보내지 않습니다.
• None: 다른 사이트 요청에도 쿠키를 보냅니다. 이 값을 쓰려면 Secure도 함께 지정해야 합니다.

일반적인 회사·기관 홈페이지의 로그인 쿠키라면 Lax로 시작하고, 관리자 화면처럼 더 엄격해도 되는 곳은 Strict를 검토합니다. None은 외부 결제창이나 다른 도메인의 위젯처럼 꼭 필요한 경우에만 씁니다. MDN에 따르면 SameSite를 생략하면 일부 브라우저가 Lax처럼 다루지만 브라우저마다 다를 수 있으므로, 값을 직접 적는 편이 안전합니다.

쿠키 이름 접두어

쿠키 이름을 __Host-로 시작하면 브라우저가 Secure, Path=/, Domain 속성 없음 조건을 지킨 쿠키만 받아들입니다. 하위 도메인에서 같은 이름의 쿠키를 덮어쓰지 못하게 하는 장치로, 개발 담당과 상의해 쓸 수 있습니다.

내 사이트 로그인 쿠키 점검 방법

크롬이나 엣지에서 내 사이트에 로그인한 뒤 개발자 도구(F12)를 열고 애플리케이션 탭의 쿠키 항목을 보면, 쿠키마다 Secure, HttpOnly, SameSite 칸이 표시됩니다. 아래 다섯 가지를 확인합니다.

• Secure 표시 확인: HTTPS 사이트라면 로그인 관련 쿠키에 모두 체크돼 있어야 합니다.
• HttpOnly 표시 확인: 세션 쿠키는 화면 코드가 읽을 필요가 없으므로 체크돼 있어야 합니다.
• SameSite 값 지정: 비어 있지 않고 Lax나 Strict로 적혀 있는지 봅니다.
• None은 꼭 필요할 때만: None이라면 이유가 있는지, Secure가 함께 있는지 확인합니다.
• 쿠키에 민감정보 금지: 쿠키 값에 이메일, 전화번호 같은 정보가 그대로 보이지 않는지 봅니다.

그림의 항목 가운데 하나라도 빠져 있다면 CMS나 프레임워크의 세션 설정에서 바꿀 수 있는 경우가 많습니다. 설정 위치는 사이트마다 다르므로 유지보수 담당에게 점검 결과를 보여 주고 조치를 요청하면 됩니다.

디코랩이 돕는 방식

디코랩은 운영 중인 사이트의 유지보수와 개선을 맡고, 웹사이트 취약점 점검 서비스로 쿠키와 보안 헤더 설정을 포함한 사이트 상태를 확인합니다. 설정을 바꿀 때 로그인이 풀리는 등의 영향이 있는지 함께 안내합니다.

자주 묻는 질문

회원 기능이 없는 홈페이지도 쿠키 보안 속성이 필요한가요?

방문자 로그인이 없어도 관리자 로그인 쿠키는 있습니다. 관리자 쿠키에는 세 속성을 모두 지정하는 것이 좋습니다.

HttpOnly를 켜면 사이트 기능이 멈추지 않나요?

세션 쿠키는 서버만 읽으면 되므로 대부분 영향이 없습니다. 화면 코드가 직접 읽어야 하는 쿠키가 있다면 그 쿠키에 민감한 값이 없는지 따로 확인합니다.

SameSite를 Strict로 바꾸면 무엇이 불편해지나요?

메일이나 다른 사이트의 링크를 눌러 들어올 때 로그인되지 않은 것처럼 보일 수 있습니다. 불편이 크면 Lax를 씁니다.

쿠키 속성만 바꾸면 CSRF가 완전히 막히나요?

SameSite는 피해를 줄이는 장치이며, 중요한 요청에는 CSRF 토큰 같은 서버 쪽 확인을 함께 두는 것이 좋습니다.

우리 홈페이지 로그인 쿠키 설정이 안전한지 확인하고 싶다면 사이트 주소를 적어 디코랩 프로젝트 문의로 보내 주세요.