쿠키 옵션(SameSite, HttpOnly, Secure): 웹 보안을 바꾸는 작은 설정들

쿠키 옵션이 문제로 드러나는 실제 장면부터 잡는다

쿠키 옵션(SameSite, HttpOnly, Secure)은 로그인은 했는데 다음 화면에서 갑자기 로그아웃되거나, 결제/관리자 페이지에서만 세션이 풀리는 상황을 순서대로 점검하는 기준이 된다.

예를 들어 서비스는 정상인데 특정 브라우저(모바일 사파리, 회사 PC 크롬)에서만 로그인 유지가 안 되거나, 프런트와 백엔드가 분리된 환경에서 인증 쿠키가 요청에 붙지 않는 현상이 나온다.

이때 개발자 도구에서는 쿠키가 저장된 것처럼 보이는데 실제 API 요청에는 쿠키가 누락되기도 한다. 문제는 "쿠키가 있느냐 없느냐"가 아니라 "쿠키가 어느 조건에서 전송되도록 설정되어 있느냐"로 이동한다.

핵심 개념 1: SameSite가 바꾸는 전송 범위와 CSRF 방어

SameSite는 쿠키가 "다른 사이트에서 시작된 요청"에도 함께 전송될지 여부를 조절하는 옵션이다. 브라우저는 외부 링크 클릭, 폼 전송, iframe 로딩 등 다양한 맥락에서 요청을 만들며, SameSite는 이런 맥락에서 쿠키를 붙일지 결정한다.

SameSite=Lax는 일반적인 탐색(링크 클릭, 주소창 입력)에서는 쿠키를 보내지만, POST 폼 제출이나 외부 사이트 iframe에서는 제한한다. 대부분의 modern 브라우저가 기본값으로 설정하는 수준이며, 외부 유입 로그인 흐름이 많은 서비스에서 호환성이 좋다.

SameSite=Strict는 교차 사이트 맥락을 거의 모두 차단한다. 보안엔 가장 유리하지만, 외부 링크를 따라 로그인 페이지로 넘어간 후 세션이 유지되지 않거나, 외부에서 리다이렉트로 들어올 때 인증 쿠키가 붙지 않을 수 있다.

SameSite=None은 교차 사이트에서도 쿠키 전송을 허용한다. 다른 도메인의 iframe이나 외부 API 호출에서 인증 쿠키를 보내야 할 때 사용한다. 대신 보안 위험이 커지므로 반드시 Secure 옵션과 함께 사용해야 한다. Secure가 없으면 브라우저가 쿠키를 저장하지 않거나 전송하지 않을 수 있다.

쿠키 옵션이 쿠키 전송 조건을 바꾸는 구조

핵심 개념 2: HttpOnly와 Secure가 바꾸는 노출 경로와 통신 조건

HttpOnly는 자바스크립트에서 쿠키를 읽지 못하게 막는 옵션이다. 이 옵션이 켜져 있으면 document.cookie로 토큰을 꺼내는 방식은 불가능해진다. 대신 쿠키는 HTTP 요청에 자동으로 붙는 인증 수단으로 쓰는 쪽이 일반적이다.

프런트에서 "쿠키 값을 직접 읽어서 Authorization 헤더로 옮기는 구조"를 사용 중이라면 HttpOnly 때문에 기능이 깨진다. 이 경우 설계 자체를 쿠키 기반 세션으로 바꾸거나, JWT 토큰을 localStorage에 저장하는 방식으로 전환해야 한다. 토큰 저장소를 분리하고 자동 전송 메커니즘을 정리하는 과정이 필요하다.

Secure는 HTTPS 연결에서만 쿠키를 전송하도록 제한한다. 개발 환경에서 http://localhost로 테스트할 때 Secure 쿠키가 전송되지 않아 로그인 유지가 안 되는 것처럼 보일 수 있다. 운영에서는 HTTPS가 기본이므로 문제가 없어도, 개발/스테이징에서만 실패하는 전형적인 패턴이 생긴다. 이를 해결하려면 개발 환경도 HTTPS로 구성하거나, 개발용 쿠키 설정을 따로 관리해야 한다.

옵션별로 무엇이 달라지는지 비교표로 정리한다

쿠키 옵션은 각각 역할이 다르며, 조합에 따라 증상이 달라진다. 아래 표는 문제를 분류하기 위한 기준이다.

항목	SameSite	HttpOnly	Secure
제어 대상	교차 사이트 맥락에서 쿠키 전송 범위	자바스크립트에서 쿠키 읽기 가능 여부	HTTPS가 아닐 때 쿠키 전송 여부
대표 증상	외부 유입/리다이렉트 뒤 로그인 유지 실패, 프론트-백 분리에서 인증 쿠키 누락	프론트 코드에서 쿠키를 못 읽어 토큰 전달이 끊김	HTTPS에서는 되는데 HTTP 개발 환경에서만 세션이 안 붙음
주요 주의점	None을 쓰면 Secure가 필수인 경우가 많다	토큰을 JS로 읽는 설계라면 깨질 수 있다	개발과 운영의 프로토콜이 다르면 오진이 생긴다

YES/NO 체크리스트로 빠르게 원인을 좁힌다

