콕플을 개발할때, 로그인 유지를 위해 리프레시 토큰을 쿠키에 저장해서 사용했다.
크롬에서는 분명 쿠키가 저장됐고, 로그인도 정상적으로 유지됐다.
그런데 이상하게 휴대폰으로 접속하면 로그인이 유지가 되지 않는 문제가 있었다.
직접 맥북 사파리로 들어가서 확인하니….

쿠키는 저장되지 않았다..🖕
쿠키는 서버가 브라우저에게 주는 데이터이다.
서버는 응답할 때 Set-Cookie 헤더를 내려주고, 브라우저는 그걸 저장했다가 다음 요청 때 다시 서버로 보낸다. 이렇게 해서 로그인 상태 유지, 사용자 식별 같은 기능을 만든다.
Set-Cookie: refreshToken=abc123; Path=/; Secure; SameSite=None
이건 서버가 브라우저에게 “refreshToken=abc123 이 값을 쿠키로 저장해” 라고 하는것이다.
쿠키는 단순히 “서버가 내려주면 브라우저가 저장하는 값”이 아니라, 브라우저가 도메인 구조와 보안 정책을 보고 저장 여부를 판단하는 데이터이다.
도메인은 쉽게 웹사이트 주소 이름이다. (ex: google.com, naver.com 등등)
그럼 www.naver.com같은 건 뭐냐면, naver.com이라는 큰 주소 아래 붙은 서브도메인이다.
즉,
처음 배포 구조는 아래와 같았다.
이 구조에서는 프론트와 백엔드의 도메인이 완전히 달랐다.
즉, 브라우저 입장에서는 다른 사이트 간 요청으로 보게 되는 것이다.
이런 상황을 cross-site 또는 cross-origin 맥락이라고 부른다.
쉽게 말해서 한 사이트에서 다른 사이트로 오가는 상황이다.
예를 들면:
이건 브라우저 입장에서 “같은 사이트가 아니라 다른 사이트랑 통신한다!”라고 본다.
원래 쿠키는 민감한 데이터를 담는 경우가 많아서 브라우저가 아무 사이트에나 쿠키를 막 뿌려주면 보안 문제가 생길 수 있기 때문이다. 그래서 브라우저는 같은 사이트인지를 확인해서 더 조심하게 처리한다.
브라우저 정책의 차이이다.
Chrome
Chrome은 개발자가 SameSite=None; Secure 같은 설정을 명시하면,
”이 쿠키가 다른 사이트 간 요청에서도 쓰는구나”라고 보고 혀용한다.
Safari
Safari는 ITP(Intelligent Tracking Prevention)라는 추적 방지 정책 때문에, 다른 사이트 간 요청에서 내려오는 쿠키를 훨씬 더 엄격하게 본다.
즉,
cockple.vercel.app → cockple.site 요청은 Safari 입장에서는 추적성 있는 cross-site 쿠키 흐름처럼 보일 수 있고, 그래서 쿠키 저장이 막힌다.
Safari는 cross-site 쿠키에 민감하기 때문에, 프론트와 백엔드의 도메인을 같은 계열로 맞추면 된다고 생각했다.
둘이 도메인을 맞췄는데도, 해결이 안되었다.. 사파리에 여전히 저장이 안됨..
백엔드가 내려주던 쿠키는 대략 이런 형태였다.
Set-Cookie: refreshToken=abc123; Path=/; Secure; SameSite=None
여기에는 Domain 속성이 없었다.
쿠키에 Domain을 안 쓰면 그 쿠키는 host-only cookie가 된다. 즉, 쿠키를 내려준 정확한 호스트에만 유효한 쿠키가 되는 것이다.
쉽게 말하면:
그러면 같은 cockple.site 계열이어도 www.cockple.site와 공유되는 형태가 아니다.
기존에는
Set-Cookie: refreshToken=abc123; Path=/; Secure; SameSite=None
이렇게 내려왔고, 백엔드에 아래처럼 Domain 속성을 추가해달라고 했다.
Set-Cookie: refreshToken=abc123; Domain=.cockple.site; Path=/; Secure; SameSite=None
이렇게 하면 브라우저는 “이 쿠키는 cockple.site와 그 하위 서브도메인들에도 적용하는군!”이라고 이해한다.
즉,
이러면 Sfari에서도 쿠키가 제대로 저장되고, 로그인 유지가 정상 동작하게 된다.

웹 개발을 할 때, 여러 브라우저에서 테스트해야겠구나!!!!