헷갈리는 맛 쿠키

인증 세션같은 것을 개발하다 보면 늘 접하는 개념이 쿠키인데, 알고있는 것 같으면서도 헷갈리는 부분이 많아 늘 문서를 찾아보게 된다. 이번에 또 접한 쿠키 관련 이슈가 있어 정리하고 기록해보면 좋을 것 같다.

쿠키는 도메인 단위로 볼 수 있다. 예를 들어, abc.com 에서 설정한 쿠키의 속성 및 값이 def.com 에서 설정한 쿠키의 속성 및 값과 동일해도, 서로 다른 쿠키라고 보는 것이다. 하지만 여기서 동일한 도메인이라는 개념이 헷갈리기 쉬운데, 여기서 짚고 넘어가면 좋을 것 같다. 정리하기 전, 쿠키에서 도메인이 동일한 경우 SameSite 라고 지칭하면 될 것 같다.

abc.com 과 abc.abc.com 은 SameSite로 본다.
abc.com 과 abc.com:8080 은 SameSite로 본다.
abc.com 과 abc.co.kr 은 SameSite로 보지 않는다.
github.io 와 my.github.io 는 SameSite로 보지 않는다.

1번과 4번의 내용이 서로 상충되지 않냐고 볼 수 있는데, SameSite 를 나누는 기준이 public suffix에 명시된 최상위 도메인과 관련이 있는데, 최상위 도메인이 명시되어 있으면, 그 앞의 부분까지 하나의 Site 라고 판단한다. 예를 들어, .com 최상위 도메인은 public suffix 에 명시되어 있으므로 abc.com 을 하나의 Site 라고 판단하고, abc.abc.com, def.abc.com 도 동일한 Site 라고 본다. 반면, .io 는 public suffix 에 명시되어 있지 않으므로 my.github.io 까지 하나의 Site 라고 본다. 즉 your.github.io 와 my.github.io 는 서로 다른 Site 라고 판단되어, SameSite 로 보지 않는다.

SameSite 속성별 특징

SameSite 속성에 값은 총 3가지 중 하나가 올 수 있는데, 각각의 특징을 알고 있어야 한다.

Strcit / 쿠키를 오직 동일 Site 에서 설정한 경우에만 전송한다. 예를 들어, abc.com 에서 Set-Cookie 로 설정한 쿠키는 def.com 로 전송하지 못하는 것이다.
Lax / 쿠키를 동일 Site 에서 설정한 경우에만 전송하지만, 조건을 만족하는 경우 다른 Site 여도 쿠키를 전송한다.
- fetch API를 사용한 요청일 경우
- <img>, <script> 등의 태그를 사용한 리소스 요청인 경우 혹은 <iframe> 내부에서 네비게이션이 일어나는 경우
None / 쿠키를 동일 Site, 다른 Site 구분 없이 항상 전송한다. 단, Secure 라는 속성과 함께 설정되어야 한다. (https를 통한 요청에만 쿠키가 전송되며, localhost 는 예외처리 된다.)

Proxy

뜬금없이 무슨 Proxy냐고 하면.. 최근 회사에서 서비스 인증 방식을 바꾸는 작업에서 JWT를 사용하다 쿠키 방식으로 변경할 때에 서버와 도메인이 달라 쿠키 관련 이슈가 생겼었다. https 를 사용하지 않고 있어서 SameSite=None; 방식을 사용하기에는 무리가 있었고, 보안적으로 문제가 될 부분이라고 생각됬다.

배포 환경에서는 백엔드 서버말고 자기 자신을 호출하게끔 하여 /api 로 시작하는 요청에 대해 nginx 에서 proxy pass 하여 백엔드로 가게 해두어 동일 도메인으로 취급되는 것 같아 이슈가 재현이 되지 않는데, 개발 서버에서는 그 역할을 proxy 가 대신 해줄 수 있었다. 모두 proxy 를 사용하여 API 호출을 사용할 거라 생각해서 동일 도메인이라 쿠키가 당연히 전송될거라 생각했었는데, proxy 를 사용하지 않고 있었던 것이다..! 하여튼 proxy 설정을 통해 동일 도메인 취급을 받을 수 있었다.

인증 방식 자체가 JWT로 가는 경우가 많기도 하다보니, 쿠키 관련은 조금 생소한 느낌이 들기도 했다.

헷갈리는 맛 쿠키