• YES/NO: 로그인 후 다음 API 호출에서 요청 헤더에 Cookie가 실제로 포함되는가?
• YES/NO: 프런트와 백엔드의 도메인(또는 포트)이 서로 다른가?
• YES/NO: 쿠키가 SameSite=None인데 Secure가 꺼져 있는가?
• YES/NO: 프런트 코드에서 document.cookie로 인증 값을 읽는 구조인가?
• YES/NO: 개발 환경이 HTTP인데 운영 설정 그대로 Secure 쿠키를 쓰고 있는가?

YES가 나오는 질문은 "쿠키가 저장은 되지만 전송/읽기 조건에서 걸린다"는 방향으로 연결된다. 반대로 Cookie 자체가 전혀 저장되지 않는다면 도메인/경로(path) 설정이나 Set-Cookie 응답 자체를 먼저 점검해야 한다.

쿠키 옵션 점검 6단계 흐름

실전 점검 절차

1. Set-Cookie를 확인한다. 개발자 도구 → Network → 로그인/세션 생성 요청 → Response Headers에서 Set-Cookie가 존재하는지, SameSite/HttpOnly/Secure가 어떻게 붙었는지 확인한다.
2. 브라우저 저장 여부를 확인한다. 개발자 도구 → Application(또는 Storage) → Cookies에서 해당 도메인에 쿠키가 실제로 저장됐는지 확인한다.
3. 다음 요청에 쿠키가 붙는지 확인한다. Network → 보호된 API 요청 → Request Headers에서 Cookie 헤더가 포함되는지 확인한다.
4. 교차 사이트 맥락인지 확인한다. 요청 URL과 페이지 URL을 비교해서 스킴·호스트·포트가 달라 출처가 갈리는지, 리다이렉트/외부 유입이 끼는지 확인한다.
5. HTTPS 조건을 확인한다. 주소창 스킴 확인 및 Network의 요청 URL을 보고, Secure 쿠키인데 HTTP로 테스트 중인지, 스테이징이 HTTPS인지 확인한다.
6. 프런트 코드의 쿠키 사용 방식을 확인한다. 인증 처리 코드에서 document.cookie로 읽는지, 쿠키 자동 전송을 전제로 하는지, HttpOnly와 충돌하는지 확인한다.

실전에서는 개발자 도구에서 쿠키를 보면 값이 존재하지만, 요청 헤더에는 Cookie가 붙지 않는 경우가 자주 나온다. Application 탭 Cookies에는 세션 쿠키가 보이는데 Network 탭 Request Headers에는 Cookie가 없고, Console에 "Failed to fetch" 또는 인증 실패 응답이 나오는 상황이다.

이 흐름은 SameSite 제한이나 Secure 조건 때문에 "저장은 됐는데 전송이 차단"되는 쪽으로 연결되기 쉽다. 이때 적합한 해결책은 실제 서비스 구조(교차 사이트 여부, HTTPS 강제 여부, 프런트에서 쿠키를 읽어야 하는지)에 맞춰 SameSite/HttpOnly/Secure 조합을 다시 설정하는 것이다.

잘못된 해결책은 문제를 급히 피하려고 SameSite=None을 무조건 적용하거나, HttpOnly를 꺼서 토큰을 JS에서 읽게 만드는 방식이다. 이런 접근은 보안 표면을 넓히고 재발 원인을 숨길 수 있다.

결론

쿠키 옵션(SameSite, HttpOnly, Secure)은 "전송 조건"과 "노출 경로"를 바꾸는 설정이므로, 쿠키가 저장됐는지보다 요청에 붙는지부터 확인하는 흐름이 효율적이다. 교차 사이트 맥락이 끼면 SameSite가 먼저 의심 대상이 되고, HTTPS가 아닌 환경에서는 Secure가 원인으로 떠오르기 쉽다. 프런트가 쿠키를 읽어 토큰을 옮기는 구조라면 HttpOnly가 설계를 바꾸는 스위치가 된다.

연계 주제로는 CORS와 credentials 조합, CSRF 방어 방식(토큰/더블 서브밋), 세션 쿠키와 JWT 토큰 저장 전략 비교가 있다. 이들을 함께 이해하면 인증/인가 설계에서 쿠키 옵션의 위치와 역할이 더 선명해진다.

FAQ

SameSite=None을 쓰면 왜 Secure가 같이 필요한가

교차 사이트 전송을 허용하는 설정은 공격 표면이 넓어질 수 있으므로, 브라우저가 HTTPS 전송(Secure) 조건을 함께 요구한다. Secure가 없으면 브라우저가 쿠키를 저장하지 않거나 전송하지 않는 것처럼 보일 수 있으므로, 항상 함께 설정해야 한다.

HttpOnly가 켜져 있으면 프런트에서 인증 처리를 못 하는가

자바스크립트로 쿠키 값을 직접 읽는 방식은 불가능해진다. 대신 쿠키 자동 전송 기반 세션을 쓰거나, JWT 토큰을 localStorage 또는 sessionStorage에 저장해서 Authorization 헤더로 보내는 구조로 설계를 변경해야 한다.

개발 환경에서만 로그인 유지가 안 되는 이유는 무엇인가

운영은 HTTPS인데 개발은 HTTP인 경우, Secure 쿠키가 개발 환경에서 전송되지 않아 세션이 붙지 않을 수 있다. 이때는 개발용 HTTPS 적용 또는 개발/운영 설정 분리(environment variable)로 쿠키 옵션을 동적으로 바꾸는 방식이 효과적이다.