💡Situation

---

프로젝트를 배포하기 직전 QA를 하던 중, 사파리 환경에서 쿠키가 저장되지 않아 로그인을 할 수 없는 문제가 발생했다.

로그인이 실패한 상황..

(나도 잡혔어)

상황 정리

• Access Token과 Refresh Token을 HTTP-ONLY 속성을 적용하여 쿠키에 저장하고 있다.
• 로그인 시 서버 측에서 쿠키에다가 Access Token을 담아서 클라이언트에 전달한다.
• 이후 클라이언트는 해당 쿠키를 저장하여 관리를 하는데, 쿠키를 저장하지 못해서 로그인에 실패하는 문제가 발생하고 있다.

위 코드는 로그인 관련 Service 메소드이다.
로그인 시 AccessToken과 RefreshToken을 발급하고 있다.

위 메소드는 AccessToken을 쿠키에 추가하는 메소드이다.

처음 시도 시 아이폰 환경에서 실패하여 IOS 문제인가? 싶었지만, 크롬이나 기타 브라우저에서는 잘 작동하였다.

그래서 아이패드, 아이폰, 맥북으로 전부 테스트해보니 IOS가 아닌 사파리 문제라는 것을 알게 되었다. 맥북에서 사파리 개발자모드를 열어서 확인해보니 쿠키가 저장되지 않는 상태를 확인했다.

요청 쿠키에 쿠키가 담기지 않는 모습

💡Task

---

1️⃣ Safari 환경에서 쿠키가 저장되지 않은 다양한 이유를 분석한다.

2️⃣ Safari 환경에서 쿠키를 저장할 수 있게 하여 정상적으로 로그인이 되도록 설정한다.

💡Action

---

📌 도메인과 쿠키의 관계

쿠키는 HTTP의 stateless 속성으로 인해, 정보를 웹사이트에 저장하여 서버로 요청을 보낼 때 사용한다.

쿠키는 생성된 도메인이 종속되며, 기본적으로 해당 도메인에서만 접근할 수 있다.

한번 예시를 들어보자. example.com에서 생성된 쿠키가 있다고 가정해보면,
다음 도메인에서 접근 가능하다.

• example.com
• www.example.com
• blog.example.com

하지만, 다음 도메인에서는 접근이 불가능하다.

• anotherdomain.com
• chip-sat.com

📌 그럼 Chrome 같은 다른 브라우저에서는 왜 될까?

바로 SameSite 옵션 덕분이다.

SameSite는 쿠키가 크로스 사이트 요청 시 전송될 수 있는지 여부를 결정하는 옵션이다.

• Strict : 반드시 같은 도메인에서만 사용 가능
• Lax: 같은 도메인에서만 사용 가능하지만, 유저가 링크를 클릭해서 접속하거나 하는 경우 다른 도메인에서도 사용 가능
• None : 다른 도메인에서도 사용 가능

현재 우리 프로젝트는 기존에 SameSite=None 설정을 두었다.

위 상황 덕분에, 프론트엔드와 서버의 도메인이 불일치 하더라도 크롬이나 기타 브라우저에서는 정상적으로 저장이 되었다.

그렇다면, Safari에서는 도대체 왜 저장이 되지 않았던 것일까?

그것은 바로 Apple의 ITP 정책 때문이다!

📌 ITP

Apple의 ITP 2.0 이란 ‘Intelligetn Tracking Prevention’ 이라는 뜻으로, Apple의 Safari 브라우저에서 사용자의 행동 추적을 억제하여 보안을 강화하기 위해 추가된 기능이다.

https://www.i-boss.co.kr/ab-74668-788

ITP 주요 특징

• 서드파티(제3자) 쿠키 완전 차단
• 사용자가 직접 방문하지 않은 도메인의 쿠키 및 로컬 저장소 차단
• JS 기반 쿠키/Storage 수명 제한 (최대 7일 등)
• 추적용으로 의심되는 도메인을 탐지하여 쿠키 저장 금지

많은 광고주와 분석 도구가 사용자의 웹 브라우징 습관을 추적해 개인화된 광고를 제공하려고 시도를 하고 있다. 이는 사용자의 데이터가 지나치게 많이 수집되고, 사생활 침해 우려가 커진다. 이에 따라 Apple에서는 광고 트래커의 분석 툴에서 발생하는 다양한 Cookie 정보를 지능적으로 억제하여 안정된 브라우저 환경인 ITP 2.0을 발표한 것이다.

따라서 ITP 2.0에서는 first party를 제외한 쿠키를 차단시키는데, 현재 우리 프로젝트에서 프론트엔드와 백엔드 도메인의 불일치로 인해 서드파티로 간주하여 쿠키 저장을 허용하지 않는 것이다.

• 프론트엔드 : chipsatbooks.vercel.app
• 백엔드 : chipsat.shop
  
  

이 두 도메인은 서로 완전히 다른 도메인으로 인식되므로, Safari는 이 요청을 크로스 사이트 요청, 즉 서드파티 요청으로 간주한다.

SameSite = None으로 설정하더라도, Safari는 ITP 정책에 따라 쿠키를 브라우저 저장소에 기록하지 않는다.

💡Result

---

✅ 해결 방법: 도메인 통합 전략

따라서, 우리는 커스텀 도메인을 구매하여 도메인을 일치시켜 이 문제를 해결하기로 결정하였다.

• 프론트엔드 : https://www.wowGood.com
• 백엔드 : https://api.wowGood.com
  (위 링크는 한 가지 예시로, 실제 존재하지 않는 링크입니다.)

로그인을 하면, 자동으로 /books로 리다이렉트 되는데 요청 헤더를 보면 쿠키가 정상적으로 담긴 모습을 볼 수 있다.

그 결과, 성공적으로 사파리 환경에서 로그인에 성공하였다!

처음에는 "크롬에선 잘 되는데 왜 Safari에선 안 되는거지?"라는 의문이 들었다. 같은 코드임에도 특정 브라우저에서만 인증이 되지 않는다는 사실이 원인을 정확히 파악하기 전까지는 꽤나 당황스러웠다.

하지만 이번 경험을 통해 웹 브라우저별 보안 정책의 차이, 특히 Apple Safari의 ITP 정책과 같은 플랫폼 특화 정책을 새로 배울 수 있었다.

또한 크로스도메인 인증과 쿠키 정책, 그리고 SameSite 속성의 의미와 동작 원리를 깊이 있게 이해하게 되면서 웹 보안 전반에 대한 이해도 역시 한층 높일 수 있는 계기가 되었다.

처음엔 자료도 많지 않고 비슷한 사례도 흔하지 않아 꽤 막막했지만, 하나씩 실험하고 설정을 바꿔보며 끝내 문제를 해결하는 끈기를 기를 수 있는 계기가 되었다.

💡자료 출처

https://atoz-develop.tistory.com/entry/작성중-Cookie쿠키와-도메인의-관계-정리

https://www.codeit.kr/tutorials/94/쿠키의 SameSite 옵션이란%3F