서론
오늘은 프로젝트를 진행하며 쿠키에 대한 이해 부족으로 인해 발생한 문제와, 이를 어떻게 해결했는지의 과정을 공유해보려 한다.
사실 이번 프로젝트 이전까지는 쿠키의 동작 원리나 저장 방식에 대해 깊이 이해하고 있지 못했다.
처음에는 백엔드(back.com)에서 쿠키를 발급하면, 요청을 보낸 프론트 도메인 (예: front.com)에 쿠키가 저장된다고 생각했고, 쿠키의 도메인 역시 당연히 front.com일 것이라 오해하고 있었다.
하지만 이후 쿠키에 대해 지피티와 인터넷 검색의 힘을 빌려 알아본 결과, 백엔드 서버(back.com)에서 쿠키를 발급하면 백엔드 주소(back.com)에 저장되는 것을 알게 되었다..
문제 상황
문제가 되는 상황은 아래와 같았다.
분명히 쿠키를 세팅을 하긴 하는데 오른쪽 끝에 보면 주의표시 같은 것이 있고
set cookie This attempt to set a cookie via a Set-Cookie header was blocked due to user preferences.
마우스를 가져다 대면 이런 메시지를 보여준다.
메시지를 보면,
사용자 선호도로 인해 Set-Cookie 헤더를 통해 쿠키를 설정하려는 시도가 차단되었습니다.
즉, 어떠한 설정 때문에 해당 쿠키를 설정하려는 시도가 차단되었다고한다.
1. 서드파티쿠키 설정 (실패)
여기저기 알아보다가 질문한 오픈채팅방에서 서드파티쿠키가 차단되어있나 확인해보라는 답을 얻어 확인해 보았다.
테스트 하고 있는 브라우저는 엣지였는데 타사 쿠키 차단이 설정 되어있었다.
해당 설정을 변경하고 실행하니 정상적으로 쿠키가 세팅되는 것 처럼 보였다.
하지만 위 해결방법은 결과적으로 실패했는데, 어떤 이유에서인지 페이지 이동 또는 브라우저 창을 새로고침하면 쿠키가 날라가버렸다.
(중요)
이후 찾아보니 대부분의 브라우저들이 서드파티 쿠키를 점점 더 강하게 차단하는 방향으로 나아가고 있다고 한다.
서드파티쿠키
브라우저는 쿠키의 도메인이 현재 보고 있는 웹사이트의 도메인과 일치할 때만, 그 쿠키를 "퍼스트 파티 쿠키"로 간주해 자동으로 전송한다.
- 동일 도메인: 퍼스트 파티 → 자동 전송
- 다른 도메인: 서드파티 → 차단 또는 미전송
2. 프론트의 프록시 설정(성공)
현재 문제가 다른 api들과의 차이가 뭘까 곰곰히 생각해 보았다.
현재 소셜로그인 과정 이후 쿠키를 발급하는 api가 문제가 되는건데,
이전에 구현했던 일반 로그인 시 쿠키를 발급하는 api에서는 문제가 되지 않았다.
두 발급 방식이 거의 일치하기 때문에 문제가 없어야하지만 문제가 생긴다. 차이점이 무엇일까?
각 요청을 실행하고 개발자 도구를 통해 분석해 보았다.
먼저 정상적으로 동작하는 일반 로그인 api 호출시 네트워크의 headers 부분과 application에서 cookie를 보는 부분이다.
cookie의 도메인이 .vercel.app으로 되어있다.
자세히 보면 response headers의 server 부분이 vercel로 되어있다.
음..? 백엔드는 ubuntu인데 뭔가 이상함을 느꼈다.
다음으로 소셜로그인이다.
소셜 로그인 과정에서 response headers의 server 부분은 ubuntu고, cookie의 도메인이 .duckdns.org로 되어있다.
위 이미지들을 비교해 보면 쿠키 설정이 응답하는 서버에 따라 달라지는 것을 알 수 있었다.
현재 상황을 정리하자면,
실제로 요청은 vercel 서버에서 하고 응답을 ubuntu(backend server)에서 하고있다.
하지만 개발자 도구상에서는 요청과 응답을 모두 Vercel에서 하고 있는 것 처럼 보인다.
실제 상태와 무관하게 Vercel에서 응답하는 것 처럼 보이는 API에서 쿠키가 정상적으로 동작한다.
왜 이러한 현상이 발생하는 걸까?
원인은 프론트엔드 팀원들이 작성한 코드를 보고 알게 되었다.
먼저, 쿠키는 본인 도메인에 설정된 쿠키만을 자동으로 전송한다.
즉, 프론트엔드와 백엔드의 도메인이 다를 경우, 쿠키가 올바르게 전달되지 않을 수 있다.
이를 해결하기 위해 프론트에서 프록시 설정을 통한 해결을 한것이었다.
프론트엔드에서 백엔드로 요청을 보낼 때, 프록시를 사용하여 응답이 Vercel 도메인에서 온 것처럼 동작하도록 설정하고, 쿠키 도메인이 프론트와 같아지도록 하여 브라우저는 이를 퍼스트 파티 쿠키로 인식하고 정상적으로 저장할 수 있게 된다.
하지만 위 문제는 프록시 설정으로 인해 발생한 문제가 아니었다. 프록시 설정자체에는 문제가 없었는데, 프론트엔드 팀원의 사소한 실수로 발생한 문제였다.
코드를 보면 프록시 설정에는 이상이 없었지만 소셜로그인 호출 과정에서 상대경로가 아닌 절대경로를 입력하여 발생한 문제였다.
결론
사소한 실수로 일어난 문제였지만 덕분에 새로운 내용을 배울 수 있었다.
- 쿠키는 응답하는 곳의 도메인을 기준으로 쿠키의 도메인이 설정된다.
- 도메인 주소가 다르면 프론트엔드에서 프록시를 통해 해결이 가능하다.
- 프론트에서 프록시 설정 시 상대주소를 사용해야한다.
- 서드파티 쿠키 정책에 대해 알게 되었다.
(추가) 카카오는 왜 정상일까
한편, 카카오 로그인의 경우 쿠키가 서드파티 쿠키로 설정되었음에도 쿠키 세팅 상태에 문제가 없었다.
GPT의 답변에 따르면, 카카오와 같은 대형 플랫폼은 브라우저 또는 OS 단에서 예외적으로 허용될 수 있다.
이는 브라우저가 신뢰할 수 있는 도메인을 내부 정책으로 화이트리스트 처리하거나,
OAuth 흐름에서 특정 토큰 기반 인증만으로도 충분히 세션을 관리할 수 있기 때문일 수 있다.
하지만 이는 명확한 스펙이 아니라, 브라우저 및 플랫폼의 정책에 따라 다르게 동작할 수 있다.
