Cross site tracking에 대해

최근에 비용 문제 때문에 개인적으로 운영하던 개인 프로젝트의 배포구조를 크게 변경한 적이있다.

그런데 어째서인지 변경 이후부터 세션 쿠키가 브라우저에 정상적으로 저장되지 않는 문제가 발생했었다.

증상을 좀 처럼 좁히기 힘들었는데 디버깅 과정에서 크로스 브라우징 이슈라는 것을 깨달았고,

좀 더 좁혀보니 결론적으로 WebKit(Safari) 환경에서 강제하는 특수한 보안 정책 때문에 Cross-site tracking 관련한 이슈가 생기고 있었다.

WebKit 보안 정책

처음 겪어보는 다소 어이없는 문제상황이었다.

Webkit에서는 특이하게 프론트와 백엔드의 origin(프로토콜/도메인/포트)이 서로 다르면, Safari의 추적 방지 정책에 의해 기대대로 동작하지 않는 경우가 있다고 한다.

내 케이스에서는 증상이 이렇게 나타났다.

• 증상 1: 브라우저가 생성하는 HTTP 요청 헤더에 쿠키가 정상적으로 전달되지 않음
• 증상 2: 백엔드가 브라우저에 보내는 HTTP 응답헤더 Set-Cookie가 Safari에서 무시해버림

배포구조를 변경하기 전까지는 Safari/Chrome 모두 문제없이 동작하던 기능이었는데, 비용을 줄이려고 배포 구조를 바꾸면서 프론트/백엔드 오리진이 갈라졌고, 그 시점부터 Safari에서만 로그인 실패가 발생하게 됐었다.

처음엔 내 아이폰 기종을 의심했지만, 원인을 좁혀보니 결국 Safari의 보안 정책이 원인이었다.

해결 과정

비슷한 문제를 겪은 사례를 구글링으로 이미 많이 찾아볼 수 있는 상태였고, 가장 많은 힌트를 준 곳은 Stack Overflow이었다.

특히 아래 문장을 보고 이거구나!! 하는 확신이 들었다...!

Versions of Safari on MacOS 10.14 and all browsers on iOS 12 are affected by this bug which means that SameSite=None is erroneously treated as SameSite=Strict, e.g. the most restrictive setting.

이러한 Cross-origin 상황에서 현실적인 해결 방법은 크게 두 가지였다.

1. 프론트/백엔드를 같은 오리진으로 호스팅하는 것.
2. 쿠키 대신 Local/Session Storage 등으로 세션상태를 저장하는 것

나는 개인프로젝트에 발생하는 과도한 운영비용이 싫어서 배포구조를 갈아엎은 상황이었다.

때문에 Option 1이 보안적(XSS)으로도 좀 더 낫고, 추가적인 구현비용도 들지 않아서 가장 좋은 선택이었지만

금전적💰... 으로 아끼는 게 가장 먼저여서 기술을 포기하고 돈을 택해야만 했다.

조금 찝찝하지만 Option 2로 구현을 마치고나니 문제는 완전히 해결됐지만, 솔직히 “정공법으로 해결했다”기보다는 다른 수단으로 우회 통과한 느낌이 남았다.